Skip to main content
This page compares the NFT protocol standards on TON for each layer. The protocol has two independent layers — collection and item — and standards can be combined across them.

Collection

There are two types of the collection layer:
  • Default collection — canonical implementation.
  • cNFT — implementation optimized for mass distribution.
CapabilityDefaultcNFT
Deployment and minting flowCreator mints an item.Any user with a valid proof can deploy an item.
Who pays for item deploymentCreators pay in most cases.Audience pays.
Eligibility or allowlistCreator controls custom off-chain or on-chain logic.On-chain Merkle allowlist; users verify proofs using root from Merkle root.
Minting permissionsOnly the creator can mint.Any user with a valid Merkle proof.
Use casesLimited drops, controlled minting.Mass airdrops, growth campaigns, large audiences.
Key trade‑offsCreator pays mint costs; full control.Lower creator costs; proof UX and distribution setup required.

cNFT

cNFT (compressed NFT) is a standard NFT designed for airdrop‑style distribution. Minting costs shift from the creator to end users using Merkle‑proof.

Royalty

Royalty defines the percentage of NFT sales paid to the collection creator. It is set at the collection level and available using the get_royalty_params. For full specification, refer to TEP‑66. Any collection, including cNFT, can implement royalties. Marketplaces automatically pay royalties to the creator, regardless of the collection type.

Item

There are two types of the item layer:
  • Default item — a standard NFT item that can be transferred.
  • SBT — a non‑transferable NFT bound to a specific owner.
CapabilityDefaultSBT
TransferabilityYesNo
Use casesArt, collectibles, tickets, in-game assetsIdentity, credentials, achievements, badges

SBT

An SBT (Soulbound Token) inherits the uniqueness and metadata model of NFTs but cannot be transferred, permanently binding the token to the recipient’s address upon minting. SBTs are suitable for identity and credentials, including attendance records, participation proofs, and achievements. It also has an on-chain API to prove ownership of an SBT item. For more details, see How it works.

Single NFT (no collection)

A single NFT is an item contract deployed without an associated collection. It keeps the same ownership semantics but omits shared collection metadata and indexing.
  • When to use: one-off assets, experimental pieces, or cases where collection-level coordination is unnecessary
  • Metadata: stored entirely on the item
  • Discoverability: no collection index; external indexers or explicit links are required to surface the item
  • Trade-offs: simpler setup but fewer shared features, including no collection-wide royalties or configuration, no batch queries by index.