Abstract

The following standard proposes a convention for using the address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE in all contexts where an address is used to represent ETH in the same capacity as an ERC-20 token. This would apply to both events where an address field would denote ETH or an ERC-20 token, as well as discriminators such as the asset field of an ERC-4626 vault.

This standard generalizes to other EVM chains where the native asset is not ETH.

Motivation

ETH, being a fungible unit of value, often behaves similarly to ERC-20 tokens. Protocols tend to implement a standard interface for ERC-20 tokens, and benefit from having the ETH implementation to closely mirror the ERC-20 implementations.

In many cases, protocols opt to use Wrapped ETH (e.g. WETH9 deployed at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 on Etherum Mainnet) for ERC-20 compliance. In other cases, protocols will use native ETH due to gas considerations, or the requirement of using native ETH such as in the case of a Liquid Staking Token (LST).

In addition, protocols might create separate events for handling ETH native cases and ERC-20 cases. This creates data fragmentation and integration overhead for off-chain infrastructure. By having a strong convention for an ETH address to use for cases where it behaves like an ERC-20 token, it becomes beneficial to use one single event format for both cases.

One intended use case for the standard is ERC-4626 compliant LSTs which use ETH as the asset. This extends the benefits and tooling of ERC-4626 to LSTs and integrating protocols.

This standard allows protocols and off-chain data infrastructure to coordinate around a shared understanding that any time 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE is used as an address in an ERC-20 context, it means ETH.

Specification

This standard applies for all components of smart contract systems in which an address is used to identify an ERC-20 token, and where native ETH is used in certain instances in place of an ERC-20 token. The usage of the term Token below means ETH or an ERC-20 in this context.

Any fields or events where an ERC-20 address is used, yet the underlying Token is ETH, the address field MUST return 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE

Any fields or events where the Token is a non-enshrined wrapped ERC-20 version of ETH (i.e WETH9) MUST use that Token's address and MUST NOT use 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.

Rationale

Smart Contract Systems which use both ETH and ERC-20 in the same context should have a single address convention for the ETH case.

Considered alternative addresses

Many existing implementations of the same use case as this standard use addresses such as 0x0, 0x1, and 0xe for gas efficiency of having leading zero bytes.

Ultimately, all of these addresses collide with potential precompile addresses and are less distinctive as identifiers for ETH.

0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE has the most current usage, is distinctive, and would not collide with any precompiles. These benefits outweigh the potential gas benefits of other alternatives.

Backwards Compatibility

This standard has no known compatibility issues with other standards.

Reference Implementation

N/A

Security Considerations

Using ETH as a Token instead of WETH exposes smart contract systems to re-entrancy and similar classes of vulnerabilities. Implementers must take care to follow the industry standard development patterns (e.g. checks-effects-interactions) when the Token is ETH.

Copyright

Copyright and related rights waived via CC0.