As definições são publicadas em inglês.
Capture Risk Assessment Methodology
Capture risk scores in the OpenHaven matrix are based on this structured assessment methodology. It explains what the 1–5 scale means, which five dimensions each entity is evaluated against, and how individual scores are derived.
Every score in the matrix is transparent and defensible: each entry includes its reasoning, and any score can be independently verified from publicly observable facts.
What "capture risk" means
Capture risk is the risk that a protocol, standard, or tool could be taken over, co-opted, or substantially controlled by a single entity — typically a company, a well-resourced foundation, a state actor, or an individual — in ways that undermine its open, decentralized, or community-governed character.
Capture risk is structural information, not a verdict. A high capture risk score does not mean a technology is bad or should be avoided. It means that users, builders, and communities who depend on it should understand the concentration of control and factor it into their risk calculus.
The 1–5 scale
Capture risk is scored on a 1–5 integer scale:
| Score | Label | Meaning |
|---|---|---|
| 1 | Minimal | Open standard governed by a neutral multi-stakeholder body; multiple independent implementations; no single entity holds meaningful control over the protocol's direction, IP, or infrastructure |
| 2 | Low | Open governance with a dominant steward, but community checks exist; forking is realistic; no single entity controls IP outright |
| 3 | Moderate | A foundation, a dominant organization, or a small group holds significant influence; forking is viable but costly; the protocol would likely survive a change in stewardship but not without disruption |
| 4 | High | Effective single-party control — one company, a DAO with heavy whale concentration, or a single key organization controls the protocol's direction and infrastructure |
| 5 | Critical | Full commercial or state capture; a single legal entity controls IP, infrastructure, roadmap, and governance with no meaningful external check |
Score 5 and OpenHaven's scope
Entities scored 5 — fully commercially or state-captured platforms — are outside OpenHaven's primary scope. OpenHaven catalogs decentralized and open protocols; a score-5 entity is by definition not one of these.
Score-5 entities appear in the matrix only as baseline comparisons: concrete anchors that show users what full capture looks like, making the contrast with genuinely open alternatives legible. They carry no affordance assignments and are visually distinguished from in-scope entries.
Representative score-5 examples: Facebook / Meta, Twitter / X, TikTok (ByteDance), Discord, Slack (Salesforce), YouTube (Google / Alphabet). These are not recommendations and are not candidates for OpenHaven's primary discovery surfaces.
Evaluation dimensions
Every entity is evaluated against five dimensions. Each dimension is scored 1–5 using the rubrics below. The overall capture risk score is the unweighted average of all five dimension scores, rounded to the nearest integer.
1. Governance & legal control
Who controls protocol changes, and who holds the intellectual property, trademarks, and domain infrastructure? How are decisions made and by whom?
| Score | Description |
|---|---|
| 1 | Open standards body (IETF, W3C, ISO, or equivalent) with a documented, public decision process and no single controlling member; IP held by a neutral steward or in the public domain under an irrevocable license; no single entity can close-source or restrict the protocol |
| 2 | Multi-stakeholder foundation with transparent governance docs and meaningful community veto or proposal power; IP held by a foundation under a permissive or copyleft license; practical revocation is improbable or legally constrained |
| 3 | Single foundation or organization holds final authority but accepts community input; governance is documented but concentrated; open license but future versions could be relicensed, or brand/trademark sits in concentrated hands |
| 4 | Effective single-party control; a company or DAO with heavy concentration steers the protocol and community input is advisory only; IP held by a company that could unilaterally relicense future versions; trademarks enforced by a single party |
| 5 | Single commercial entity with no formal governance process; decisions are internal product decisions; IP fully held by that entity with no encumbrance, free to close-source, restrict, or weaponize without community recourse |
2. Regulatory / jurisdictional exposure
Is the entity subject to regulatory or state pressure that could force co-option?
| Score | Description |
|---|---|
| 1 | Minimal jurisdictional exposure; protocol operates without a legal entity in any heavily regulated domain; no single government could compel a meaningful change |
| 2 | Legal entity in a relatively neutral jurisdiction; regulatory pressure is a theoretical risk but not a near-term realistic one |
| 3 | Legal entity in a jurisdiction with active regulatory interest in the relevant technology domain; a significant compliance demand could reshape the protocol |
| 4 | Legal entity subject to ongoing or recent regulatory pressure; compliance demands have already shaped protocol behavior or governance |
| 5 | Legal entity in a high-control jurisdiction or heavily regulated sector; state-directed or regulator-driven capture is a realistic near-term risk |
3. Funding & key-org dependency
How is the project funded, how much influence does any single funder hold, and could the protocol be captured or substantially redirected through pressure on a single person or organization?
| Score | Description |
|---|---|
| 1 | Diverse funding from multiple independent sources (grants, protocol fees, community donations, multiple institutional donors), no single source dominating; knowledge and decision-making are broadly distributed with no individual or organization a single point of failure |
| 2 | Two to three major funders, none of whose loss would threaten continuity or meaningfully shift direction; a small number of key contributors are highly influential but documented processes exist and successors are realistic |
| 3 | Primarily one funder with some diversity, leaving the project financially vulnerable to that funder's preferences but not wholly controlled; one lead maintainer or organization is highly influential and the project would likely survive their departure but with significant disruption |
| 4 | A single funder provides the large majority of budget and substantially shapes direction; a single person or organization is essential to continuity, such that acquisition, legal pressure, or exit would substantially redirect the protocol |
| 5 | Wholly funded by a single commercial or state entity, with funding and direction inseparable; that person or organization is the sole effective maintainer, and capture of them equals capture of the protocol |
4. Forking viability
If the project were captured, how realistic is a meaningful fork?
| Score | Description |
|---|---|
| 1 | Open license, clean spec/implementation separation, fork history demonstrates it is achievable; a fork community could credibly replace the original |
| 2 | Open license and reasonable documentation; forking is technically feasible with significant coordinated effort |
| 3 | Open license but high technical complexity, strong network effects, or ecosystem coupling makes a meaningful fork costly and slow |
| 4 | Forking is technically possible but practically unviable: network effects, legal complexity, or data portability constraints make the original nearly irreplaceable |
| 5 | Fork is not viable: proprietary components, legal constraints, or winner-take-all network effects make a competitive fork prohibitive |
5. Track record
Is there observable evidence of past capture-favoring decisions?
| Score | Description |
|---|---|
| 1 | No capture-favoring decisions on record; governance choices consistently favor openness and multi-stakeholder benefit |
| 2 | Minor decisions that favored a dominant party, but these were transparent and corrected through community feedback |
| 3 | Mixed record; some decisions clearly favored a controlling party but community influence has had measurable effect over time |
| 4 | A clear pattern of decisions that prioritize a controlling entity; community input is acknowledged but rarely decisive |
| 5 | Documented capture events: spec changes that locked out alternative implementations, license changes, hostile fork suppression, or governance restructuring that removed community voice |