ERC-926: Address metadata registry


  Ethereum Improvement Proposals
        
        
          
            
              
            
          
        

        AllCoreNetworkingInterfaceERCMetaInformational

      



      
        
  
    

  
    
      🚧 Stagnant
    
    
    
    
    
      Standards Track: ERC
    
  
  
    
      ERC-926: Address metadata registry
    
    
      
        
      
    
    
      
        
      
    
  

  

  	Authors	Nick Johnson <nick@ethereum.org>
	Created	2018-03-12
	Requires	

  EIP-165




  


  

  
    Table of Contents

    	Abstract
	Motivation
	Specification
	Provider specification
	Rationale
	Backwards Compatibility
	Implementation
	Copyright



  


  
      
      
         Abstract
      
      
    

This EIP specifies a registry for address metadata, permitting both contracts and external accounts to supply metadata about themselves to onchain and offchain callers. This permits use-cases such as generalised authorisations, providing token acceptance settings, and claims registries.

  
    
      
      
         Motivation
      
      
    

An increasing set of use cases require storage of metadata associated with an address; see for instance EIP 777 and EIP 780, and the ENS reverse registry in EIP 181. Presently each use-case defines its own specialised registry. To prevent a proliferation of special-purpose registry contracts, we instead propose a single standardised registry using an extendable architecture that allows future standards to implement their own metadata standards.

  
    
      
      
         Specification
      
      
    

The metadata registry has the following interface:

interface AddressMetadataRegistry {
  function provider(address target) view returns(address);
  function setProvider(address _provider);
}





setProvider specifies the metadata registry to be associated with the caller’s address, while provider returns the address of the metadata registry for the supplied address.


The metadata registry will be compiled with an agreed-upon version of Solidity and deployed using the trustless deployment mechanism to a fixed address that can be replicated across all chains.

  
    
      
      
         Provider specification
      
      
    


Providers may implement any subset of the metadata record types specified here. Where a record types specification requires a provider to provide multiple functions, the provider MUST implement either all or none of them. Providers MUST throw if called with an unsupported function ID.


Providers have one mandatory function:


function supportsInterface(bytes4 interfaceID) constant returns (bool)





The supportsInterface function is documented in EIP-165, and returns true if the provider implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a provider returns true for supportsInterface(), it must implement the functions specified in that interface.


supportsInterface must always return true for 0x01ffc9a7, which is the interface ID of supportsInterface itself.


The first argument to all provider functions MUST be the address being queried; this facilitates the creation of multi-user provider contracts.


Currently standardised provider interfaces are specified in the table below.


| Interface name | Interface hash | Specification |
| — | — | — |


EIPs may define new interfaces to be added to this registry.

  
    
      
      
         Rationale
      
      
    

There are two obvious approaches for a generic metadata registry: the indirection approach employed here, or a generalised key/value store. While indirection incurs the cost of an additional contract call, and requires providers to change over time, it also provides for significantly enhanced flexibility over a key/value store; for that reason we selected this approach.

  
    
      
      
         Backwards Compatibility
      
      
    

There are no backwards compatibility concerns.

  
    
      
      
         Implementation
      
      
    

The canonical implementation of the metadata registry is as follows:

contract AddressMetadataRegistry {
  mapping(address=>address) public provider;
  
  function setProvider(address _provider) {
    provider[msg.sender] = _provider;
  }
}




  
    
      
      
         Copyright
      
      
    

Copyright and related rights waived via CC0.


  Citation

  Please cite this document as:

  
  Nick Johnson <nick@ethereum.org>, "ERC-926: Address metadata registry [DRAFT]," Ethereum Improvement Proposals, no. 926, March 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-926.






      
    
  

  

    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.