A normal smart contract cannot be changed after deployment. That is a strength, because users know the rules will not change, and a weakness, because a bug found after launch cannot be fixed. Upgradeable smart contracts solve this by separating the address users interact with from the code that runs behind it, so the code can be replaced while balances and other state stay in place.
When Upgradeability Makes Sense
- Early-stage protocols that will need fixes and new features as they learn from real users.
- Complex systems where the risk of an undiscovered bug is real and a migration to new contracts would be costly.
- Integrations with external protocols that may change their own interfaces.
It makes less sense for simple tokens and contracts whose value depends on users knowing that nobody can ever change them. Upgradeability is a trade-off: flexibility for the team against trust for users.
Making Upgrades Safe
- Who may upgrade: the upgrade right sits in a multisig, never with one person.
- When: upgrades go through a timelock, so users see the new code before it is live.
- Storage compatibility: the new version must keep the storage layout of the old one. We check this automatically before every upgrade, because a mismatch silently corrupts data.
- Initialisation: upgradeable contracts use initialisers instead of constructors, and an unprotected initialiser is a known attack path.
- Testing the upgrade itself: we test upgrades on a fork of mainnet with real state, not only the new code in isolation.
- A path to immutability: when a protocol has matured, the upgrade right can be removed so the code becomes final.
The technical mechanism is a proxy contract. For a comparison of transparent proxies, UUPS, beacons and diamonds, see smart contract proxy patterns.
Frequently Asked Questions about Upgradeable Smart Contracts
Can any existing contract be made upgradeable?
Not after deployment. Upgradeability has to be built in from the start. For a contract that is already live and immutable, the alternative is a migration: deploying a new version and moving users and state over.
Do upgradeable contracts cost more gas?
Slightly. Every call goes through the proxy, which adds a small overhead. For most applications that cost is negligible compared to the ability to fix problems.
Can we make the contract immutable later?
Yes. Once the code is final, the upgrade right can be renounced, which turns the contract into an immutable one at the same address.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our smart contract development services. Planning an audit? See smart contract audit support.
Plan Your Upgrade Strategy
Tell us how your contracts need to evolve. We will help you decide whether upgradeability fits and set it up safely.