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), что упрощает портирование коллекций между сетями.