UUPS vs Transparent vs Beacon Proxy Architecture Guide

Frequently Asked Questions

01.What is the difference between UUPS and Transparent proxies?

A Transparent proxy holds the upgrade and admin logic inside the proxy contract itself and routes admin calls separately from user calls to avoid function selector clashes. A UUPS proxy moves the upgrade logic into the implementation contract instead, which makes the proxy smaller and cheaper to deploy but means a faulty implementation that omits the upgrade function can lock the proxy permanently. The choice trades deployment cost against the risk of bricking an upgrade path.

02.How does a Beacon proxy differ from UUPS and Transparent?

A Beacon proxy reads its implementation address from a separate beacon contract rather than storing it locally, so many proxies pointing at the same beacon all upgrade in a single transaction when the beacon is updated. UUPS and Transparent proxies each store their own implementation address, so upgrading a fleet means one transaction per proxy. Beacon is the pattern for large numbers of identical contracts such as per-user vaults or token clones.

03.How do EIP-1967 slots prevent storage collisions?

EIP-1967 fixes the implementation address at the pseudo-random storage slot derived from keccak256 of eip1967.proxy.implementation minus one, a position the Solidity compiler never assigns to ordinary state variables. Because the proxy executes implementation code against its own storage through delegatecall, storing the implementation pointer in a normal slot would risk an implementation variable overwriting it. The derived slot removes that collision class by construction.