An interface for better identification and detection of ERC by numbers.
It designates a field in which it's called majorERCIdentifier which is normally known or referred to as "ERC number". For example, ERC-721 aka ERC-721 has a majorERCIdentifier = 721. This ERC has a majorERCIdentifier = 5269.
Calling it a majorERCIdentifier instead of ERCNumber makes it future-proof: anticipating there is a possibility where future ERC is not numbered or if we want to incorporate other types of standards.
It also proposes a new concept of minorERCIdentifier which is left for authors of
individual ERC to define. For example, ERC-721's author may define ERC721Metadata
interface as minorERCIdentifier= keccak256("ERC721Metadata").
It also proposes an event to allow smart contracts to optionally declare the ERCs they support.
This ERC is created as a competing standard for ERC-165.
Here are the major differences between this ERC and ERC-165.
Here is the motivation for this ERC given ERC-165 already exists:
Using ERC numbers improves human readability as well as make it easier to work with named contract such as ENS.
Instead of using an ERC-165 identifier, we have seen an increasing interest to use ERC numbers as the way to identify or specify an ERC. For example
extensions to be a list of ERC numbers.ERC number in the m / purpose' / subpurpose' / ERC' / wallet' path.The instruction_id of an instruction defined by an ERC MUST be its ERC number unless there are exceptional circumstances (be reasonable)struct Token { uint eip; ..., } where uint eip is an ERC number to identify ERCs.ERC-867(Stagnant) proposes to create erpId: A string identifier for this ERP (likely the associated ERC number, e.g. “ERC-1234”).Having an ERC/ERC number detection interface reduces the need for a lookup table in smart contract to convert a function method or whole interface in any ERC in the bytes4 ERC-165 identifier into its respective ERC number and massively simplifies the way to specify ERC for behavior expansion.
We also recognize a smart contract might have different behavior given different caller accounts. One of the most notable use cases is that when using Transparent Upgradable Pattern, a proxy contract gives an Admin account and Non-Admin account different treatment when they call.
In the following description, we use ERC and ERC inter-exchangeably. This was because while most of the time the description applies to an ERC category of the Standards Track of ERC, the ERC number space is a subspace of ERC number space and we might sometimes encounter ERCs that aren't recognized as ERCs but has behavior that's worthy of a query.
In the following description, ERC_5269_STATUS is set to be keccak256("DRAFTv1").
In addition to the behavior specified in the comments of IERC5269:
minorERCIdentifier=0 is reserved to be referring to the main behavior of the ERC being queried.minorERCIdentifier for their optional interfaces, behaviors and value range for future extension.ERC_5269_STATUS for the call of supportERC((any caller), 5269, 0, [])Note: at the current snapshot, the supportERC((any caller), 5269, 0, []) MUST return ERC_5269_STATUS.
OnSupportERC(address(0), 5269, 0, ERC_5269_STATUS, []) event upon construction or upgrade.OnSupportERC with relevant values and when the compliant contract changes whether the support an ERC or certain behavior for a certain caller or all callers.ERC-XXX that is NOT in Final status, when querying the supportERC((any caller), xxx, (any minor identifier), []), it MUST NOT return keccak256("FINAL"). It is RECOMMENDED to return 0 in this case but other values of ercStatus is allowed. Caller MUST treat any returned value other than keccak256("FINAL") as non-final, and MUST treat 0 as strictly "not supported".supportERC MUST be mutability view, i.e. it MUST NOT mutate any global state of EVM.uint256 majorERCIdentifier, there are other alternative options such as:The pros for (1) are that it automatically supports any evolvement of future ERC numbering/naming conventions.
But the cons are it's not backward readable: seeing a hash(ERC-number) one usually can't easily guess what their ERC number is.
We choose the (2) in the rationale laid out in motivation.
We have a bytes32 minorERCIdentifier in our design decision. Alternatively, it could be (1) a number, forcing all ERC authors to define its numbering for sub-behaviors so we go with a bytes32 and ask the ERC authors to use a hash for a string name for their sub-behaviors which they are already doing by coming up with interface name or method name in their specification.
Alternatively, it's possible we add extra data as a return value or an array of all ERC being supported but we are unsure how much value this complexity brings and whether the extra overhead is justified.
Compared to ERC-165, we also add an additional input of address caller, given the increasing popularity of proxy patterns such as those enabled by ERC-1967. One may ask: why not simply use msg.sender? This is because we want to allow query them without transaction or a proxy contract to query whether interface ERC-number will be available to that particular sender.
We reserve the input majorERCIdentifier greater than or equals 2^32 in case we need to support other collections of standards which is not an ERC/ERC.
See TestERC5269.ts.
Here is a reference implementation for this ERC:
See ERC5269.sol.
Here is an example where a contract of ERC-721 also implement this ERC to make it easier to detect and discover:
See ERC721ForTesting.sol.
Similar to ERC-165 callers of the interface MUST assume the smart contract declaring they support such ERC interfaces doesn't necessarily correctly support them.
Copyright and related rights waived via CC0.