feat: [Standard > NFT > Comparison] Improve article

standard/tokens/nft/comparison.mdx

@@ -3,64 +3,58 @@ 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>
+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
 
-Short overview:
+There are two types of the collection layer:
 
-- Default Collection: canonical implementation.
-- cNFT (compressed NFT): optimized for mass distribution.
+- Default collection — canonical implementation.
+- [cNFT](/standard/tokens/nft/comparison#cnft)  — implementation 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   |
+| 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
 
-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](/foundations/proofs/overview) based self‑deployment. NFT Items uses instead of [airdrop markers](/standard/tokens/airdrop#the-scalable-design%3A-shard-and-prove).
+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).
 
-### Additional: Royalty
+### 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.
+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).
 
-Marketplaces can rely on this model and pay royalties to the collection creator regardless of how the collection was deployed.
+Any collection, including cNFT, can implement royalties. Marketplaces automatically pay royalties to the creator, regardless of the collection type.
 
 ## Item
 
-Short overview:
+There are two types of the item layer:
 
-- 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.
+- 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 Item                              | SBT (Soulbound Token)                                        |
-| ----------------- | ----------------------------------------- | ------------------------------------------------------------ |
-| Transferability   | ✅ Yes                                     | ❌ No                                                         |
-| Typical use cases | Art, collectibles, tickets, gaming assets | Identity, credentials, achievements, non‑transferable badges |
+| Capability      |                   Default                  |                     SBT                     |
+| --------------- | :----------------------------------------: | :-----------------------------------------: |
+| Transferability |                     Yes                    |                      No                     |
+| Use cases       | Art, collectibles, tickets, in-game assets | Identity, credentials, achievements, 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.
+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.
+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).
+- 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.