mirror of https://github.com/status-im/EIPs.git
74 lines
3.8 KiB
Markdown
74 lines
3.8 KiB
Markdown
---
|
|
eip: 926
|
|
title: Address metadata registry
|
|
author: Nick Johnson <nick@ethereum.org>
|
|
type: Standards Track
|
|
category: ERC
|
|
status: Draft
|
|
created: 2018-03-12
|
|
dependencies: 165
|
|
---
|
|
|
|
## 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](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md), 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](https://creativecommons.org/publicdomain/zero/1.0/).
|