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