USDC Has a Different Upgrade Key on Every Chain, and Its Own owner() Names None of Them

Why the honest answer is better than the one people ask for

The request that starts this work is always some version of the same sentence. Show me all the entities ultimately controlling these assets, across every chain, and explain the evidence for each step. The first two thirds of that are a good specification. The last hop is not achievable and never will be.

A control path ends at a public key. Whether the corresponding private key sits on a laptop, inside a hardware security module, or is split across a nine-party threshold scheme in three jurisdictions is a fact about an off-chain arrangement. No block contains it. No amount of graph analysis recovers it. The commercial attribution products resolve that hop by combining exchange deposit patterns, off-chain leaks and human research, and they do not show you which of those produced any given label. That is not a criticism of their accuracy. It is an observation that you cannot audit it.

So the vocabulary we built stops where the evidence stops and gives the stopping point a name. A control path that ends at an account with no code is typed as an unattributed key, and a SHACL rule rejects any attempt to link an account to a legal entity unless the supporting assertion carries an off-chain attestation as its evidence class. A storage read can never support that link, and the shapes enforce it rather than merely recommending it. The result is a graph that tells you exactly how far the chain can take you, which is a great deal further than most people assume, and then refuses to take one step more.

What the census measured

The population is 6,316 contracts, drawn from the DefiLlama protocol list and the CoinGecko token list, spanning Ethereum, Arbitrum, Optimism, Base, Polygon, BSC and Gnosis. For each contract we read the code size, five different proxy storage slots covering EIP-1967, the legacy zeppelinos layout and EIP-1822, and the return values of symbol, owner, admin and implementation. Everything was read from keyless public nodes with each value confirmed by more than one independent provider.

1,827 of the 6,316 contracts, 28.9 per cent, are upgradeable. 656 of those have an upgrade authority we can resolve. A separate 1,068 contracts have deliberately renounced ownership, returning the zero address from owner(), which the ontology records as a positive fact rather than a missing value, because giving up a capability is the strongest guarantee a contract can offer.

Three defects then fall out of the data. The first is the delegation hazard. On a transparent proxy, calls from anyone other than the admin are forwarded to the implementation, so a caller asking owner() is answered by the implementation about the implementation. 390 contracts return a different account this way than the account holding the upgrade power. Any dashboard, explorer or compliance tool reading owner() to determine control is being told the wrong thing, and it is being told it by the contract itself.

The second is that the admin slot is only the first hop. In most real deployments that slot holds an admin contract, which is itself owned by a multisig or a governance contract. For 556 of 656 contracts the path continues past the slot. Reading one hop and stopping produces a confident, precise and wrong answer five times out of six.

The third is narrower but sharper. 37 contracts are upgradeable through storage slots outside EIP-1967. The legacy zeppelinos slots, keccak256 of org.zeppelinos.proxy.admin and .implementation, predate the standard and remain in use under some very large deployments, including every native USDC contract. Tooling that checks the EIP-1967 slot alone reports these contracts as immutable. They are not.

Where the paths actually end

Walking all 656 paths to their terminal node gives the distribution the question was really after. 335 contracts, 51.1 per cent, end at a multisig whose quorum is enforced and published by the chain. 109, 16.6 per cent, end at a timelock, which constrains when control is exercised rather than who holds it. 73 end at a contract we did not classify further, and 7 at renounced control. And 132, 20.1 per cent, end at a single externally owned account.

Two qualifications sharpen that last number in opposite directions. Eight of the 335 multisigs have a threshold of one, meaning any single signer acts alone, so the honest count of effective single-signature control is 140 of 656, or 21.3 per cent. Among those eight is the largest contract in the population by the protocol TVL attached to it, whose terminal controller is a 1-of-2, verified identically across three independent providers. A quorum of one is not a quorum, and a label that says multisig without the threshold is not information.

Pulling the other way, a bare key is not evidence of carelessness. Institutional issuers routinely hold keys under multi-party computation or hardware custody with internal approval policies that are, in substance, quorums. The finding is not that these are weak. It is that they are invisible. A well-run five-of-nine custody policy and a single laptop present identically on chain, and the difference between them is exactly the thing an auditor, a counterparty or a regulator would want to see.

USDC, one asset, seven chains, seven answers

The composition claim becomes concrete on the second largest stablecoin in the world. Native USDC on Ethereum, Base, Arbitrum, Optimism, Polygon and Avalanche has six different upgrade authorities. No signer is reused. All six are externally owned accounts with no code, so no quorum is enforced or visible on any of them. On all six chains, owner() returns an account other than the one that can replace the code.

The asymmetry is the point. On Solana the issuer's control structure is enforced and published by the chain, and mint authority and freeze authority are separated across two different multisigs with different signers, which is a real separation of duties that anyone can check. On the EVM chains that separation cannot exist, because the account that can replace the code can mint and freeze and anything else it writes into the new implementation. Same issuer, same asset, two entirely different assurance postures, and you can only see it if both chains are one queryable world.

This is not an accusation. Circle is a regulated issuer and those EVM keys are near-certainly held under serious institutional custody. The observation is narrower and, we think, more useful: on one chain that fact is verifiable by a counterparty in a single RPC call, and on six others it is not verifiable at all.

How the artefact is built

The load-bearing decision is that control is never a property. Saying a contract has an owner throws away everything that matters. Instead every edge in the graph is a control assertion: a named observation run claims, at a recorded block, that one account holds a named capability over another, on the basis of a stated evidence class, having read a stated locator. The evidence classes are a SKOS scheme with strengths attached, and the one that earns its place is delegated view function return, the class for a value read through a proxy, which is the single most common source of wrong ownership reporting in this field.

Identifier schemes declare their own conformance rules as data rather than having them hard-coded, so an EIP-55 checksummed address, an unchecksummed hexadecimal address and a base58 account address each carry their own pattern, case rule and check algorithm. Accounts are identified by CAIP-10, because a bare 0x address is not an identifier for anything: the same twenty bytes denote different contracts on different chains, and treating them as one thing is how cross-chain analysis goes wrong at the first step.

The SHACL layers are the defect classes, so the validation report is the findings table. Layer 3 contains the rule that stops us doing what the attribution vendors do, and the rule that fires when a proxy's slot-derived controller disagrees with its own view function. That second rule fires exactly 390 times, matching the independent Python count precisely.

What we are not claiming

L2BEAT resolves contract permission graphs and did so before this work. Its discovery tooling is open source under MIT, it is careful and curated, and for deep analysis of a rollup or a bridge it is the right instrument. This study does not duplicate it. EthOn is the incumbent Ethereum ontology, published under CC BY 4.0 and archived since October 2018. Measured by grep over its Turtle file it contains zero occurrences of proxy, upgrade, admin, owner, multisig and timelock, because it predates EIP-1967 entirely. Our Account class is declared a subclass of EthOn's, and the alignment is deliberately weak. GraphSense does open clustering on UTXO chains, which is a different problem.

We also removed a number from an earlier draft. It totalled the reported value of every protocol whose contract resolves to a single key and produced a headline figure above two billion dollars. That number is not defensible, because the value figure is protocol-level while the contract measured is usually a token contract, and controlling a token contract is not the same as controlling a protocol's deposits. Where the two genuinely coincide, as with a gold-backed token whose proxy is the token itself, the case is stated individually instead. The build report explains why it was cut.

The same build report lists four bugs this pipeline had. A SHACL layer that reported a clean pass while 390 real violations sat in the data, because the SKOS hierarchy was supplied through a parameter that does not expose it to constraint queries. An address decoder that invented a controller out of a function return that was not an address. A decoder change that then labelled 5,691 ordinary contracts as having renounced ownership when their storage slot was merely empty. And an account carrying two different canonical addresses, caught by SHACL and not by a regular expression. Each is documented because a repository that reports only its successes is not evidence of anything.

If this touches your work

Three groups have an immediate use for this. Anyone running a register, explorer or analytics product can be told which of their control records this census disagrees with, contract by contract, with the storage slot and block for each. Anyone holding or accepting a tokenised asset can ask a question they probably have not asked, which is not who issues this but who can rewrite it, and get an answer with its evidence attached. And anyone writing assurance requirements for digital assets can use the distinction this artefact is built around, between a control structure that is enforced on chain and one that is merely asserted off it.

The repository is public, the pipeline needs no API keys, and every headline is computed twice with a governance report that exits non-zero if the two methods disagree. If you want the rows that concern you, or a control census of a specific set of contracts, write to Fabio Rovai at fabio@thetesseractacademy.com and say which chains and which addresses.