К основному содержанию
T TON Adoption
← Словарь
NODE/03 · Term

TEP-64

Стандарт метаданных токенов в TON: формат JSON-структуры с name, description, image, attributes для NFT и jetton-ов.

Синонимы: tep 64, ton metadata standard, nft metadata

TEP-64 — стандарт метаданных для токенов на TON. Описывает, как jetton- и NFT-контракты хранят описательную информацию: имя, символ, изображение, атрибуты, ссылки. Общий язык для кошельков, эксплореров и маркетплейсов.

Где могут лежать метаданные

TEP-64 различает три типа размещения:

  • On-chain. Все поля упакованы в cell-структуру внутри контракта. Дороже по storage-fee, но не зависит от внешних серверов.
  • Off-chain. В контракте лежит только URL (обычно IPFS или HTTPS), а сам JSON хранится отдельно. Дёшево по storage, но требует, чтобы сервер был доступен.
  • Semi-chain. Часть полей on-chain, часть — по ссылке. Гибрид.

Большинство jetton-ов используют off-chain для гибкости (изменить иконку без обновления контракта), большинство NFT — semi-chain.

Структура JSON

Базовый набор полей:

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

Для NFT добавляются атрибуты:

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

Что важно

  • IPFS vs HTTPS. IPFS более устойчив к удалению (если есть пиннинг), но медленнее в отображении. HTTPS быстрее, но завязан на конкретный сервер.
  • Изображения. Кошельки кешируют, поэтому смена image в JSON не всегда мгновенно отражается на пользователе.
  • Целостность. Если вы публикуете off-chain JSON, храните копию. Потеря metadata-сервера превращает NFT-коллекцию в визуально пустую.

TEP-64 совместим с метаданными OpenSea (тот же формат name/description/image/attributes), что упрощает портирование коллекций между сетями.

См. также