TEP-62

TEP-62 is TON’s standard for non-fungible tokens. It defines the architecture — collection as one contract, each NFT as its own item contract — and the set of standard messages and get-methods. Every NFT on TON that works in wallets and marketplaces conforms to TEP-62.

What the standard defines

• Contract layout. A collection holds shared data and deploys items; each item stores its owner and individual metadata. The same master / wallet pattern as jetton, applied to NFTs.
• Messages. transfer — change owner. get_static_data — service query. excesses — refund unused TON.
• Get-methods. get_collection_data, get_nft_address_by_index, get_nft_content — required for explorer and marketplace integration.
• Addressing. An NFT with index i in collection C has a deterministic address — you can know it before mint.

What it deliberately doesn’t define

TEP-62 is intentionally thin: it sets the base, and adjacent concerns live in their own TEPs:

• TEP-64 — metadata format (JSON with name, image, attributes).
• TEP-66 — royalties (how marketplaces pay the creator).

This split lets each format evolve without breaking compatibility.

Why conformance matters

Wallets (Tonkeeper, MyTonWallet, Wallet) and marketplaces (Getgems, Disintar) expect TEP-62-compatible contracts. A collection with a non-standard transfer or missing get-methods either won’t display or won’t trade. Designing a custom “improved” NFT standard without TEP-62 backward compatibility is almost always a mistake.

The full spec lives in ton-blockchain/TEPs. Tact and Tolk ship with reference implementations in their standard libraries.