Secure Proxy Models: Understanding Beacon Proxies

Secure Proxy Models: Understanding Beacon Proxies


3 min read

The Beacon proxy is a common proxy pattern that was first introduced by Dharma wallet in 2019. It was popularized by its ability to allow multiple contracts to upgrade their implementation contracts by just updating a single contract. This is efficient because other proxy patterns like TPUS require the individual contracts to be updated with the new implementation contract one by one.

The Beacon pattern is different because each proxy holds the address to a beacon, instead of an implementation contract. Whenever the proxy receives a call it asks the beacon for the current implementation to use. All proxies that share a beacon can be updated in a single transaction by changing the implementation the beacon uses. Below is a diagram explaining the following:

Security Concerns and Safer Upgrades

With Beacon proxies, the expectation is that only the owner address, which by default is the address that deployed the beacon, will be able to make an upgrade. When attempting to upgrade a smart contract deployed using the beacon pattern, a call is made to the beacon contract to update the implementation contract address stored there.

Once this beacon is updated, all proxies referring to this beacon will simultaneously start referring to the new contract, and the proxies will be upgraded to the new implementation at once. It's worth noting that typical upgradeable contracts should not have a constructor, as the constructor of the implementation contract can never be run in the context of the proxy contract.

Leaving a contract without initializing it can pose a security threat. However, calling the _disableInitializers method in the constructor renders the implementation contract non-initializable, which is much safer than leaving the implementation without a constructor and not initialized. This occured in the the $14 million hack of the Furucombo protocol in 2021.

Comparison with Diamond Contracts

In comparison Diamond contracts allow us to have multiple implementation contracts per proxy while beacons do the direct opposite they have multiple proxies per implementation. The downside to Diamond is if you find a bug in your implementation and deploy a fix you would have to upgrade each individual poxy, which is expensive and cumbersome and may lead to an exploit of the other contracts before you’re to fix them.

Benefits of Beacon Proxy over Other Proxy Models

In contrast to various other proxy models, where every proxy must be updated when the implementation contract is upgraded, the Beacon proxy requires only the beacon contract itself to be modified. The admin has the ability to set both the beacon address within the proxy and the implementation contract address within the beacon. This flexibility enables a wide array of possibilities, particularly when managing substantial numbers of proxy contracts that must be organized in diverse groupings.


The Beacon proxy pattern, introduced in 2019, has revolutionized contract upgrades by allowing multiple contracts to be updated through a single beacon, unlike other cumbersome models like TPUS and Diamond contracts. This efficiency is coupled with robust security measures, such as the ability for only the owner address to make an upgrade and the emphasis on secure initialization through the _disableInitializers method. The flexibility in managing large quantities of proxy contracts and the benefits over other proxy models make the Beacon proxy an innovative and essential tool in smart contract development, highlighting the importance of both efficiency in upgrades and the significance of secure initialization.

Rivanorth is a global boutique Web3 cybersecurity company. We specialise in smart contract audits and blockchain security advisory. Visit to find out more.

You build the future. We help you secure it.