ABOUT ZERØTRUST

The Trustless Index is an educational platform designed to help users understand and compare blockchain networks across key metrics that matter for decentralized systems.

OUR MISSION

To provide unbiased, educational content that helps users make informed decisions about blockchain networks based on objective technical metrics.

OUR APPROACH

We evaluate blockchains across six critical dimensions: trustlessness, decentralization, immutability, censorship resistance, speed, and ownership distribution.

SCORING METHODOLOGY

BLOCKCHAIN SCORING

Layer 1 blockchains form the base layer of DeFi. They aren't governed by a single contract, but by consensus mechanisms, validator economics, and governance structures. To evaluate their trustlessness, we score them on six key dimensions. Each is scored 1.0 (worst) to 10.0 (best), with the Final Score as the average. This rubric is distinct from the one used for Smart Contracts because blockchains and dApps face different risks. Scores are based on verifiable facts from whitepapers, explorers, metrics sites, and historical data—trust nothing, verify everything.

Decentralization

Assesses validator/node distribution, diversity, and control concentration using metrics like node count, operator diversity, stake/hashrate distribution, and Nakamoto Coefficient.

10.0 ~ Tens of thousands of independent validators/nodes (>50,000), maximally diverse geographically/jurisdictionally, no entity controls >5%, Nakamoto Coefficient >100.
9.0-9.9 ~ Over 20,000 validators/nodes, highly diverse, minimal control concentration (5-10% by largest entity), Nakamoto Coefficient 75-100.
8.0-8.9 ~ 10,000-20,000 validators/nodes, strong diversity, low concentration (e.g., top pools control 10-20%), Nakamoto Coefficient 50-74.
7.0-7.9 ~ 5,000-10,000 validators/miners, good distribution but notable concentration (e.g., LSTs or pools at 20-30%), Nakamoto Coefficient 30-49.
6.0-6.9 ~ 1,000-5,000 validators, moderate diversity, emerging concentration (e.g., top operators at 30-40%), Nakamoto Coefficient 20-29.
5.0-5.9 ~ 500-1,000 validators, limited diversity, significant concentration (e.g., few operators control 40-50%), Nakamoto Coefficient 10-19.
4.0-4.9 ~ 200-500 validators, poor diversity, high concentration (e.g., top entities control >50%), Nakamoto Coefficient 5-9.
3.0-3.9 ~ 100-200 validators/nodes, minimal diversity, very centralized (e.g., foundation influences majority), Nakamoto Coefficient 3-4.
2.0-2.9 ~ 50-100 validators, negligible diversity, extreme centralization (e.g., one entity appoints most), Nakamoto Coefficient 2.
1.0-1.9 ~ Fewer than 50 validators, no diversity, fully centralized (e.g., single company/foundation controls all), Nakamoto Coefficient 1.

Censorship Resistance

Evaluates protocol-level resistance to transaction blocking or alteration, verified via historical events, validator compliance data, and features in code/docs. Cross-reference Decentralization for validator set influences.

10.0 ~ No history of freezes/blacklists/clawbacks; validator set too broad/diverse for any coordinated censorship.
9.0-9.9 ~ Extremely resistant, no protocol features enabling censorship; rare, isolated validator-level issues only. (<1% OFAC-compliant validators, no impact history)
8.0-8.9 ~ Highly resistant, but minor theoretical vectors (e.g., <10% OFAC-compliant validators, no impact history).
7.0-7.9 ~ Generally resistant, some practical cracks (e.g., 10-20% compliant validators, MEV filtering in relays).
6.0-6.9 ~ Moderately resistant, but validator concentration allows plausible collusion (e.g., 20-30% compliant).
5.0-5.9 ~ Limited resistance, evidence of steering (e.g., >30% compliant, past voluntary filtering events).
4.0-4.9 ~ Weak resistance, centralized set enables easy collusion; documented compliance pressures.
3.0-3.9 ~ Poor resistance, protocol includes optional freeze/clawback tools; coordination feasible via few entities.
2.0-2.9 ~ Very poor, built-in halts or blacklists used occasionally; censorship by design in governance.
1.0-1.9 ~ No resistance, mandatory freeze/blacklist/clawback features; easily coordinated by central authority.

Immutability

Measures resistance to rule changes or state reversals, checked against fork history, upgrade frequency, and governance docs. Cross-reference Security for halt overlaps; PoW favors hard forks, PoS social consensus.

10.0 ~ Strict "code is law" ethos; no rollbacks, admin keys, or halts ever; forks solely for non-reversing upgrades. (1 or less total in history)
9.0-9.9 ~ Near-perfect immutability; no reversals/halts, rare controlled upgrades (e.g., <1/year, community-driven via verifiable proposals).
8.0-8.9 ~ High immutability; no reversals, occasional upgrades (e.g., 1/year, via formal proposals like EIPs).
7.0-7.9 ~ Strong but flexible; no reversals, regular upgrades (e.g., 1-2/year, foundation-influenced roadmaps).
6.0-6.9 ~ Moderate immutability; no reversals, but frequent upgrades (e.g., >2/year), some halts without state changes. (<5 total)
5.0-5.9 ~ Limited; history of short halts (5-10 total), foundation-driven frequent changes, no full reversals.
4.0-4.9 ~ Weak; multiple halts (>10), upgradable consensus, but no forced reversals yet.
3.0-3.9 ~ Poor; documented halts/reversals (1-5 reversals), consensus upgradable by multisig/governance.
2.0-2.9 ~ Very poor; repeated forced changes (>5 reversals), foundation controls upgrades freely.
1.0-1.9 ~ No immutability; routine halts/rollbacks (>10), fully upgradable by central entity.

Security

Assesses consensus reliability against attacks/downtime, verified by uptime records, attack history, and economic metrics. Economic security is consensus-specific: for PoS, total staked value; for PoW, estimated annual 51% attack cost.

10.0 ~ Battle-tested with >$50B economic security; zero downtime, no 51%/consensus attacks ever.
9.0-9.9 ~ Extremely secure; >$25B economic security, no attacks, minimal patched vulnerabilities without exploits.
8.0-8.9 ~ Highly secure; >$10B economic security, strong record, rare centralized infra issues (e.g., brief AWS reliance outages <1/year).
7.0-7.9 ~ Good security; >$5B economic security, no major attacks, some small exploits patched quickly.
6.0-6.9 ~ Moderate; >$1B economic security, occasional downtime or minor reorgs without user disruption (<5 incidents).
5.0-5.9 ~ Limited; >$500M economic security, documented liveness failures or reorgs causing minor user issues (5-10 incidents).
4.0-4.9 ~ Weak; >$100M economic security, multiple downtimes, reorgs disrupting users (>10), no successful consensus exploits yet.
3.0-3.9 ~ Poor; >$50M economic security, repeated halts/reorgs, small consensus-layer exploits resolved.
2.0-2.9 ~ Very poor; >$10M economic security, frequent exploits, ongoing unresolved issues at consensus level.
1.0-1.9 ~ Insecure; <$10M economic security, successful major attacks, chronic downtime/halts.

Speed

Evaluates real-world finality and throughput, sourced from testnets, mainnet metrics, and UX reports; note trade-offs with decentralization.

10.0 ~ Sub-second finality (<1s), >10,000 TPS sustained, no halts.
9.0-9.9 ~ Very fast; 1-2s finality, 5,000-10,000 TPS, rare minor lags.
8.0-8.9 ~ Fast; 2-3s finality, 2,000-5,000 TPS, handles load well.
7.0-7.9 ~ Good; 3-5s finality, 500-2,000 TPS, occasional load-based delays.
6.0-6.9 ~ Moderate; 5-10s finality, 200-500 TPS, lags under moderate load.
5.0-5.9 ~ Limited; 10-15s finality, 100-200 TPS, frequent load issues.
4.0-4.9 ~ Slow; 15-30s finality, 50-100 TPS, clunky DeFi UX.
3.0-3.9 ~ Poor; 30-45s finality, 20-50 TPS, significant UX friction.
2.0-2.9 ~ Very poor; 45-60s finality, 5-20 TPS, unreliable for DeFi.
1.0-1.9 ~ Unusable; >60s finality, <5 TPS, constant failures.

Speed is included because user experience depends on how fast transactions confirm, but it's not a free win: high speed is often achieved by reducing validator numbers or centralizing consensus, which can weaken decentralization and immutability. In other words, chains that boast higher throughput may gain performance but lose trustlessness, while slower chains often protect security and censorship resistance through broader validator participation.

Distribution (Ownership)

Analyzes token supply concentration via on-chain data, premine details, and holder metrics from explorers/analytics.

10.0 ~ No premine/hoard; fully broad distribution across >10M holders, no entity >1%.
9.0-9.9 ~ Minimal premine; very broad (>5M holders), largest holders <5%.
8.0-8.9 ~ Low concentration; broad (>1M holders), identifiable whales <10%.
7.0-7.9 ~ Mostly broad; >500K holders, concentrated early allocations (10-20%).
6.0-6.9 ~ Moderate concentration; >100K holders, insiders/VCs hold 20-30%.
5.0-5.9 ~ Notable concentration; 50-100K holders, >30-40% linked to foundation/insiders.
4.0-4.9 ~ High concentration; <50K holders, >40-50% controlled by few entities.
3.0-3.9 ~ Very high; majority (>50-60%) by foundation/VCs, limited holders.
2.0-2.9 ~ Extreme; >60-80% centralized, small group dominates.
1.0-1.9 ~ Fully centralized; >80% owned/controlled by one entity/group.

Final Score

The Final Score is the average of the six metrics above. While all factors are weighted equally in the math, readers should note that Decentralization and Immutability are the most critical in assessing whether an L1 can be stopped or steered.

SMART CONTRACT SCORING

The Trustless Index evaluates smart contracts and protocols on five core dimensions of trustlessness. Each metric is scored from 1.0 (worst) to 10.0 (best). The Trustless score is the average of all five.

Our framework is designed to be absolute, not relative. That means HEX scoring 10.0 doesn't mean Aave "must" be close at 9.0 - it means HEX meets the maximum bar of immutability and Aave doesn't, regardless of popularity.

No Admin

10.0 ~ No admin keys, no owner functions, no multisigs, no governance hooks that can alter core logic.
7.0-9.0 ~ Only minimal, non-critical functions remain (e.g. fee routing, variable adjustments).
4.0-6.0 ~ Multisigs or DAOs can pause, upgrade, or otherwise interfere.
1.0-3.0 ~ Clear admin control; contract can be altered at will.

Immutable

10.0 ~ Finished product; bytecode is final, rules cannot change.
7.0-9.0 ~ Mostly fixed, but some configurable parameters.
4.0-6.0 ~ Upgradeable via proxy or governance.
1.0-3.0 ~ Fully mutable; upgrade hooks allow core logic to change freely.

No Proxy

10.0 ~ Contract deployed directly; no upgradeable proxy in place.
7.0-9.0 ~ Some auxiliary modules proxied, core immutable.
4.0-6.0 ~ Major functions proxied and upgradable by governance.
1.0-3.0 ~ Proxy controlled by admin/multisig; logic swappable at will.

Open Source

10.0 ~ Fully verified source code on-chain, open GitHub/GitLab repository, transparent deployment history.
7.0-9.0 ~ Mostly open, minor components unverified or obfuscated.
4.0-6.0 ~ Partial transparency, unverifiable helpers.
1.0-3.0 ~ Closed-source or non-verified bytecode.

Audited

10.0 ~ Multiple professional audits, long runtime, and active bug bounty programs. For immutable contracts, audits are evergreen.
7.0-9.0 ~ At least one professional audit plus runtime history, but active upgrade path means audits can expire.
4.0-6.0 ~ Single audit of limited scope or younger project with minimal track record.
1.0-3.0 ~ No known audit or unresolved critical issues.

Trustless Score

The final Trustless score is the arithmetic mean of the five categories above.

Notes on Interpretation

High Audit score ≠ perfect safety. Aave may score 9.0 for audits because it has many and runs a bug bounty, but since it's upgradeable, audits can "age out" as code changes. HEX, on the other hand, is immutable - so a single set of audits remains valid forever, justifying a 10.0.

No Admin & Immutable are weighted in perception. While mathematically all metrics are equal, readers should note that these two define the heart of trustlessness. A protocol with a 10 in Audited but a 1 in No Admin is not trustless.

EDUCATIONAL PURPOSE

This platform is designed for educational purposes only. Scores and ratings are based on technical analysis and should not be considered as investment advice. Always do your own research before making any decisions.