Upgrade risk
who can change the code after you deposit
An upgradeable contract means the code you reviewed can be replaced. The audit you relied on applies to the original implementation. A single EOA holding the upgrade key - on any protocol with significant TVL - is a critical risk that no audit resolves.
Analyse a protocolUpgrade authority identification · proxy detection · EVM
Every scan is powered by the XemaS Semantic Intelligence Platform · answers carry their evidence and coverage state
The code you approved is not necessarily the code running now
Smart contracts are often described as immutable, but the majority of production DeFi contracts use upgradeable proxy patterns. The proxy contract - the address you interact with - is permanent and its storage persists. But the implementation contract it delegates logic to can be replaced at any time by whoever holds the upgrade key.
This means a contract audit is not a permanent security certificate. It is a point-in-time assessment of a specific implementation. An upgrade that happens after an audit makes the audit inapplicable to any changed functions. New code in an upgraded implementation has exactly zero audit coverage unless a new audit covers it explicitly.
The identity and structure of the upgrade key holder is therefore a first-order security question for any upgradeable protocol. It determines who can change what you deposited into, and under what conditions.
Five upgrade authority models and their risk levels
| Authority type | Description | Risk | Key concern |
|---|---|---|---|
| Single EOA | One externally owned address holds the upgrade key | Critical | One private key compromise or insider threat = full protocol replacement |
| Multisig (low threshold) | 2-of-3 or 3-of-5 multisig controls upgrades | High | Small threshold; if signers are not independent, the protection is weaker than it appears |
| Multisig (high threshold) | 5-of-9 or higher with disclosed independent signers | Medium | Meaningful but still bypasses community governance; signers can collude |
| Governance + timelock | Upgrades require a governance vote and pass through a timelock | Low | Community has visibility and exit window; still requires healthy governance (see Governance Risk) |
| Immutable (no upgrade) | Contract cannot be upgraded after deployment | N/A - fixed | No upgrade risk; bugs in the original code cannot be patched without a full migration |
Five-step upgrade risk assessment
Determine whether the contract is upgradeable
Does the contract use a proxy pattern (transparent proxy, UUPS, beacon proxy)? An upgradeable contract has an admin address that can replace the implementation. A non-upgradeable contract cannot be modified after deployment. This is detectable from the contract's bytecode and storage layout.
Identify who holds the upgrade key
If the contract is upgradeable, read the admin or owner slot. Is it a single EOA, a multisig, a timelock, or a governance contract? A single EOA holding the upgrade key on a contract with $100M in TVL is a critical risk regardless of who owns that address.
Check whether upgrades require a timelock
Even if upgrades go through governance, does the upgrade execution pass through a timelock? A governance vote that executes immediately after passing gives users no window to review the new implementation before it goes live. A timelock of at least 48 hours is the minimum for any meaningful protection.
Verify the implementation contract is verified
If the contract is a proxy, the proxy itself may be verified but the implementation it points to may not be. Verified source code is a prerequisite for any meaningful security review. Unverified implementation contracts cannot be audited.
Check when the last upgrade occurred and what changed
Has the contract been upgraded since its original audit? An upgrade resets the security baseline for the changed code. If the implementation was upgraded after an audit, the audit no longer covers the current code. Review the changelog for any post-audit upgrades.
Free · No sign-up required
What analysts get wrong about upgrade risk
Treating a proxy contract audit as a permanent guarantee
An audit of a proxy contract is an audit of the implementation at the time the audit was conducted. If the implementation is later upgraded, the audit does not cover the new code. Any upgrade - even a minor one - resets the security baseline for the changed functions.
Assuming a multisig upgrade key is safe because the team is trusted
Team trust is not a security model. A 3-of-5 multisig where all five signers are employees of the same company, using the same device type and the same password manager, provides much weaker protection than the threshold implies. Operational security of the signers is as important as the threshold.
Not distinguishing UUPS from transparent proxy
In a UUPS (Universal Upgradeable Proxy Standard) pattern, the upgrade logic lives in the implementation contract. If the implementation is upgraded to a version that removes the upgrade function, the contract becomes permanently immutable - without the admin intending that. In a transparent proxy, the upgrade logic lives in the proxy and is always available to the admin.
Overlooking upgrade risk in composable protocols
A protocol that calls another protocol's contract inherits that contract's upgrade risk. If the upstream contract is upgradeable and its upgrade key holder is compromised, the attacker can modify the upstream contract in a way that breaks or steals from the downstream protocol.