This standard defines minimal ERC-1967 proxies for three patterns: (1) transparent, (2) UUPS, (3) beacon. The proxies support optional immutable arguments which are appended to the end of their runtime bytecode. Additional variants which support onchain implementation querying are provided.
Having standardized minimal bytecode for upgradeable proxies enables the following:
The minimal nature of the proxies enables cheaper deployment and runtime costs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
All of the following proxies MAY have optional data bytecode appended to the end of their runtime bytecode.
Emitting the ERC-1967 events during initialization is OPTIONAL. Indexers MUST NOT expect the initialization code to emit the ERC-1967 events.
The I-variants have logic that returns the implementation baked into their bytecode.
When called with any 1-byte calldata, these I-variants will return the address (left-zero-padded to 32 bytes) and will not forward the calldata to the target.
The bytecode of the proxies before any optional immutable arguments MUST be verified with the following steps:
EXTCODECOPY.If the hash does not match, the implementation address returned MUST NOT be trusted.
The transparent upgradeable proxy is RECOMMENDED to be deployed by a factory that doubles as the account that is authenticated to perform upgrades. An externally owned account may perform the deployment on behalf of the factory. For convention, we will refer to the factory as the immutable account authorized to invoke the upgrade logic on the proxy.
As the proxy's runtime bytecode contains logic to allow the factory to set any storage slot with any value, the initialization code MAY skip storing the implementation slot.
The upgrading logic does not emit the ERC-1967 event. Indexers MUST NOT expect the upgrading logic to emit the ERC-1967 events.
During upgrades, the factory MUST call the upgradeable proxy with following calldata:
Runtime bytecode (20-byte factory address subvariant):
where ________________________________________ is the 20-byte factory address.
Runtime bytecode (14-byte factory address subvariant):
where ____________________________ is the 14-byte factory address.
Runtime bytecode (20-byte factory address subvariant):
where ________________________________________ is the 20-byte factory address.
Runtime bytecode (14-byte factory address subvariant):
where ____________________________ is the 14-byte factory address.
As this proxy does not contain upgrading logic, the initialization code MUST store the implementation at the ERC-1967 implementation storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc.
Runtime bytecode:
Runtime bytecode:
As this proxy does not contain upgrading logic, the initialization code MUST store the implementation at the ERC-1967 implementation storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc.
Runtime bytecode:
Runtime bytecode:
PUSH0 opcodeFor more widespread EVM compatibility, the proxies deliberately do not use the PUSH0 opcode proposed in EIP-3855.
Converting the proxies to PUSH0 variants may be done in a separate future ERC.
The proxies are first optimized for minimal runtime gas before minimal bytecode size.
These proxies made from handcrafted EVM bytecode. While utmost efforts have been made to ensure that they are as minimal as possible at the time of development, it is possible that they can be further optimized. If a variant has already been used in the wild, it is preferable to keep their existing layout in this standard, as the benefits of automatic block explorer verification will outweigh the few gas saved during runtime or deployment.
For historical reference, the ERC-1167 minimal proxy was not the theoretical minimal at the time of writing. The 0age minimal proxy has lower runtime gas costs and smaller bytecode size.
The factory address in the transparent upgradeable proxy is baked into the immutable bytecode of the minimal transparent upgradeable proxy.
This is to save a SLOAD for every proxy call.
As the factory can contain custom authorization logic that allows for admin rotation, we do not lose any flexibility.
The upgrade logic takes in any 32 byte value and 32 byte storage slot. This is for flexibility and bytecode conciseness.
We do not lose any security as the implementation can still modify any storage slot.
It is beneficial to install the transparent upgradeable proxy factory at a vanity address with leading zero bytes so that the proxy's bytecode can be optimized to be shorter.
A 14-byte factory address (i.e. 6 leading zero bytes) is chosen because it strikes a balance between mining costs and bytecode size.
The so-called "I-variants" contain logic that returns the implementation address baked into the proxy bytecode.
This allows contracts to retrieve the implementation of the proxy onchain in a verifiable way.
As long as the proxy's runtime bytecode starts with the bytecode in this standard, we can be sure that the implementation address is not spoofed.
The choice of reserving 1-byte calldata to denote an implementation query request is for efficiency and to prevent calldata collision. Regular ETH transfers use 0-byte calldata, and regular Solidity function calls use calldata that is 4 bytes or longer.
This is for minimal bytecode size and deployment costs.
Most block explorers and indexers are able to deduce the latest implementation without the use of events simply by reading the slots.
This is to avoid compatibility and safety issues with other ERC standards that append extra data to the calldata.
The EXTCODECOPY opcode can be used to retrieve the immutable arguments.
As long as the initialization code is able to initialize the relevant ERC-1967 implementation slot where needed (i.e. for the UUPS proxy and Beacon proxy), there is no need for additional requirements on the initialization code.
The following topics are intentionally out of scope of this standard, as they can contain custom logic:
Nevertheless, they require careful implementation to ensure security and correctness.
No backward compatibility issues found.
To ensure security, the transparent upgradeable proxy factory must implement proper access control to allow proxies to be upgraded by only authorized accounts.
The I-variants reserve all calldata of length 1 to denote a request to return the implementation. This may pose compatibility issues if the underlying implementation actually uses 1-byte calldata for special purposes.
Copyright and related rights waived via CC0.