How OpenHaven Works
How we build and maintain the Navigator and Matrix — and how to get involved.
How protocols and tools get into the Navigator
OpenHaven’s convergence matrix — the structured dataset behind the Navigator — is built through dedicated research and community contribution.
Research-led intake.
Our research team investigates the peer-to-peer and decentralized protocol landscape using published documentation, source code, governance records, and direct engagement with protocol communities. New entries are proposed by the research team or by community members and partners.
Community submissions.
Anyone can propose a new protocol, tool, or project for inclusion. Our contribution pathway captures what the research team needs: protocol name, governance model, key affordances, development status, and source references.
Propose a new entry →What we collect.
Each entry includes 40+ standardized attributes covering technical capabilities, governance structure, capture risk, development status, self-hostability, source licensing, and community links. Every capability claim is backed by at least one independent source reference.
Our review standards — and how they’re evolving
What we verify today.
Our research team drafts each entry, and our Research Lead reviews it against published sources before publication. Every entry is checked for:
- Development status is current (active, maintained, archived, or deprecated)
- Governance model is documented and sourced (foundation, DAO, single company, open standard body, etc.)
- Capture risk assessment is grounded in observable governance structure
- Capability claims are supported by at least one independent source — documentation, repository evidence, or third-party confirmation. Self-attestation from a developing team is not sufficient.
- Community links (repos, forums, chat groups) are active and current
Freshness tracking.
Every entry carries a last_investigated date — when the research team last reviewed it. Stale data is visible, not hidden.
Where we're headed.
We don’t stamp entries “verified” or “unverified.” Instead, each entry shows a combination of independent signals — research review, development team confirmation, and community verification — so you can see exactly how much scrutiny it’s received.
Reviewed by Research Lead
Internal review against published sources. This is the baseline today.
Confirmed by development team
The technology’s own development team has reviewed and confirmed the entry’s accuracy. A useful signal, but not sufficient on its own — one input, not a stamp of approval.
Third-party verified (N)
Independent community members have reviewed and confirmed the entry, with a visible count. An entry verified by 24 people carries more weight than one verified by 2.
These signals are additive, not sequential. An entry might be reviewed by the Research Lead and confirmed by 12 independent verifiers but not yet confirmed by the development team. Another might have development team confirmation but no third-party review yet. Every entry shows exactly where it stands.
This model means verification doesn’t depend on any single person. It becomes a shared practice — rooted in the community this data serves.
Update triggers.
Entries are revisited when:
- A community member flags an issue or suggests an update
- A protocol team releases a significant update or governance change
- Partners surface new information through coordination channels
Governance and capture risk.
We surface governance model and capture risk on every entry because we believe it matters — a technology’s governance structure shapes whether it stays open or gets captured. But we want to be direct: how to best assess capture risk for each technology is something we’re still working out, and we’re looking to the community for guidance on how to do it well.
Ways to contribute and connect
The Navigator is stronger because people who know the landscape help build and maintain it. If you rely on this data, you can help make it better.
Flag an error or suggest an update.
Community flags are a primary update trigger. Your input directly improves the data for everyone.
Suggest an update →Propose a new entry.
Know a protocol, tool, or project that should be here? Our contribution pathway captures what the research team needs to verify and publish it.
Propose a new entry →Help shape verification and capture-risk standards.
Our verification standards and capture-risk assessment frameworks are still evolving. If you have experience with data verification, protocol evaluation, or governance assessment in open-source or decentralized contexts, we want your input.
Get in touch →Protocol team and coalition partnerships.
If you represent a protocol team, a coalition organization, or a research group in the P2P and decentralized space — let’s talk. Whether that’s ensuring your project’s data is accurate, coordinating on shared research, or exploring deeper collaboration.
Get in touch →Participate in governance.
OpenHaven’s governance evolves as the community grows. We operate as a small founding team with a consent-based decision model and are building pathways for broader participation. If you’re interested in contributing to how OpenHaven is governed — not just its data — reach out.
Get in touch →Spread the word.
If OpenHaven is useful to you, share it. The more eyes on this data, the more accurate and complete it becomes.
Attribution.
Every contribution is credited. Data contributions, editorial input, and community flags are tracked with contributor attribution. When your submission is verified and published, your name (or pseudonym, by preference) appears on the work — including on protocol cards in the Navigator.
Team
- Day Waterbury — Open Protocol Visionary and Project Management
- Brandon Nørgaard — Backend Development and Technical Research
- Zach Miltz — Product Management and Full Stack Development
- Marty Behrens — User Research and Community Outreach
- Kevin Triplett — Decentralized Technology Advisor