---
eip: 7632
title: Interfaces for Named Token
description: Enable tokens to have a string name and be able to convert between name and id.
author: Zainan Victor Zhou (@xinbenlv)
discussions-to: https://ethereum-magicians.org/t/erc-tbd-named-nfts-extending-erc-721/18550
status: Draft
type: Standards Track
category: ERC
created: 2024-02-08
requires: 165
---

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

1. 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`,
```solidity
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))`.

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

3. A compliant contract MAY implement one or more of the following extra interfaces

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

## Rationale

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

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

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).