ERC-7528 Native asset ETH address convention (ETH (Native Asset) Address Convention)
Final · Tokens · created 2023-10-03
A convention that fixes 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as the address that denotes ETH wherever ETH is handled like an ERC-20 token. It lets ETH and ERC-20 be recorded in a single event format.
Why it is needed
ETH is a unit of value that is fungible, so it behaves much like an ERC-20 token. Protocols therefore build a standard interface for ERC-20 and try to make their ETH handling resemble that implementation as closely as possible. Some protocols use Wrapped ETH (WETH) to fit the ERC-20 format, while others use native ETH because of gas costs, or because ETH itself is required, as with Liquid Staking Tokens (LST). If different events are created for the ETH case and the ERC-20 case, the data splits, and infrastructure that reads data off-chain has to support the two formats separately. If a single address is fixed to denote ETH wherever ETH is used like ERC-20, both cases can be handled with a single event format.
In depth
Scope
This standard applies to every component of a smart contract system that identifies ERC-20 tokens by address. However, the system must be in a situation where it sometimes uses native ETH in place of an ERC-20 token. The original uses the word 'token' in this context to mean either ETH or ERC-20. The covered targets include both events whose address field represents ETH or an ERC-20 token, and identifiers such as the asset field of an ERC-4626 vault. The same convention is generalized to other EVM chains whose native asset is not ETH.
For ETH, the address must be 0xeeee...
In a field or event that takes an ERC-20 address, if the actual token is ETH, that address field MUST return 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee. This address is a value with all 20 bytes filled with 0xee. Protocols and off-chain data infrastructure can coordinate on the shared understanding that, in an ERC-20 context, this address always means ETH.
Wrapped ETH is excluded
When the token is a wrapped ERC-20 version of ETH that is not enshrined in the protocol, such as WETH9, the contract address of that token itself MUST be used, and the 0xeeee... address MUST NOT be used. In other words, the address in this convention refers only to native ETH, and a token that wraps ETH as an ERC-20 is identified by its own address, exactly like any other ERC-20 token. The original gives 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 as an example, the WETH9 address on Ethereum mainnet.
Checksum notation
The original says to write this address in checksummed form where appropriate. The notation with the EIP-55 checksum applied is 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. The all-lowercase 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee and the checksummed notation differ only in letter case and point to the same address. In human-readable documents and screens, use the checksummed notation, and in comparison logic, treat the two notations as the same address.
Why 0xeeee... was chosen over other addresses
Many existing implementations for the same purpose use addresses such as 0x0, 0x1 or 0xe, because the leading bytes are zero and that saves gas. However, all of these addresses can collide with precompile (a special contract built into the EVM) addresses, and they are less conspicuous as an identifier for ETH. 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee is the most widely used today, is clearly distinguishable, and does not collide with any precompile. The original judges that this advantage outweighs the gas savings of the alternatives.
ERC-4626 liquid staking token use case
One use case the original intends is an ERC-4626 compatible liquid staking token (LST) that uses ETH as its asset. ERC-4626 is the standard for tokenized vaults, and it has an asset field that points to the underlying asset by ERC-20 address. Putting the 0xeeee... address in this field brings vaults whose underlying asset is ETH inside the ERC-4626 format as well. The original explains that this extends the benefits and tooling of ERC-4626 to LSTs and the protocols that integrate with them.
Compatibility and status
The original states that there are no known compatibility issues with other standards. This standard defines no new functions or events and only fixes a convention for a single address value, so it does not change the existing ERC-20 interface or the ERC-4626 interface. The status is Final, it was created on October 3, 2023, and the author is Joey Santoro. This standard requires ERC-20, EIP-55 and ERC-4626.
Things to watch out for
- Re-entrancy risk when using ETH as a token: Treating ETH itself as a token instead of WETH exposes a smart contract system to vulnerabilities of the same class as re-entrancy. Implementers must follow industry-standard development patterns such as checks-effects-interactions when the token is ETH.