Intermediate
Proxies & Upgradeable Contracts — Key concepts
Understand how upgrades work.
Developer Intermediate
3/6 — Proxies & Upgradeable Contracts — Key concepts
Why it matters A bad upgrade can brick funds. The pattern you pick dictates who can upgrade and how storage is laid out. Misordered variables or unguarded initializers are common footguns.
Bitcoin seems to be a very promising idea. I like the idea of basing security on the assumption that the CPU power of honest participants outweighs that of the attacker.
Design lens Treat storage layout as a contract with yourself. Treat upgrade authority as a production secret—wrap it in multisig/timelock and rehearse rotations.
Auditability Clear upgrade paths, events, and storage layout docs make audits easier and reduce human error. Document expected storage slots and roles.
Recovery Plan for mistakes: how to pause, roll back, or rotate admins if keys are lost. Practice before mainnet.
EIP-1967 slot
implementationSlot = keccak256("eip1967.proxy.implementation") − 1
Transparent/UUPS proxies store the implementation here; verify it before and after upgrades.
Key points
- Proxy patterns:Transparent (separate admin), UUPS (logic handles upgrades), Beacon (shared logic). Understand call paths.
- Storage layout:Append-only, no reordering/renaming; reserved gaps; avoiding inheritance reordering pitfalls.
- Initializers:Constructors don’t run behind proxies. Protect initialize so it can’t be re-run.
- Upgrade safety:Access control, rollback tests, storage diff checks, EIP-1967 slots, and UUPS proxiableUUID guard.
- Operational hygiene:Admin keys vs multisig/timelock, pausing, rehearsed runbooks, and post-upgrade verification.