Розробка NFT-колекції на TON
TON — архітектурно інший блокчейн. Розробник з досвідом тільки на EVM підходить до TON NFT та виявляє, що концепції «контракт-адрес», «transfer», «approve» працюють принципово інакше. Кожен NFT токен на TON — це окремий смарт-контракт. Не запис у маппінгу, а повнофункціональний задеплоєний контракт з власною адресою та сховищем. Це змінює всю логіку деплою, мінту та трансферу. TEP-62 стандарт описує інтерфейс, але розуміння sharding архітектури TON — передумова для коректної реалізації.
Як працюють NFT на TON: TEP-62
Архітектура: контракти Collection + Item
Колекція на TON складається з двох типів контрактів:
NFT Collection contract — головний контракт колекції. Зберігає: owner_address, next_item_index, content (metadata колекції), nft_item_code (код для деплою item контрактів). При мінті деплоює новий NFT Item контракт через deploy_nft_item internal message.
NFT Item contract — кожен токен. Зберігає: index (порядковий номер), collection_address, owner_address, individual_content. Адреса item-контракту обчислюється детерміновано з collection_address та index через stateInit.
;; Отримати адресу NFT item за індексом (FunC)
cell calculate_nft_item_state_init(int item_index, cell nft_item_code) {
cell data = begin_cell()
.store_uint(item_index, 64)
.store_slice(my_address())
.end_cell();
return begin_cell()
.store_uint(0, 2)
.store_dict(nft_item_code)
.store_dict(data)
.store_uint(0, 1)
.end_cell();
}
Це означає: адреса будь-якого NFT в колекції можна обчислити off-chain, не робячи запит до блокчейну. Важливо для індексаторів та маркетплейсів.
TEP-62 transfer механіка
Transfer NFT на TON — це відправлення internal message від поточного власника до NFT Item контракту з operation code transfer. Item контракт змінює owner_address та опціонально відправляє ownership_assigned сповіщення новому власнику.
;; NFT Item: обробка transfer
if (op == op::transfer()) {
slice new_owner = in_msg_body~load_msg_addr();
slice response_destination = in_msg_body~load_msg_addr();
throw_unless(401, equal_slices(sender_address, owner));
owner = new_owner;
save_data();
;; Сповіщення нового власника (опціонально)
send_msg(new_owner, 0, op::ownership_assigned(), ...);
}
На відміну від EVM, де transferFrom — синхронна операція, на TON transfer — це async message. Новий власник отримає сповіщення через наступний блок. Важливо для marketplace логіки: листинг та delisting вимагають обробки async підтвердження.
Metadata стандарт (TEP-64)
TON NFT metadata зберігається в двох форматах: on-chain (TL-B encoded прямо в контракті) та off-chain (URL на JSON файл). Для колекцій з generative metadata типовий snake encoding URL:
Cell content = begin_cell()
.store_uint(0x01, 8) // off-chain flag
.store_slice("https://example.com/nft/")
.end_cell()
Individual content зберігає суфікс (наприклад, 123.json), колекція зберігає base URL. get_nft_data() getter об'єднує їх для повного URI.
Формат JSON ідентичний EVM: name, description, image, attributes. Зберігання на IPFS працює так само — різниця тільки у тому, як URI передається в контракт.
Інтеграція з маркетплейсами TON
GetGems — основний NFT маркетплейс TON. Використовує TEP-62 стандарт напрямку. Для листингу на GetGems контракт повинен коректно повертати get_nft_data(): (init?, index, collection_address, owner_address, individual_content).
TON Diamonds, Fragment — додаткові маркетплейси. Fragment спеціалізується на Telegram usernames як NFT (також TEP-62).
Перевіряємо сумісність через toncenter.com API: викликаємо get_nft_data() через RunGetMethod та порівнюємо з очікуваним форматом маркетплейса.
Royalty: TEP-66
TEP-66 — стандарт royalty для TON, аналог EIP-2981. Collection контракт додає getter royalty_params(), повертаючий (numerator, denominator, destination). Royalty 5% = numerator 50, denominator 1000.
GetGems підтримує TEP-66 з 2023 року. Без імплементації royalty не буде виплачуватись на основних маркетплейсах.
Mint механіка та Tact vs FunC
Вибір мови: FunC або Tact
FunC — нативна мова TON смарт-контрактів. Низькорівневий, вимагає явного управління пам'яттю та TL-B серіалізацією. Всі продакшн-контракти TON написані на FunC, добре покрита документацією та аудитами.
Tact — мова високого рівня для TON, синтаксично ближче до TypeScript. Компілюється в FunC. Упрощує розробку, але екосистема та інструментарій аудиту поки менш зрілі. Для продакшн-колекцій у 2024 році ми використовуємо FunC з перевіреними шаблонами з ton-blockchain/token-contract репозиторію.
Batch mint в sharding архітектурі
Кожен mint — це деплой контракту, що коштує дорожче ніж EVM SLOAD. На Ethereum mainnet mint ~50K gas; на TON — від 0.05 TON за NFT Item деплой. При batch mint 10 000 токенів одразу — 500 TON тільки на storage fees.
Оптимізація: lazy mint (NFT Item деплоється при першому transfer або явному claim), або попередній деплой на стороні власника колекції з розподіленням по батчам з затримкою між блоками.
Процес роботи
Аналітика (0.5-1 день). Тип колекції (стандартна, soulbound, фракційна), кількість токенів, формат metadata, royalty, цільові маркетплейси.
Розробка (3-4 дні). Collection + Item контракти на FunC з TEP-62/TEP-64/TEP-66 імплементацією, тести через ton-jest/sandbox, скрипти деплою через ton/core та @ton/ton SDK.
Mint сайт (1-2 дні). Frontend через TonConnect 2.0, інтеграція з TON Wallet, Tonkeeper.
Деплой (0.5-1 день). Testnet (TON Testnet), потім mainnet. Верифікація на GetGems.
Базова колекція без mint сайта — 3-4 дні. З mint сайтом, вайтлістом та інтеграцією GetGems — 5-7 днів. Вартість розраховується індивідуально.