Imagine your smart contract in production with hundreds of thousands of USDT in liquidity. A vulnerability—reentrancy—is found in the code. You need to update the logic, but the contract address must remain unchanged—users and integrations are tied to it. The only way out is the proxy pattern for upgradeable contracts. We have implemented such solutions for 30+ projects on Ethereum, Polygon, and Arbitrum. Our experience ensures you avoid common pitfalls—storage collision, improper initialization, and loss of upgrade rights.
Why storage collision is the main threat to proxies
A classic proxy works via DELEGATECALL: the proxy contract calls the implementation but executes code in the proxy's storage context. Storage in the EVM is an array of 2²⁵⁶ slots of 32 bytes each. If the proxy stores the implementation address at slot 0, and the implementation stores, for example, owner at slot 0, a storage collision occurs: the owner variable in the implementation overwrites the implementation address in the proxy. An attacker who can modify the owner in the implementation gains control over the proxy.
EIP-1967 solves this radically: it stores the implementation address in a pseudo-random slot computed as keccak256("eip1967.proxy.implementation") - 1. The probability of collision with user-defined variables in the implementation is astronomically low. OpenZeppelin's ERC1967Proxy implements exactly this standard.
Which proxy pattern to choose for your project?
Transparent Proxy (TUP). The classic OpenZeppelin pattern. Two types of callers: admin (manages upgrades) and users (call logic). Admin cannot call implementation functions—only upgrade. Overhead per call: one extra storage read (SLOAD) to check msg.sender.
UUPS (EIP-1822). The upgrade logic is moved into the implementation contract itself. The proxy becomes thinner—less gas per call. But here's a critical trap: if you deploy a new implementation without the upgradeTo function, the contract permanently loses the ability to upgrade. OpenZeppelin's UUPSUpgradeable adds a check in _authorizeUpgrade—this is the only defense. UUPS can save up to 30% gas compared to Transparent, potentially reducing costs by thousands of dollars monthly.
Beacon Proxy. A single beacon contract stores the implementation address. Many proxy contracts point to this beacon. One upgrade of the beacon updates all proxies simultaneously. Ideal for factories (factory pattern), where you need to create many identical contracts (e.g., pools in an AMM). Beacon Proxy surpasses UUPS in flexibility for factories by more than 2x in mass deployment.
| Pattern | Gas per call | Flexibility | Risks |
|---|---|---|---|
| Transparent | +2100 gas (SLOAD) | High | Storage collision with incorrect layout |
| UUPS | Minimal | High | Loss of upgradability if error |
| Beacon | Medium | Maximum for factories | Single point of failure (beacon) |
For large-scale projects with high transaction loads, the gas savings using UUPS instead of Transparent can reach $5,000 per month, making this pattern optimal for high-volume DeFi protocols.
Why initialization instead of a constructor is critical
constructor() in Solidity is executed once at deployment. In the proxy pattern, the implementation is deployed separately—its constructor runs in the implementation's context, not the proxy's. All variables set in the constructor remain in the implementation and are inaccessible through the proxy.
Solution: replace the constructor with an initialize() function using OpenZeppelin's initializer modifier. It is called once through the proxy and writes data to the proxy's storage.
A common mistake is forgetting to call _disableInitializers() in the implementation's constructor. Without it, an attacker can call initialize() directly on the implementation (not through the proxy) and become its owner. This does not directly affect the proxy, but opens vectors for attack via DELEGATECALL.
| Approach | Execution context | Security | Usage |
|---|---|---|---|
| constructor | Implementation | Low (inaccessible via proxy) | Only for immutable variables |
| initialize | Proxy | High (initializer modifier) | Upgradeable contracts |
How we do it: stack and tools
We use a modern stack: Foundry for development and testing, OpenZeppelin Upgrades Plugin for storage layout validation, and OpenZeppelin Upgrades for safe implementation. Solidity 0.8.x versions, support for all L2s (Arbitrum, Optimism, Base).
For deployment, we use a Gnosis Safe multisig. No private keys in scripts. All upgrades go through a TimelockController with a 3-day delay.
What's included in the work
- Audit of the current storage layout and risk identification.
- Selection of the optimal pattern (Transparent/UUPS/Beacon) with justification.
- Implementation of the contract with initialize() and tests (Foundry/Hardhat).
- Estimation of potential gas savings (up to 30%, equivalent to $5,000 per month for an average project).
- Preparation of deployment scripts via Safe Transaction Builder.
- Contract verification on Etherscan.
- Documentation on upgrade and team training.
- 2-week post-deployment support.
Work process
- Analysis. Study the current contract (or requirements for a new one), storage layout, desired functions.
- Design. Select the pattern, design the storage structure considering possible future changes.
- Implementation. Write the code with initialize(), tests on a mainnet fork.
- Testing. Perform gas profiling, verify no storage collision via OpenZeppelin Upgrades Plugin.
- Deployment. Deploy implementation and proxy through multisig. Call initialize().
- Support. After deployment, provide upgrade scripts and monitoring.
Checklist before deploying an upgradeable contract
- [ ]
_disableInitializers()called in the implementation's constructor. - [ ]
initialize()protected by theinitializermodifier. - [ ] Storage layout validated via OpenZeppelin Upgrades Plugin (
validate). - [ ] ProxyAdmin owner is a multisig, not an EOA.
- [ ] Timelock configured for production.
- [ ] New implementation verified on Etherscan before transfer of upgrade rights.
- [ ] Test: fork mainnet, upgrade, verify storage.
Timelines and contact
Implementation of a proxy pattern for a new contract takes 2-3 business days. Migration of an existing non-proxy contract to an upgradeable architecture (with data preserved via a migration script) takes 3 to 7 days depending on storage complexity. Pricing is determined individually—contact us for a project assessment; we'll propose the optimal turnkey solution. Gas savings when choosing UUPS can reach 30%, translating to up to $5,000 monthly for popular contracts. Get a consultation on your storage layout and pattern selection.
Proxy pattern — the conceptual foundation.