BeaconProxy Storage Implementation

From reading its clear that proxy contracts run into many limitations around storage layouts.

These issues revolve around Ethereum smart contracts storage models.

Question: how do BeaconProxy implementation allow for additional storage modifications? e.g. you can append variables without any issues - is it using an eternal storage under the hood? If not what is it doing?

" Beacon Proxies have no “proxy-specific” storage or logic (apart from the primary fallback itself)*, and so are immune to function clashing or storage corruption of any kind."


How does this work?

"In this pattern, each proxy holds the address not to its implementation contract, but to a beacon which, in turn, holds the address of the implementation. Whenever the proxy receives a call, it asks the beacon for the current implementation to use" (from

  • How is the storage on these proxies / beacon taken care of? E.g. if I have 3 beacon proxies - I upgrade the implementation contract to append more variables to contract storage then how is this reflected upon my 3 beacon proxies?

This is not accurate. I think the author referred to the proxy-specific storage, such as the implementation address.

Beacon proxies are just as vulnerable as transparent or UUPS proxies to storage layout corruption, so the same measures need to be taken.