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

EIP-165

Links

GitHub page Discussion on Ethereum Magicians

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.

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)).

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.
Compliant contract MAY implement one or more of following extra interface

Rationale

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.
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