A proxy contract is a smart contract that forwards all calls to a separate implementation contract that contains the actual logic. Because deployed smart contract code can't be changed, proxies are the standard way to make contracts upgradeable: users and other contracts always interact with the proxy's fixed address, while the owner can point the proxy to a new implementation to fix bugs or add features. The data stays in the proxy, so balances and settings survive an upgrade.
How does a proxy contract work?
- delegatecall: the proxy forwards each call using the EVM's
delegatecall, which runs the implementation's code in the proxy's own context, using the proxy's storage and balance. - Implementation address: the proxy stores the address of its current implementation in a fixed storage slot, standardised in EIP-1967, so it never collides with the logic's own variables.
- Upgrade: an authorised account changes that address to a new implementation; from the next call on, the new logic applies.
- Initialisers instead of constructors: because the implementation's constructor never runs in the proxy's context, setup happens in an
initializefunction that must be protected so it can only be called once.
Common proxy patterns
- Transparent proxy: upgrade logic lives in the proxy and is only accessible to the admin, keeping admin and user calls strictly separate.
- UUPS (ERC-1822): upgrade logic lives in the implementation, which makes the proxy lighter and cheaper; an implementation without upgrade logic ends upgradeability.
- Beacon proxy: many proxies read their implementation from one beacon contract, so a whole set of contracts can be upgraded in one step.
- Diamond (ERC-2535): one proxy routes different functions to different implementation contracts ("facets"), for very large systems.
Risks and governance
Upgradeability is power: whoever controls the upgrade can change what the contract does, including how it handles user funds. That key should therefore sit in a multisig, ideally behind a timelock so users can see changes coming, or be governed by a DAO. Technical pitfalls include storage layout collisions between versions, uninitialised implementation contracts, and function selector clashes. Tools such as the OpenZeppelin Upgrades plugins check storage compatibility automatically. Some projects deliberately remove upgradeability once a system is mature. See our smart contract proxy patterns and upgradeable contracts.
Frequently Asked Questions about Proxy Contracts
Why can't a smart contract just be updated?
Deployed bytecode on Ethereum is immutable. A proxy keeps the address and data fixed while swapping the logic behind it, which gives the effect of an update.
What is the difference between a transparent proxy and UUPS?
In a transparent proxy, the upgrade function lives in the proxy itself. In UUPS, it lives in the implementation contract, which saves gas but means every new version must include the upgrade function correctly.
Are upgradeable contracts less secure?
They add a trust assumption: users must trust whoever can upgrade. With a multisig, timelock and transparent governance, that risk can be made acceptable; without them, an upgrade key is a single point of failure.
What is a storage collision?
When a new implementation arranges its variables differently from the old one, so existing data is read as the wrong variable. Following storage layout rules and automated checks prevents it.