> ## Documentation Index
> Fetch the complete documentation index at: https://companyname-a7d5b98e-nft-comparison.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# NFT comparison

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](/standard/tokens/nft/comparison#cnft)  — implementation optimized for mass distribution.

| Capability                   | Default                                              | cNFT                                                                                                        |
| ---------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Deployment and minting flow  | Creator mints an item.                               | Any user with a valid proof can deploy an item.                                                             |
| Who pays for item deployment | Creators pay in most cases.                          | Audience pays.                                                                                              |
| Eligibility or allowlist     | Creator controls custom off-chain or on-chain logic. | On-chain Merkle allowlist; users verify proofs using root from [Merkle root](/foundations/proofs/overview). |
| Minting permissions          | Only the creator can mint.                           | Any user with a valid Merkle proof.                                                                         |
| Use cases                    | Limited drops, controlled minting.                   | Mass airdrops, growth campaigns, large audiences.                                                           |
| Key trade‑offs               | Creator pays mint costs; full control.               | Lower creator costs; proof UX and distribution setup required.                                              |

### cNFT

cNFT (compressed NFT) is a [standard NFT](/standard/tokens/nft/overview) designed for [airdrop‑style distribution](/standard/tokens/airdrop). Minting costs shift from the creator to end users using [Merkle‑proof](/foundations/proofs/overview).

### 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](https://github.com/ton-blockchain/TEPs/blob/1e5b2c4c8290d88d6bc3ddc4729812e3ac232c00/text/0066-nft-royalty-standard.md).

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](/standard/tokens/nft/comparison#sbt) — a non‑transferable NFT bound to a specific owner.

| Capability      |                   Default                  |                     SBT                     |
| --------------- | :----------------------------------------: | :-----------------------------------------: |
| Transferability |                     Yes                    |                      No                     |
| Use cases       | Art, collectibles, tickets, in-game assets | Identity, 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](/standard/tokens/sbt/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.