# NFT implementations comparison (https://docs-kyrm16yq7-ton-core-docs.vercel.app/llms/standard/tokens/nft/comparison/content.md)



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.

<Callout type="note" title="Scope">
  This page focuses on high-level capabilities and typical trade-offs. For low-level details, see [How it Works](/llms/standard/tokens/nft/how-it-works/content.md).
</Callout>

## Collection [#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 [#cnft]

A cNFT (compressed NFT) combines a [standard NFT](/llms/standard/tokens/nft/overview/content.md) with an [airdrop-style distribution](/llms/standard/tokens/airdrop/content.md), optimized for large distributions and for shifting minting costs from the creator to end users via [Merkle-proof](/llms/foundations/serialization/merkle/content.md)-based self-deployment. NFT items are self-deployed by users using Merkle proofs instead of [airdrop markers](/llms/standard/tokens/airdrop/content.md).

### Additional: Royalty [#additional-royalty]

Royalty is defined at the collection level and exposed via `get_royalty_params` ([TEP-66](https://github.com/ton-blockchain/TEPs/blob/1e5b2c4c8290d88d6bc3ddc4729812e3ac232c00/text/0066-nft-royalty-standard.md)). Any collection implementation can follow this model.

Marketplaces can attempt to pay royalties to the collection creator regardless of how the collection was deployed.

<Callout type="note">
  Some NFT implementations included obligatory royalties, which required careful off-chain restrictions and management, thus limiting the distribution.
</Callout>

## Item [#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 [#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 [#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) [#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).