ERC-7528: ETH (Native Asset) Address Convention


  Ethereum Improvement Proposals
        
        
          
            
              
            
          
        

        AllCoreNetworkingInterfaceERCMetaInformational

      



      
        
  
    

  
    
    
    
      ⚠️ Review
    
    
    
      Standards Track: ERC
    
  
  
    
      ERC-7528: ETH (Native Asset) Address Convention
    
    
      
        
      
    
    
      
        
      
    
  

  An address placeholder for ETH when used in the same context as an ERC-20 token.

  	Authors	Joey Santoro (@joeysantoro)
	Created	2023-10-03
	Requires	

  EIP-20, 

  EIP-155, 

  EIP-4626




  


  
    
      
      
        This EIP is in the process of being peer-reviewed. If you are interested in this EIP, please participate using this discussion link.
      

    

  

  
    Table of Contents

    	Abstract
	Motivation
	Specification
	Rationale
    	Considered alternative addresses


  
	Backwards Compatibility
	Security Considerations
	Copyright



  


  
      
      
         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.


Where appropriate, the address should be checksummed. E.g. the EIP-155 checksum is 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.

  
    
      
      
         Rationale
      
      
    

  
    
      
      
         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.

  
    
      
      
         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.


  Citation

  Please cite this document as:

  
  Joey Santoro (@joeysantoro), "ERC-7528: ETH (Native Asset) Address Convention [DRAFT]," Ethereum Improvement Proposals, no. 7528, October 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7528.






      
    
  

  

    Ethereum Improvement Proposals


    
      
        	Ethereum Improvement Proposals


      


      	 ethereum/EIPs





      
        Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.