Each NFT, no matter the chain it's based on, has an ID allowing it to be uniquely identified. These identifiers can be structured quite differently depending on the chain ecosystem the NFT is a part of and the standards it adheres to however. SimpleHash helps simplify all of this with a cross-chain NFT and token identifier schema, to allow for consistent querying of NFT data, no matter the ecosystem you work with.
All NFTs on SimpleHash can be queried using a three part structure:
chain.contract_address.token_id
"Contract address" may mean many different things on different chains, and on some ecosystems (e.g., Solana) token_id isn't relevant. In this brief article, we'll walk through how the identifiers work on each chain or ecosystem, and how they fit into the overall structure of NFT data.
Identifying NFTs on EVM based chains
NFTs can be identified in a straightforward manner on most EVM (Ethereum Virtual Machine) based chains (e.g., Ethereum itself, Polygon, Base, Zora). Almost every EVM NFT can be identified by:
- The chain
- The contract_address (the unique address of the smart contract associated with the NFT itself)
- The token ID
SimpleHash allows for querying chains using the EIP155 associated standard of chain IDs. (EIP155 addressed replay attack protection - the chain ID is integral to the mechanism; different networks have distinct chain IDs to maintain transaction integrity across Ethereum and other Ethereum-based networks).
Token IDs are always numeric, and many popular contracts will have interrupted series (e.g., from 0 to 9999 or 1 to 10000), but this is not always the case, so should not be relied upon. (If you need to get the number of tokens on a contract, consider instead using the count=1 param on one of the SimpleHash API endpoints).
For ERC1155 NFTs, which have multiple copies, the token ID will be the same for each copy, but you can identify each individual holder using endpoint such as Owners by NFT.
For example, for Ethereum instead of passing the chain ID "ethereum" you could pass "eip155:1". Arbitrum would be "eip155:42161" and so on. The full list can be found here.
Identifying NFTs on Solana
On Solana, NFTs adhering to the Metaplex standard as formatted as a Base58-encoded string uniquely representing the NFT itself (e.g., 2DfTukhzftoX9oF8xaUQ8kS85oPEVEHsmpa4DQiinQGD), instead of being tied to a specific contract_address. These addresses on Solana are often elsewhere referred to as a Mint Address or Token Address. These are case sensitive. The notion of a token ID does not exist on Solana in the same way, but when querying Solana NFTs on SimpleHash, one can still be passed (and it will be ignored).
On EVM chains, a common work-flow is to look up NFTs that are on the same contract (or collection). On EVM this is usually straightforward, and querying all NFTs on a single contract_address is a common approach. For Solana, since the unique IDs are unique to each and every NFT, it works a bit differently. To get more details on how collections work on Solana, read this article, but in short, SimpleHash has a systematic approach, and collections verified by Metaplex take precedence (and can be queried using their metaplex_mint ID).
Identifying NFTs on Bitcoin (for Ordinals)
For Bitcoin Ordinal, each NFT ID is formatted as a lowercase string corresponding to the inscription ID, e.g. 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0. Similar to Solana, the notion of a token ID does not apply for Ordinals. The inscription ID in the Ordinals system is a stable and unique identifier, and usually what is used to query a specific item.
Bitcoin Ordinals can also be queried using an inscription number. Inscription numbers were initially sequential identifiers for inscriptions in the Ordinals system, meant to be stable and unchanging. However, due to protocol updates allowing multiple inscriptions per transaction and other changes, maintaining these stable numbers has now become more challenging. This led to the creation of "cursed" inscriptions with negative numbers, which sometimes makes the order of inscriptions unclear. As a convenience measure, SimpleHash allows for querying Bitcoin Ordinals via inscription number on this endpoint.
Identifying NFTs on other chains
SimpleHash also supports the Flow and Tezos ecosystems. On SimpleHash for Flow, NFT identifiers still follow the chain.contract_address.token_id format, but with contract_addresses formatted as a hybrid string starting with with the capital A, followed by a period and the hexidecimal portion of the address, followed by a period and the name of the contract, e.g., A.0b2a3299cc857e29.TopShot. These are case sensitive.
Tezos is more similar to EVM chains, with the familiar chain.contract_address.token_id formatting.
Conclusion
SimpleHash provides a unified, cross-chain schema for querying NFT data, accommodating the diverse identifier structures across different blockchain ecosystems. As multi-chain activity increases, this adaptability ensures developers can efficiently work with NFTs from various chains, using a consistent and reliable approach, regardless of the underlying blockchain's specific standards or identifier systems. If you'd like to learn more about different identifiers and standards for token data, please reach out - we'd love to chat.
