NFT implementations 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.

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 for shifting minting costs from the creator to end users via Merkle-proof-based self-deployment. NFT items are self-deployed by users using Merkle proofs 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 attempt to 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 an on-chain API to prove ownership of an SBT item.

Core functionality

SBTs provide several key operations that enable secure credential management:

• Ownership binding - the owner is set at mint time and never changes, ensuring permanent association with the recipient.
• Ownership proof - allows the owner to request the SBT to send a proof to a target contract confirming ownership, with optional content attachment.
• Owner information requests - any party can request current owner information and optional content from the SBT.
• SBT destruction - the owner can destroy the SBT contract, clearing ownership and authority fields.
• Revocation mechanism - the authority can mark the SBT as revoked, preventing further use while maintaining historical records.

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).