Why "immutable" contracts change
Smart contracts are often described as unchangeable once deployed. Many DeFi services and bridges, however, use a proxy structure that lets them replace the logic after deployment. The purpose is to fix bugs and add features, but the same power can change the rules governing users' funds.
This guide explains who can change code in an upgradeable contract and how much time multisigs and timelocks give users to react. It compares permission structures in a hypothetical table, shows when emergency powers or long withdrawal times make that reaction time meaningless, and lists what to check in a block explorer.
Proxies and implementation contracts
Ethereum.org's page on upgrading smart contracts and OpenZeppelin's proxy pattern documentation explain that users interact with a proxy contract, which forwards calls to an implementation contract holding the actual logic. Funds and data stay in the proxy; when the admin points the proxy to a new implementation address, the service at the same address runs entirely new code.
ERC-1967 standardizes the storage slots where a proxy keeps its implementation and admin addresses. That lets block explorers show the current implementation and the admin when you open a proxy contract. The admin address is the first thing a user should check.
Reaction time by permission structure
The table compares, in a hypothetical example, how much time users have to respond when a malicious or mistaken upgrade is proposed under different permission structures.
| Structure | Who executes an upgrade | Delay before execution | User reaction time | Remaining risk |
|---|---|---|---|---|
| Single key | One private key | Immediate | None | One stolen or misused key changes everything |
| 3-of-5 multisig | Any 3 of 5 signers | Immediate | Almost none | Collusion or theft among 3 signers |
| 4-of-7 multisig + 48-hour timelock | 4 signers, then the delay | 48 hours | About 48 hours | Useless if withdrawing takes more than 48 hours |
| Governance vote + 7-day timelock | Token vote, then the delay | Voting period + 7 days | 7 days or more | A formality if voting power is concentrated |
A timelock queues approved changes and executes them only after a set delay. If the delay is shorter than the time it takes to actually withdraw, its protection weakens.
The time a timelock buys
OpenZeppelin's TimelockController lets proposers schedule operations that can be executed only after a minimum delay. Scheduled operations are public on chain, so anyone can see in advance which implementation is coming and when it is due to execute.
Suppose a user notices a scheduled upgrade six hours after it was queued. With a 48-hour timelock, 42 hours remain to move funds. If those funds sit on a layer 2 where withdrawing to Ethereum takes seven days, the 48-hour timelock offers that user no real protection. A delay must be read alongside the exit route.
The emergency-power exception
Many protocols keep emergency powers that bypass the timelock to respond to hacks or critical bugs. These can pause the service, block certain functions, or in some cases upgrade immediately. Where such powers exist, the timelock's delay applies only to ordinary changes.
Whether an emergency role can only pause or can also change code makes a large difference. A pause can freeze funds but not take them; an immediate upgrade can rewrite the rules for moving them. Check the scope of emergency powers and which addresses hold them in the documentation and the contract code.
Some protocols publish a page listing every privileged role, its holder, and its delay. Where no such page exists, the explorer's read-contract tab and the protocol's governance forum are the next places to look.
Checking in a block explorer
Work through these steps for any protocol you use.
- Open the proxy contract in a block explorer and note the current implementation and admin addresses.
- See whether the admin is a personal wallet, a multisig, or a timelock; for a multisig, check the required signatures and number of signers.
- Check the timelock's minimum delay and whether any operations are currently scheduled.
- Find in the documentation which addresses hold emergency powers and whether those powers can only pause or can also upgrade.
- Compare the time it takes you to withdraw with the timelock delay.
Matching proposals with code
Do not judge an upgrade by its title or summary alone. A proposal called "reward calculation improvements" might also change withdrawal permissions. Check whether the new implementation has verified source code in the explorer, and whether there is a write-up of the differences and an audit.
Contracts with no upgrade path avoid this risk but carry another: bugs cannot be fixed. Neither is simply safer; what matters is whether it is clearly disclosed who can change what, and under which conditions.
Limits of the checks
The structures and delays here are hypothetical. Real protocols may have different admins for different contracts or layered permissions that are hard to map at once, and permissions can themselves be changed by an upgrade.
When checking, use Ethereum.org, OpenZeppelin's documentation, each protocol's current documentation, and block explorer data with their dates. This guide does not recommend using any protocol or trading any token.