NFT tokenId in ERC721

Support Contracts
1

As far as I know, the token ID of NFT can be anything if unique in a given ERC721 contract, no standard for it. So, it can be just a number(such as 1, 2, 3, …).

But some NFT dApp uses its own formatted token ID from off-chain centralized server. Is it reasonable? In that case, how can we be sure that the ID is unique(no collision) and should we trust the issuer?

I wonder there is any good idea of generating unique NFT token ID.

1 Like
2

Hi @swkim109,

The token ID is a uint256 and doesn't need to be sequential or have any pattern according to EIP721.

The metadata extension is optional and allows for a URI to be associated with a tokenID. As it is a URI, there is at least some centralization, also the metadata according to EIP721 can change.

See EIP721 for more details, I have quoted some of the relevant sections:

NFT Identifiers

Every NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that a NFTs MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface.

The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.

The metadata extension is OPTIONAL for ERC-721 smart contracts (see "caveats", below).

A mechanism is provided to associate NFTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each NFT. The image size recommendation is taken from Instagram, they probably know much about image usability. The URI MAY be mutable (i.e. it changes from time to time). We considered an NFT representing ownership of a house, in this case metadata about the house (image, occupants, etc.) can naturally change.

Metadata is returned as a string value. Currently this is only usable as calling from web3 , not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information.

Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)

Incrementing a counter when tokens are minted is a possible solution. Token IDs are then sequential (unless burning is allowed).

The OpenZeppelin ERC721 documentation section Constructing an ERC721 Token Contract shows an example of using Counters for generating token IDs.

There is an open Issue for an ERC721 extension with "automatic" token URI: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1745

1 Like
3

what is ProvenanceHash and how we can implement it in ERC721?