Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Centralization risk is the power of a small set of actors to change a contract system, block its operation, or move value. It may be an intentional governance design rather than a coding defect. The security question is whether the disclosed trust model matches the deployed authority and whether one compromised or malicious actor can cause unacceptable harm.
List every capability that can mint or burn assets, change fees, pause or blacklist users, withdraw reserves, alter oracle or bridge configuration, grant roles, or replace implementation code. Include proxy admins, beacons, timelocks, guardians, and off-chain signers. A harmless-looking configuration setter can be critical if downstream logic trusts its value.
Then identify who holds each capability now and who can grant it later. An onlyRole check does not decentralize a function when one account controls that role's admin. Likewise, a multisig is only as strong as its threshold, signer independence, modules, and recovery process.
Measure blast radius, speed, and reversibility. Hard supply or fee caps constrain an administrator even after key compromise. A timelock can give users and monitors time to inspect a queued action, but emergency bypasses and upgradeable timelocks can restore immediate authority.
OpenZeppelin's access-control guide explains that a timelock delays maintenance actions but can also lock a system indefinitely if required proposers or executors become unavailable. Centralization therefore includes liveness risk as well as malicious-action risk.
Upgradeable systems require a separate authority review. OpenZeppelin's upgrade documentation notes that transparent proxies, UUPS implementations, and beacons place upgrade power in different locations. Inspect the actual proxy type and deployed admin rather than assuming a modifier in the implementation controls upgrades.
Create a role-to-function matrix and a function-to-asset matrix. Resolve proxy implementation and admin slots on every supported chain. Verify role membership, multisig thresholds and modules, minimum delays, cancellers, and any alternate emergency route from deployed state.
Test the strongest legal action each role can take. Try maximum fee and mint values, malicious implementations, simultaneous role loss, pause and unpause failures, and timelock cancellation or delayed execution. Assert caps and delays at the contract level, not only in a governance interface.
Apply least privilege, separate routine operations from role administration, and put high-impact actions behind independent signers and an appropriate delay. Bound dangerous parameters in code. Publish addresses, thresholds, delays, and upgrade procedures so users can verify them.
Renouncing ownership removes one control path but can also remove recovery and does not affect hidden roles or proxy admins. A multisig changes the compromise threshold; it does not make its decisions benign.
Source analysis can enumerate explicit privileged functions and upgrade hooks. Without verified deployments and current chain state, it cannot establish who controls those roles, whether an address is a safe multisig, or whether off-chain signers are independent.
Is centralization always a vulnerability?
No. It is a trust property. It becomes a security finding when authority is undisclosed, broader than intended, weakly controlled, or inconsistent with protocol claims.
Does a timelock make an admin safe?
It reduces surprise by delaying actions. It does not limit what can execute after the delay or secure the proposer and cancellation paths.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Review smart contract liveness failures caused by gas growth, external-call reverts, griefing, and unrecoverable state.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Review accounting assumptions for fee-on-transfer, rebasing, and other non-standard ERC-20 tokens, with test and mitigation guidance.
Understand transaction-ordering risk, sandwich attacks, the conditions that make them profitable, and practical review and mitigation techniques.
Learn how weak swap bounds expose users and vaults to adverse execution, how to review integrations, and where minimum outputs and deadlines fall short.