NODE/03 · Term

TEP-64

TON's token metadata standard: JSON layout with name, description, image, and attributes for NFTs and jettons.

Aliases: tep 64, ton metadata standard, nft metadata

TEP-64 is the metadata standard for TON tokens. It defines how jetton and NFT contracts expose descriptive information: name, symbol, image, attributes, links. It’s the common language wallets, explorers, and marketplaces speak.

Where metadata can live

TEP-64 distinguishes three placements:

On-chain. All fields packed into a cell structure inside the contract. More expensive in storage fees, but doesn’t depend on any external server.
Off-chain. The contract stores only a URL (usually IPFS or HTTPS) and the JSON lives elsewhere. Cheap on storage, but the server must stay reachable.
Semi-chain. Some fields on-chain, others by link — a hybrid.

Most jettons use off-chain for flexibility (changing the icon without redeploying), most NFTs use semi-chain.

JSON shape

Base fields:

{
  "name": "Notcoin",
  "description": "Tap-to-earn token",
  "image": "https://example.com/icon.png",
  "symbol": "NOT",
  "decimals": 9
}

NFTs add attributes:

{
  "name": "Anonymous Number #100",
  "description": "Anonymous Telegram Number",
  "image": "ipfs://Qm.../100.png",
  "attributes": [
    { "trait_type": "Length", "value": 7 }
  ]
}

What to keep in mind

IPFS vs HTTPS. IPFS is more deletion-resistant (with pinning) but slower to render. HTTPS is faster but tied to a specific server.
Images. Wallets cache aggressively, so updating image in the JSON doesn’t always show up immediately for users.
Integrity. If you publish off-chain JSON, keep a backup. Losing the metadata server turns an NFT collection visually empty.

TEP-64 is compatible with OpenSea metadata (same name/description/image/attributes shape), which makes porting collections between chains easier.

Where metadata can live

JSON shape

What to keep in mind

Related terms