Decentralisation Assessment
Decentralisation is multi-dimensional. A network can be decentralised in validators but centralised in software development, governance, sequencers, admin
Reading progress — saved on this device
Learning objectives
- Assess decentralisation across consensus, governance, software, infrastructure and economics.
- Identify practical choke points rather than relying on branding.
- Distinguish redundancy from independent control.
What it is
Consensus decentralisation asks who produces and finalises blocks. Governance decentralisation asks who can change rules. Infrastructure decentralisation asks whether nodes depend on the same hosting, RPC or oracle providers. These are related but not interchangeable.
Economic concentration matters because stake, mining power or liquidity can create influence even when node counts are high. The distribution of effective control is more useful than raw participant count.
Some systems intentionally centralise early-stage components for performance or security. Research should describe the trade-off accurately and track whether promised decentralisation milestones are actually implemented.
How to analyse it
Map each control plane: consensus participants, client software, governance delegates, admin keys, sequencers, bridges, oracles, front ends and major infrastructure providers.
Use concentration measures such as top-N share, Nakamoto-style thresholds or provider dependence where appropriate. The metric should reflect the action needed to censor, halt or rewrite the system.
Test geographic and organisational independence. Ten validators run by one company or on one cloud provider do not create ten independent failure domains.
Assess exit and recovery. Can users submit transactions through alternative interfaces, run their own node, withdraw through a canonical bridge or fork software if a governance actor becomes hostile?
Research framework
| Check | Why it matters | What to verify |
|---|---|---|
| Consensus | Controls ordering/finality | Measure validator/miner concentration and client diversity. |
| Governance | Controls rules | Measure delegate, foundation and admin-key authority. |
| Infrastructure | Controls access | Review RPC, cloud, sequencer, oracle and bridge concentration. |
| Exit options | Limits capture | Assess self-hosting, alternative interfaces, withdrawal and forkability. |
Evidence hierarchy and limitations
Decentralisation metrics can be gamed through sybil entities. Where possible, cluster related validators, custodians or delegates by ownership rather than counting addresses blindly.
The relevant decentralisation threshold depends on the threat. Censoring one user, halting finality and executing a malicious upgrade can require different actors and percentages.
Worked example and thought exercise
A network has 120 validators, but the top three operators control 58% of stake and 75% of nodes run on two cloud providers. Validator count alone suggests breadth; effective economic and infrastructure concentration tells a more nuanced story.
A rollup may inherit strong settlement security from a base layer while still relying on one sequencer for transaction ordering. The system is not simply “centralised” or “decentralised”; the specific control plane matters.
Thought exercise: Which decentralisation dimension matters most if your primary concern is censorship rather than theft or protocol upgrades?
Common mistakes and practical workflow
- Using node count without ownership clustering.
- Combining unrelated decentralisation dimensions into one score.
- Ignoring cloud, RPC, sequencer and oracle dependence.
- Assuming planned decentralisation has already occurred.
Practical workflow
- Define the threat model and action of concern.
- Map consensus, governance, infrastructure and software control.
- Measure effective ownership concentration, not raw addresses.
- Identify common-mode providers and key dependencies.
- Evaluate user exit, self-hosting and recovery options.
Knowledge checkpoint
- Why is decentralisation multi-dimensional?
- How can sybil entities distort validator counts?
- What is a control plane?
- Why do exit options matter?
FAQs
❓ Is more validators always better?
Not if validators share ownership, infrastructure or key custody.
❓ Can a system be decentralised in consensus but centralised in governance?
Yes. Different control planes can have very different concentration.
❓ Why does client diversity matter?
A bug in one dominant software client can create a common-mode network failure.
❓ Is temporary centralisation always unacceptable?
Not necessarily, but the risk and transition plan should be explicit and verifiable.
Summary
A useful decentralisation assessment maps who controls each critical function and how easily that control can be coordinated. Measure effective independence, common dependencies and user exit options rather than relying on a single headline score.
Want this in a personalised order?
Take the crypto assessment and get a custom path of 10 modules matched to what you already know. Free, no card required.
Build my path →