feat: add nft comparison page

docs.json

@@ -323,6 +323,7 @@
                 "pages": [
                   "standard/tokens/nft/overview",
                   "standard/tokens/nft/how-works",
+                  "standard/tokens/nft/сomparison",
                   "standard/tokens/nft/cNFT-how-it-works"
                 ]
               },

standard/tokens/nft/сomparison.mdx

@@ -0,0 +1,66 @@
+---
+title: "NFT comparison"
+sidebarTitle: "Comparison"
+---
+
+import { Aside } from '/snippets/aside.jsx';
+
+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.
+
+<Aside
+  type="note"
+  title="Scope"
+>
+  This page focuses on high‑level capabilities and typical trade‑offs. For low‑level details, see [How it Works](/standard/tokens/nft/how-works).
+</Aside>
+
+## 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](/standard/tokens/nft/overview) with an [airdrop‑style distribution](/standard/tokens/airdrop), optimized for large distributions and shifting minting costs from the creator to end users via [Merkle‑proof](/ton/proofs/basic-proof-concepts) based self‑deployment.  NFT Items uses instead of [airdrop markers](/standard/tokens/airdrop#the-scalable-design%3A-shard-and-prove).
+
+### 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 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).