NFT comparison

This page compares the available standards for each layer of the NFT protocol on TON. The protocol has two layers — Collection and Item — and you can mix standards between layers since they are independent of each other.

Scope

This page focuses on high‑level capabilities and typical trade‑offs. For low‑level details, see How it Works.

Collection

Short overview:

• Default Collection: canonical implementation.
• cNFT (compressed NFT): optimized for mass distribution.

Capability	Default Collection	cNFT Collection
Deployment & minting flow	Items are minted by the creator	Any user with a valid proof can deploy their item
Who pays for item deployment	Creator in most flows	Costs shifted to the audience
Eligibility/allowlist	Custom off‑chain/on‑chain logic, usually controlled by creator	On‑chain Merkle allowlist, root readable via get_merkle_root
Minting permissions	Typically restricted to the creator	Open to any user who provides a valid Merkle proof
Typical use cases	Curated drops, controlled minting	Mass airdrops, growth campaigns, very large audiences
Key trade‑offs	Creator bears mint costs; tighter control	Lower creator cost; proof UX and distribution setup required

cNFT

A cNFT (compressed NFT) combines a standard NFT with an airdrop‑style distribution, optimized for large distributions and shifting minting costs from the creator to end users via Merkle‑proof based self‑deployment. NFT Items uses instead of airdrop markers.

Additional: Royalty

Royalty is defined at the collection level and exposed via get_royalty_params (TEP‑66). Any collection implementation can follow this model.

Marketplaces can rely on this model and pay royalties to the collection creator regardless of how the collection was deployed.

Item

Short overview:

• Default Item: fully transferable NFT item that implements the standard transfer operation.
• SBT (Soulbound Token): a non‑transferable NFT bound to a specific owner by design.

Capability	Default Item	SBT (Soulbound Token)
Transferability	✅ Yes	❌ No
Typical use cases	Art, collectibles, tickets, gaming assets	Identity, credentials, achievements, non‑transferable badges

SBT

An SBT inherits the uniqueness and metadata model of NFTs but disables transfer operations, binding the token permanently to the recipient’s address after mint. This makes SBTs well‑suited for identity and credentials: attendance records, participation proofs, and non‑transferable achievements. It also has on-chain API to proof ownership of SBT item.

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: there is no collection index, external indexers or explicit links are used to surface the item.
• Trade‑offs: simpler setup but fewer shared features (no collection‑wide royalty/config, no batch queries by index).