Centralization risk is the exposure created when one party can unilaterally change the rules, move the money, or stop the chain. In a token system it sits in five concrete places: admin keys, upgrade rights, oracle control, sequencer operation, and validator or stake concentration. Each one is measurable and each one has a named holder. If nobody on the team can name the holder, that is the finding.
Decentralization is not a property of a protocol. It is a property of one specific privileged action. Ask who can call this function today and how fast, rather than whether the project is decentralized, because the second question has no answer anyone can audit.
The five places control actually sits
Admin keys: which addresses hold which roles, and is there a delay between an instruction and its execution. Upgrade rights: is the logic behind a proxy, and who owns the proxy admin. Oracle control: who may write the price, how many independent writers exist, and what the contract does when the feed stops. Sequencer: on an L2, who orders transactions and whether anyone else can force one in. Stake concentration: how few entities together control enough weight to halt or reorder the chain.
Aave's access control contract is the legible version of the first one. It defines named on-chain roles including pool admin, emergency admin, risk admin, asset listing admin, flash borrower and bridge, each grantable and revocable through a standard access control pattern.1 A protocol whose privileged functions cannot be listed that cleanly still has them. They are just undocumented, which is a worse place to be during diligence.
How each surface gets measured
The consensus layer has a standard yardstick. EY's token due diligence framework describes the Nakamoto Coefficient, proposed by Balaji Srinivasan, as the number of validators that would have to collude with malicious intent to affect the safety or liveness of the blockchain.2 Lower is worse. It is a single number, which is what makes it useful and what makes it misleading.
It measures one subsystem. A chain can carry a healthy validator count while running one client implementation, one dominant cloud region, one bridge, and one multisig holding the upgrade key. Our view is to compute the same style of number per subsystem (consensus, client software, upgrade authority, oracle set, bridge) and report the lowest. That is the number describing the system: an attacker only needs the cheapest of the five.
Building on an L2 means inheriting its centralization
Optimism's own documentation frames fault proofs, activated on OP Mainnet, as moving the OP Stack closer to technical decentralization by allowing anyone to make proposals about the state of the L2 and anyone to challenge those proposals.3 Read that as a statement about the direction of travel and about where the starting point was.
If your token lives on someone else's rollup, that rollup's sequencer is in your risk register whether or not you wrote it there. Two questions cover it. Who runs the sequencer today, and what is the documented path for a user to force a transaction in if the sequencer refuses to include it. Cite the L2's own documentation for both answers rather than your assumptions about them.
The admin capability matrix, and what it usually turns up
The tool we use is a matrix with one row per privileged action and five columns: what it does, which address executes it, what authorization is required, the delay, and the blast radius if the key is abused or compromised. Across the 100+ projects we have advised, a complete matrix usually runs to a dozen or more distinct privileged functions, and two or three of them are news to somebody in the room.
The goal is not zero privilege, since a team should be able to pause a broken market. The goal is that every privileged action is delayed, distributed or governed, with a delay long enough for a holder who disagrees to leave first. Whichever row pairs total-loss blast radius with zero execution delay is the one to fix, however trustworthy the person holding it is.
Where it gets designed in by accident
Key management gets treated as an operational detail to sort out after launch. By then the contracts are deployed, the keys are set, and unwinding the concentration needs a governance vote the concentrated holders control. The window closes at deployment.
The other common miss is counting signers instead of assessing them. A 2-of-3 multisig whose signers are co-founders of one company, in one office, holding keys on identical hardware, is a single point of failure in a costume. Write down what would have to happen for two of the three to be unavailable, coerced or compromised at once. If the honest answer is one event, the control has not done any work yet.
Common questions
How do you measure centralization risk?
One measurement per privileged subsystem, then report the lowest. For consensus, the Nakamoto Coefficient counts how many validators would have to collude to affect safety or liveness.2 For admin authority, count independent signers and the execution delay. For oracles, count independent price writers. For a rollup, document who runs the sequencer and whether a forced inclusion path exists. A single headline number hides the cheapest attack.
What is a Nakamoto Coefficient?
It is a decentralization metric proposed by Balaji Srinivasan and motivated by the Gini Coefficient: the number of validators that would have to collude with malicious intent to affect the safety or liveness of a blockchain.2 A coefficient of four means four colluding parties are enough. It describes consensus only, so it says nothing about who controls upgrades, oracles or bridges.
Is a multisig enough to fix centralization risk?
Not on its own. A multisig converts single key compromise into signer collusion risk, which is an improvement only if the signers can actually fail independently. Three co-founders at one company holding keys on identical hardware are correlated. Pair the multisig with an execution delay long enough for holders to react, publish the signer set, and record the blast radius of every function it can call.
See Tokenomics Audit Services for how this applies in practice.
Sources
- ACLManager.sol, aave-v3-origin
Aave DAO (GitHub), 2026
Deployed access control contract defining pool admin, emergency admin, risk admin, flash borrower, bridge and asset listing admin roles, each grantable and revocable. Read 3 August 2026. - Token due diligence: a structured approach to evaluate digital asset risk
EY, 2024
Defines the Nakamoto Coefficient as the number of validators that would have to collude with malicious intent to affect safety or liveness, attributing the metric to Balaji Srinivasan. - Fault Proofs
Optimism Docs, 2026
Optimism's own framing of fault proofs on OP Mainnet as moving the OP Stack closer to technical decentralization by opening state proposals and challenges to anyone. Read 3 August 2026.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.