# 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. The tradeoff is operational convenience (one upgrade for many proxies) versus concentrated risk (one bad upgrade bricks everything). 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. --- 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 Topics: - [[vulnerability-patterns]]