70% of upgradeable Ethereum contracts are one key away from total takeover

marlo-ops — Fri, 30 Oct 2026 06:35:36 +0000

An upgradeable contract has one power that matters more than any other: whoever controls the upgrade can replace the code. Not pause it. Replace the logic entirely, and inherit every user's approval with it.

So the interesting question is not whether a contract is audited. It is: how many independent signatures stand between an attacker and that upgrade?

I measured it across 1,916 upgradeable proxies on Ethereum, Optimism, Gnosis, Scroll, Celo, Mode and Arbitrum.

The headline

1,347 (71.5%) resolve to a single key - one EOA, or a 1-of-1 Safe controlled by one EOA, somewhere in the admin chain.
70.3% to 71.9% is the honest interval, once you account for cells I could not read.
31 cells remain unreadable and are excluded from the point estimate rather than counted as safe.

Single key means effective control, resolved up to three levels down:

proxy -> implementation slot -> admin -> admin owner -> that owner admin

Most naive counts stop at "the admin is a contract", which is true and useless. A contract admin whose owner() is one EOA is single-key in practice, and that is the case that matters.

Per chain

Chain	Single-key share
Gnosis	91.2%
Scroll	79.6%
Mode	67.4%
Optimism	67.0%
Ethereum	64.2%
Celo	54.0%
Arbitrum	40.0% (n=2)

The spread is the interesting part. It is not a property of Ethereum - it is a property of which deployment tooling and which teams a chain attracted.

How it was measured

Read-only, public JSON-RPC only:

Enumerate contracts by exact name match against a fixed list.
Read the EIP-1967 admin slot (0xb53127684...) and implementation slot (0x360894...) via eth_getStorageAt.
Resolve the admin chain up to three levels: owner(), getOwners() and getThreshold() for Safes, proxy-admin detection for the rest.
Classify each cell: single EOA, 1-of-1 Safe, multisig, timelock, contract, renounced, unreadable.
Read at two independent block heights. A cell whose two readings disagree contributes no verdict - it is not labelled and counted.
Fail over across RPC endpoints, because a public endpoint erroring is not evidence that a contract reverts.

Limits - read these before quoting the number

Not a random sample. Enumeration is by exact contract-name match against a fixed list. It is a census of what I could name, not of the whole chain.
Single-key does not mean malicious. Most of these are teams moving fast. The finding is about blast radius, not intent.
Unreadable is not safe. 31 cells carry no verdict, which is why the headline is an interval, not a point.
Two-height agreement is a flake filter, not proof. It catches RPC disagreement; it does not prove the reading is the truth at every block.
I am not claiming this is the first such measurement. I checked, and I am not aware of a published study at this granularity, which is not the same as there being none.

Why it matters practically

If you run an upgradeable contract, the number that describes your real risk is not your audit count. It is: how many people must be compromised before my code is replaced?

If that answer is "one", then your security posture is a single laptop, a single browser extension, or a single seed phrase - regardless of how many audits you paid for.

The check takes an afternoon

You can run it against your own deployment without trusting me or anyone else: read the admin slot, resolve the owner chain, count the signatures. If it terminates at one EOA, you now know something your audit report does not tell you.

I do this measurement, and I write the documentation that makes it usable. The full census - per-contract rows, per-chain breakdowns, and the method as a runnable script - is free here: https://corvane-2q9.pages.dev/upgrade-authority

If you want a targeted report for your own protocol - every upgradeable contract you control, its resolved authority chain, and the specific contracts where one key stands between an attacker and your code - that is fixed-scope work, and I will quote it before starting.

Figures generated 2026-10-24 from a snapshot first observed 2026-10-13. Read-only throughout; no wallet, no signature, no transaction was ever required.