Methodology

The reasoning behind our scoring framework.

Summary

Formula: TotalScore = 0.4 * Chain + 0.4 * Control + 0.2 * Fairness

Kill-Switch Cap: B5=0 caps total score at 1.0

Current #1: Bitcoin scores highest in our framework

Why 40/40/20?

Chain Score (40%) measures technical decentralization - can the network survive attacks? This is fundamental: without a resilient network, nothing else matters.

Control Score (40%) measures governance decentralization - who actually controls the protocol? A technically decentralized network means nothing if one entity can change the rules, halt the chain, or steal funds through upgrades.

Fairness Score (20%) measures launch and distribution fairness. This matters less for ongoing decentralization but reflects the project's values and long-term incentive alignment. A 70% VC premine creates different dynamics than a fair launch.

Chain and Control are equally weighted because both are necessary conditions for decentralization. Fairness is weighted lower because it's a one-time historical fact that affects but doesn't determine ongoing decentralization.

Why Cap at 1.0 for Kill-Switches?

If a project has an architectural kill-switch (B5=0), it is fundamentally not decentralized, regardless of how well it scores on other criteria.

B5=0 applies to: Smart contract pause functions (admin keys), documented emergency stops (explicit "safe mode"), governance with halt-authority (foundation/council can stop chain by design), and centralized sequencers (L2s where one entity controls transaction inclusion).

B5=0 does NOT apply to: Bug-crashes (unintentional outages), coordinated restarts after crashes, or low validator concentration (assessed separately in B1/B3).

Bug-crash = technical immaturity. Kill-switch = architectural centralization. Different problems, different scores. We display the uncapped score for transparency.

Why These 14 Criteria?

We selected criteria that are measurable, meaningful, and resistant to gaming. Each criterion captures a distinct aspect of decentralization that cannot be easily faked.

Chain Score (A1-A5)

  • A1: Nakamoto Coefficient - Number of independent entities that would need to collude to compromise the system.
  • A2: Validator/Miner Concentration - Share of top 5 validators/miners in stake/hashrate.
  • A3: Client Independence - Number of independently developed full-node implementations.
  • A4: Node Geography & Hosting - Geographic distribution of nodes and cloud hosting concentration.
  • A5: Full Node Decentralization - Number of independent full nodes validating the chain.

Control Score (B1-B6)

  • B1: Corporate/Foundation Capture - Is there a dominant company/foundation controlling roadmap, marketing, and hiring? Can the project survive without them?.
  • B2: Repo/Protocol Ownership - Distribution of merge rights in core repositories (clients, specs).
  • B3: Brand & Frontend Control - Who owns brand, domains, main frontends, official wallets/apps? Decentralized ownership is better.
  • B4: Treasury & Upgrade Keys - Composition of treasury/upgrade multisigs and admin keys.
  • B5: Admin Halt Capability - Can a single entity or small group unilaterally halt, freeze, or censor the chain? This is a critical centralization risk.
  • B6: Protocol Immutability - Has the protocol made fundamental rule changes (consensus mechanism, monetary policy, contentious forks)? Immutable rules are a core property of decentralization.

Fairness Score (C1-C3)

  • C1: Launch Fairness / Premine - Team/VC/Foundation premine and launch model (fair launch vs.
  • C2: Token Concentration - Share of circulating supply held by insiders (team/VC/foundation).
  • C3: Governance Control - Share of governance voting power held by insiders.

Scoring Rubric

Each criterion is scored 0-10. Within each category, all criteria are equally weighted. Here's what the scores mean:

ScoreMeaning
0Fully centralized / Single point of failure
1-3Highly centralized / Few entities dominate
4-6Moderately decentralized / Some concentration
7-9Highly decentralized / Well distributed
10Maximum decentralization / No single point of control

Category Weights

  • Chain Score: A1-A5 equally weighted (each 20% of Chain Score)
  • Control Score: B1-B6 equally weighted (each ~16.7% of Control Score)
  • Fairness Score: C1-C3 equally weighted (each ~33.3% of Fairness Score)

N/A values (criteria that don't apply to a consensus type) are excluded from the average.

Example Calculation

Project with Chain=7.5, Control=6.0, Fairness=8.0:
TotalScore = 0.4 × 7.5 + 0.4 × 6.0 + 0.2 × 8.0 = 3.0 + 2.4 + 1.6 = 7.0

Highest Scoring Project

Bitcoin currently scores highest in this framework. This is an outcome of the criteria, not a predetermined choice. Key characteristics that contribute to its score:

  • No premine, no VC allocation, no foundation treasury (C1, C2)
  • No documented halt or censorship capability (B5)
  • Limited protocol changes since launch (B6)
  • Project continuity after founder departure

Other projects may score higher as they evolve or as framework criteria are refined.

What We Don't Measure

Decentralization is not the same as quality. We deliberately exclude:

  • Price / Market Cap - Not a decentralization metric
  • TVL - Measures adoption, not decentralization
  • TPS / Performance - Often traded for centralization
  • User Experience - Orthogonal to decentralization
  • Team Reputation - Subjective and gameable

This framework focuses on decentralization metrics only. Other factors may be relevant for different use cases.

Data Sources & Objectivity

We measure what's measurable and document transparently where judgment is required. Each criterion falls into one of two categories:

Chain Score (A1-A5)

Network metrics fetched daily via chain-specific APIs.

  • A1 - Nakamoto Coefficient
  • A2 - Validator/Miner Concentration
  • A3 - Client Independence
  • A4 - Node Geography & Hosting
  • A5 - Full Node Decentralization

Control Score (B1-B6) - Expert Assessment

Requires human judgment. No API can determine if a foundation can halt a chain. Each assessment is documented with sources and reasoning.

  • B1 - Corporate/Foundation capture - Who controls roadmap, hiring, marketing?
  • B2 - Repo ownership - GitHub contributor analysis, merge rights distribution
  • B3 - Brand & frontend control - Domain ownership, official apps, alternatives
  • B4 - Treasury/upgrade keys - Multisig composition, signer independence
  • B5 - Admin halt capability - Can anyone pause/freeze the chain?
  • B6 - Protocol change history - Fundamental rule changes since launch

Fairness Score (C1-C3) - Mixed

Historical and current distribution data. Verifiable from tokenomics sources.

  • C1 - Premine % - Historical, verifiable (Messari, docs, blockchain explorers)
  • C2 - Token concentration - Current insider holdings (on-chain data, Etherscan, etc.)
  • C3 - Governance control - Voting power distribution (Snapshot, governance dashboards)

N/A Values

N/A values indicate genuine absence of a centralization vector (e.g., Bitcoin has no treasury because there is no foundation). Projects cannot score poorly on metrics that don't apply to them - this is intentional, as absence of control structures is itself a form of decentralization.

For expert assessments, each value includes:

  • Source links with dates
  • Reasoning for the specific score
  • Known limitations or caveats
  • Full documentation in the project source files

No API can tell you if a foundation can halt a chain or if a team controls the brand. These require judgment - but that judgment is documented, sourced, and open to challenge.

Limitations

This framework is an approximation. Decentralization is a spectrum, not a binary. Some caveats:

  • Data is updated periodically - snapshots, not real-time
  • Some criteria require manual assessment (brand ownership, governance dynamics)
  • New attack vectors may emerge that our criteria don't capture
  • Scores reflect current state, not trajectory or potential

Use this as one input among many when evaluating projects. Not financial advice.