# beacon proxy patterns share upgrade risk across all dependent proxies In a beacon proxy pattern, multiple proxies reference a single beacon contract that stores the implementation address. This means a single upgrade to the beacon immediately affects every proxy depending on it. The beacon admin effectively holds root-level privileges across the entire system, a malicious or compromised upgrade impacts all contracts simultaneously. This amplification distinguishes beacon proxies from standard transparent or UUPS proxies, where each proxy upgrades independently. In transparent and UUPS patterns, a bad upgrade's blast radius is limited to a single proxy. With beacons, the blast radius is the entire system: every proxy depending on that beacon is simultaneously affected. The beacon owner can also push upgrades without individual proxy consent, meaning no proxy operator can opt out of a malicious or buggy upgrade. Since [[access control vulnerabilities are the leading cause of smart contract financial losses]], the beacon admin role requires the highest level of access control protection; compromise of the beacon admin is effectively compromise of every dependent proxy. Mitigation requires multi-signature wallets or DAO governance over the beacon to prevent unilateral upgrades. --- Relevant Notes: - [[delegatecall executes code from another contract using the callers storage context]]: the mechanism underlying all proxy patterns - [[storage layout must remain consistent across proxy implementation versions]]: a constraint that applies to every proxy the beacon controls - [[access control vulnerabilities are the leading cause of smart contract financial losses]]: beacon admin is a critical access control surface - [[uninitialized proxy contracts are vulnerable to re-initialization attacks that hijack ownership]]: initialization vulnerabilities apply to every beacon-managed proxy - [[EIP-1822 UUPS upgrade logic in implementation enables permanent proxy bricking if implementation is destroyed or uninitialized]]: UUPS limits blast radius to one proxy per upgrade; beacons affect all dependents simultaneously - [[contract upgrade procedures create temporary vulnerability windows when initialization must occur after a state change that disables reentrancy protection]]: upgrade procedure windows in beacon systems affect every dependent proxy simultaneously, amplifying the Optimism-style upgrade window pattern Topics: - [[vulnerability-patterns]]