Interfaces for Named Token | Ethereum Improvement Proposals

Abstract

Extends tokens using uint256 tokenId to support tokenName of type string and to convert back to tokenId.

Motivation

For Marketplaces, Explorers, Wallets, DeFi and dApps to better display and operate NFTs that come with a name.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Compliant contracts MUST support tokenName and a mapping between tokenName and tokenId in one of the following ways:
- 1a all compliant contracts are RECOMMENDED to implement the following interfaces: IERC_NamedTokenCore,
```
interface IERC_NamedTokenCore {
  function idToName(uint256 _tokenId) external view returns (string);
  function nameToId(string memory _tokenName) external returns (uint256);
}
```

and it should satisfy the behavior rules that: - 1a.1. when a new name is introduced, it is RECOMMENDED to emit an event newName(uint256 indexed tokenId, string tokenName). - 1a.2. tokenId and tokenName MUST be two-way single mapping, meaning if tokenId exists, tokenName MUST exist and vice versa and tokenId = nameToId(idToName(tokenId)) and tokenName = idToName(nameToId(tokenName)) MUST hold true.

1b. if the compliant contract does not implement IERC_NamedTokenCore, it MAY follow the default mapping rule between tokenId and tokenName uint256 tokenId = uint256(keccak256(tokenName)).

All methods involving tokenId for a compliant contract are RECOMMENDED to have a counterpart method ending with ByName that substitutes all parameters of uint256 tokenId with string memory tokenName, and the behavior of the counterpart method MUST be consistent with the original method.
A compliant contract MAY implement one or more of the following extra interfaces

interface IERC_NamedTokenExtension {
  function isValidTokenName(string memory _tokenName) external view returns (string);
  function normalizeTokenName(string memory _tokenName) external view returns (string memory);
}

Rationale

We allow a default way to map tokenId and tokenName for convenience, but we also allow contracts to implement their own ways of mapping tokenId and tokenName for flexibility.
We consider providing an interface for

Backwards Compatibility

This proposal is fully backwards compatible with token contracts using uint256 tokenId as the unique identifier.

Security Considerations

This proposal assumes that both tokenName and tokenId are unique amongst all tokens.

If token names are not normalized, two distinct token names may confuse users as they look alike. Contract developers shall declare a normalization mechanism if non-unique tokenName is allowed using IERC_NamedTokenExtension.