ERC-7632: Interfaces for Named Token
Enable tokens to have a string name and be able to convert between name and id.
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 betweentokenName
andtokenId
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 betweentokenId
andtokenName
uint256 tokenId = uint256(keccak256(tokenName))
.
-
All method involving
tokenId
for a compliant contract is RECOMMENDED to have a counterpart method end withByName
that substitute all pamameters ofuint256 tokenId
withstring 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
andtokenName
for convenience, but we also allow contract to implement their own way to maptokenId
andtokenName
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
Copyright and related rights waived via CC0.