ERC-7632: Interfaces for Named Token

Enable tokens to have a string name and be able to convert between name and id.


Metadata
Status: DraftStandards Track: ERCCreated: 2024-02-08
Authors
Zainan Victor Zhou (@xinbenlv)
Requires

Abstract


Extends tokens using uint256 tokenId to support tokenName in type string and be able to convert backward to tokenId.

Motivation


For Marketplaces, Explorers, Wallets, DeFi and dApps to better display and operate NFTs that comes 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.

  1. Compliant contracts MUST support tokenName and mapping between tokenName and tokenId in one of the following ways:
  • 1a all compliant contracts are RECOMMENDED to implement the following interfaces: IERC_NamedTokenCore,

and it should satisfy the behavior rules that: - 1a.1. when a new name is instroduced, 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 doesn't implement IERC_NamedTokenCore, it MAY follow the default mapping rule between tokenId and tokenName uint256 tokenId = uint256(keccak256(tokenName)).
  1. All method involving tokenId for a compliant contract is RECOMMENDED to have a counterpart method end with ByName that substitute all pamameters of uint256 tokenId with string memory tokenName, and the behavior of the counterpart method MUST be consistent with the original method.

  2. Compliant contract MAY implement one or more of following extra interface


Rationale


  1. We allow default way to map tokenId and tokenName for convenience, but we also allow contract to implement their own way to map tokenId and tokenName for flexibility.

  2. 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 assume that both tokenName and tokenId are unique amongst all tokens.

If tokenNames are not normalize, two distinct tokenNames may confuse users as they look alike. Contract developer shall declare normalization mechanism if non-unique tokenName is allowed using IERC_NamedTokenExtension.

Copyright


Copyright and related rights waived via CC0.