Types of Proxy Contracts Detected by Etherscan

Proxy contracts are commonly used on Ethereum to enable upgradeability and reusable logic. While all proxies work by forwarding calls to another contract, there are several distinct proxy patterns in use today.

Etherscan detects and labels these proxy types to help users understand how a contract is structured and how upgrades are handled. Below are the most common proxy types you may encounter on Etherscan.

For a general introduction to proxy contracts, see: Proxy Contracts

OpenZeppelin's Unstructured Storage proxy pattern

Example: FiatTokenProxy

OpenZeppelin’s Unstructured Storage pattern prevents storage collisions in upgradeable smart contracts by storing proxy data in random, hashed storage slots rather than standard, sequential slots.

This technique ensures the implementation logic cannot overwrite crucial proxy data, facilitating safe, flexible smart contract upgrades.

EIP-1967 Transparent Proxy pattern

Example: TransparentUpgradeableProxy

EIP-1967 is the most widely used proxy storage standard today. It defines specific storage slots for storing the logic contract address in proxy contracts, preventing storage collisions between the proxy and the implementation contract. This standard allows tools like Etherscan to identify and interact with both the proxy and its implementation.

The implementation address is typically stored in a fixed storage slot, 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, which is designed to never be allocated by the compiler.

During an upgrade, the implementation address is changed to the upgraded contract.

EIP-1822 UUPS proxy pattern

Example: UUPSProxy

EIP-1822 defines the UUPS proxy pattern. In this setup, the proxy itself is very simple and delegates all logic, including upgrade logic, to the implementation contract. For example, you can find the upgradeTo and upgradeToAndCall functions in this implementation contract.

This makes UUPS proxies cheaper and more flexible, but also means upgrade safety depends entirely on the implementation code. Most UUPS proxies also use EIP-1967 storage slots.

EIP-1967 Beacon Proxy pattern

Example: BeaconProxy

Beacon proxies do not store an implementation address directly. Instead, they reference a separate beacon contract that holds the current implementation address.

For example, in a typical Beacon Proxy, the beacon contract is stored in a fixed storage slot, such as 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50, while the beacon contract itself stores the implementation address.

Multiple proxies can share the same beacon contract, allowing all of them to be upgraded simultaneously simply by updating a single beacon contract. This pattern is commonly used when deploying many similar contracts that need to stay in sync.

Custom proxy implementation

Example: UpgradeBeaconProxy

Custom proxies are upgradeable contracts that do not follow widely recognized standards like EIP-1967 or EIP-1822. They may use unique storage layouts, custom upgrade logic, or nonstandard admin mechanisms.

Smart Account by Safe

Example: GnosisSafeProxy

A Safe smart account proxy is a cost-efficient contract that serves as a user’s wallet while delegating all transaction logic to a central singleton contract.

By separating the proxy from the logic, users save gas compared to deploying a full smart contract wallet, and Safe can upgrade the wallet logic over time without changing user account addresses.