Roadmap › Solidity & Smart Contract Development › Module: Advanced Topics
Lessons in this course (11)
9. Upgradeable contracts (proxy patterns)
AdvancedMediumLesson 9 of 11
Contracts are immutable, so upgradeability uses a proxy that holds storage and delegatecalls into a replaceable implementation (logic) contract.
| Pattern | Upgrade logic lives in | Notes |
|---|---|---|
| Transparent proxy | Proxy (admin via ProxyAdmin) | Admin can't call logic functions; slightly more gas |
| UUPS (ERC-1822) | Implementation (upgradeTo + _authorizeUpgrade) | Cheaper; risk of bricking if an upgrade removes upgrade logic |
| Beacon proxy | Beacon contract shared by many proxies | Upgrade many instances at once |
| Diamond (ERC-2535) | Multiple facets | Very large/modular systems; complex |
Rules: use initializers instead of constructors (initialize() with initializer modifier; call _disableInitializers() in the implementation's constructor), never change the order/types of existing storage variables (append only, or use ERC-7201 namespaced storage), protect upgrades with a multisig + timelock, and validate with the OpenZeppelin Upgrades plugin. Upgradeability trades trustlessness for fixability — be transparent with users.