Contract admin keys and upgrade risk

Fixed code, changeable contracts

A deployed contract’s code cannot be edited. Yet many protocols, tokens and bridges can be changed after launch, because their code was written to allow it. That lets teams fix bugs and add features. It also means the safety of the funds depends on whoever controls those changes as much as on the code you can read today.

The powers to look for

• Ownership. Many contracts have a single owner with special functions: setting fees, adding minters, withdrawing funds, changing price feeds. Ownership can be transferred, and a two-step pattern, where a pending owner must accept, prevents transfers to a mistyped address.
• Roles. Contracts with role-based access control give separate powers, such as minting or pausing, to different addresses, plus an admin role that can grant the others.
• Pause. A pauser can stop transfers or withdrawals: useful in an emergency, dangerous in the wrong hands.
• Mint and blacklist. Token issuers can often create new supply or freeze addresses.
• Upgrades. An upgradeable contract can have its code replaced entirely, which covers every power above and any new ones.

How upgradeable proxies work

An upgradeable contract is usually a proxy: a small contract that holds the address, the balances and the storage, and forwards every call to a separate implementation contract using delegatecall. Upgrading means pointing the proxy at a new implementation. Users keep calling the same address while the code behind it changes.

The EIP-1967 standard fixes where a proxy records its implementation and admin, in storage slots derived from well-known strings, so anyone can read them:

implementation slot = keccak256("eip1967.proxy.implementation") − 1
                    = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc

• Transparent proxies keep the upgrade power in the proxy itself, held by an admin, usually a ProxyAdmin contract with its own owner.
• UUPS proxies put the upgrade function in the implementation, guarded by whatever access control it uses, usually the owner. Upgrading to code without that function fixes the contract permanently.
• Beacon proxies read their implementation from a beacon contract, so a single upgrade of the beacon changes every proxy that follows it.

Initialisation and other traps

Proxies cannot use a constructor, so they are set up by an initialise function that must be called exactly once. If that call is missed, anyone can make it and become the owner. In November 2017 a user took ownership of an uninitialised library contract that Parity multisig wallets depended on and then destroyed it, permanently freezing the funds in every one of those wallets.

Upgrades also go wrong in ordinary ways. A new implementation that lays out storage differently can corrupt existing balances, and an unreviewed upgrade can add powers nobody announced; bridges have lost large sums to faulty upgrades. A pending ownership transfer to an unfamiliar address always deserves a question.

What a trustworthy setup looks like

• No single key. Admin powers sit with a multisig of independent signers, not an ordinary externally owned account.
• A delay. Upgrades and sensitive changes pass through a timelock, such as OpenZeppelin’s TimelockController, which makes each change wait a minimum time after it is scheduled. The delay should be long enough for users to notice a change and withdraw before it executes.
• A narrow emergency path. A fast pause held by a separate multisig can limit damage, but it should only be able to stop things, never move funds or upgrade code.
• Published and matching. The team documents which addresses hold which powers, and that documentation matches the chain.

Renouncing ownership, which sets the owner to the zero address, disables the owner functions for good. That removes one admin risk and also any way to fix a bug, and it does nothing about a separate proxy admin, which can still upgrade the code.

Check a contract yourself

1. Paste the address into the contract admin inspector. It reads the EIP-1967 implementation, admin and beacon slots, the owner and pending owner, and the pause state straight from the chain.
2. See who holds each power. The inspector says whether the owner is a single key or a Safe, and shows a Safe’s threshold and owners.
3. If the owner or admin is a timelock, read its minimum delay from a block explorer (getMinDelay on OpenZeppelin’s timelock) and find out who can schedule changes through it.
4. If the inspector finds no standard admin surface, the contract may be immutable or may use roles. Read the verified source before concluding that nobody can change it.
5. Keep watching. A contract admin monitor re-reads these fields on every block and alerts you to upgrades, ownership transfers, role grants and pauses, including changes made without an event, and a timelock monitor warns you when a change is scheduled, while there is still time to act.