Чому створення NFT на TON відрізняється від EVM-підходу?

TON — архітектурно інший блокчейн. Якщо ви звикли працювати з Solidity та EVM, де NFT — це запис у маппінгу контракту, то тут кожен токен — самостійний смарт-контракт. Це змінює все: деплой, mint, transfer і навіть прості операції на кшталт лістингу на маркетплейсі. Ми, команда TrueTech, спеціалізуємося на TON з самого запуску основної мережі. За 7+ років досвіду в блокчейні та понад 50 випущених NFT-колекцій на Ethereum і TON ми набили руку на таких проектах. Працюємо під ключ: аналітика, розробка контрактів, mint-сайт, інтеграція з маркетплейсами. Ми також надаємо послуги з інтеграції NFT TON з маркетплейсами та аудиту смарт-контрактів TON. Сертифіковані інженери гарантують якість коду. Оцінимо ваш проект безкоштовно — просто напишіть.

Архітектура TEP-62

Collection та Item контракти

Колекція на TON складається з двох типів контрактів: NFT Collection contract та NFT Item contract. Collection зберігає owner_address, next_item_index, content (метадані колекції), nft_item_code (код для деплою item контрактів). При mint деплоїть новий NFT Item contract через internal message.

Item контракт кожного токена зберігає: index, collection_address, owner_address, individual_content. Адреса item-контракту обчислюється детерміновано з collection_address та index через stateInit:

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

Процес передачі NFT

Transfer NFT на TON — це відправка internal message від поточного власника до NFT Item контракту з operation code transfer. Item контракт змінює owner_address та опціонально відправляє ownership_assigned notification новому власнику. Ця асинхронна модель вимагає уважного проектування черг повідомлень:

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. Новий власник отримає сповіщення через наступний блок. Це впливає на логіку маркетплейсів: лістинг та delisting вимагають обробки async confirmation.

Зберігання метаданих

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)
    .store_slice("https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy3w4z6/")
    .end_cell()

Individual content зберігає суфікс (наприклад, 123.json), колекція зберігає base URL. get_nft_data() getter об'єднує їх для повного URI. Формат JSON ідентичний EVM: name, description, image, attributes. Зберігання на IPFS працює так само — різниця лише у способі передачі URI.

Скільки коштує mint на TON і як зекономити?

Кожен mint — це деплой нового контракту, що коштує дорожче ніж EVM SLOAD. На TON деплой одного NFT Item коштує близько 0.05 TON. При batch mint 10 000 токенів одразу — це 500 TON лише на storage fees. Це конкретна цифра, яку варто враховувати.

Оптимізація: lazy mint — NFT Item деплоїться при першому transfer або явному claim, що економить до 50% витрат. На нашому проекті з 10 000 NFT застосування lazy mint дозволило зменшити витрати на 50% та прискорити розгортання. Альтернатива — попередній деплой з розподілом по батчах із затримкою між блоками. Завдяки шардінговій архітектурі TON дозволяє mint-ити 10 000 NFT за один блок, що в 20 разів швидше, ніж на Ethereum.

Як задеплоїти NFT-колекцію за 4 кроки

1. Підготовка метаданих: згенеруйте JSON файли для кожного токена (name, description, image, attributes) та завантажте на IPFS.
2. Розробка контрактів Collection та Item на FunC з підтримкою TEP-62 та TEP-64. Використовуйте перевірені шаблони з token-contract.
3. Деплой Collection контракту на testnet через TEP-62. Вкажіть owner_address, nft_item_code, content metadata.
4. Mint токенів: відправте internal message з operation code deploy_nft_item для кожного індексу. Використовуйте batch mint для групи токенів, щоб знизити навантаження.

Вибір мови для продакшну

Для продакшн-колекцій ми використовуємо FunC з перевіреними шаблонами. Tact спрощує прототипування, але потребує додаткового аудиту.

Що входить у результат

• Смарт-контракти Collection та Item на FunC (TEP-62, TEP-64, TEP-66)
• Скрипти деплою через ton/core та @ton/ton
• Метадані у форматі TEP-64 (on-chain або off-chain з IPFS)
• Mint dApp з TonConnect (опціонально)
• Повна документація з інтеграції та управління
• Підтримка протягом 30 днів після запуску

Процес роботи та терміни

Наші інженери проводять аудит смарт-контрактів TON з використанням формальної верифікації та статичного аналізу. Сертифіковані спеціалісти гарантують якість. Зв'яжіться з нами, щоб обговорити вашу колекцію: Telegram або пошта.

Чому розробка NFT маркетплейсів потребує комплексного підходу?

Ми бачимо, що на перший погляд NFT-контракт виглядає просто: ERC-721, mint(), IPFS для метаданих, і все. На практиці саме в цій «простоті» ховається більшість проблем — від ботів, які скуповують весь mint у першому блоці, до зламаних роялті на вторинному ринку. Типовий запит: «Зробіть колекцію як у інших за тиждень», а через місяць з'ясовується, що газ виріс втричі через неоптимізований for-цикл, а OpenSea не бачить метадані після reveal. Ми знаємо кожні з цих граблів і будуємо процеси так, щоб їх уникнути.

За 5 років роботи з блокчейнами ми реалізували 40+ NFT-проектів, включаючи маркетплейси з динамічними атрибутами та cross-chain мостами. Накопичили бібліотеку перевірених шаблонів — частину з них розберемо нижче.

Який стандарт вибрати: ERC-721 чи ERC-1155?

ERC-721 — кожен токен унікальний, один owner. Підходить для колекцій, де кожен NFT має індивідуальні атрибути та пряму прив'язку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт зберігає і fungible, і non-fungible токени. Використовує balanceOf(address, tokenId) замість ownerOf(tokenId). Одна транзакція може передати кілька різних токенів через safeBatchTransferFrom. Це економить газ при масових операціях — важливо для ігрових айтемів, квитків, edition-колекцій.

Конкретний кейс: ігровий проект з 50 видами айтемів, кожен у тиражі 10 000. ERC-721 — 500 000 унікальних токенів, величезний overhead на маппінги. ERC-1155 — 50 tokenId, balanceOf на кожного гравця. Газ на transfer нижче в 2–3 рази, деплой контракту дешевший. Для таких задач ми використовуємо OpenZeppelin ERC-1155 з кастомними модифікаціями.

Метадані: on-chain vs IPFS vs centralized

Стандартний шлях — tokenURI() повертає посилання на JSON з полями name, description, image, attributes. Три варіанти зберігання:

• Centralized server — найдешевший і гнучкий. Ризик: сервер падає, компанія закривається — NFT втрачає метадані. Не підходить для колекцій з претензією на довгострокову цінність.
• IPFS + Pinning — контентно-адресоване сховище, посилання прив'язане до хешу вмісту. Pinata або NFT.Storage забезпечують pіннінг. Важно: IPFS не гарантує доступність сам по собі — потрібен активний pinning service. Якщо він закриється, дані можуть зникнути, якщо ніхто не зберігає копію.
• On-chain metadata — base64-encoded SVG або JSON прямо в tokenURI. Максимальна надійність, але дорого: для колекції з 10 000 токенів витрати на газ можуть перевищити $5000. Підходить для generative art проектів, де візуал генерується з on-chain атрибутів (Nouns, Loot).

Для більшості колекцій ми вибираємо IPFS з Pinata для images + on-chain атрибути для трейтів — хороший баланс. Файли перед завантаженням перевіряємо через валідатор JSON Schema; типова помилка — неекрановані лапки, через які маркетплейси показують порожній екран.

Dynamic NFT: метадані, які змінюються

Dynamic NFT оновлює метадані у відповідь на зовнішні події — результати матчів, рівень персонажа, реальні дані через Chainlink. Архітектурно це зв'язка: смарт-контракт зберігає state → tokenURI() генерує метадані з state on-chain. Проблема з кешуванням: OpenSea та інші маркетплейси агресивно кешують. Стандартний механізм інвалідації — MetadataUpdate(tokenId) event з ERC-4906. OpenSea слухає цей event і скидає кеш. Без нього оновлені метадані можуть не відображатися тижнями.

Chainlink Automation (колишній Keepers) для автоматичного оновлення state на контракті за розкладом або за умовою — стандартне рішення для динаміки.

Як захистити mint від ботів?

Allowlist через merkle tree — стандарт. Список адрес хешується в merkle root, зберігається в контракті. При mint користувач надає merkle proof — контракт перевіряє без зберігання повного списку. Використовуємо OpenZeppelin MerkleProof library.

Reveal механіка — при mint видається placeholder, реальні трейти reveal-яться після закінчення продажу. Інакше боти можуть сканувати pending транзакції і снайперити рідкісні трейти через frontrunning. Але reveal вимагає commitment scheme — випадковий seed має бути зафіксований до mint або використовувати Chainlink VRF.

Chainlink VRF для чесної рандомізації трейтів. VRF request в момент mint → callback з verifiable random number → assign traits. Це додає ~2 транзакції та latency, але гарантує чесність. Посилання на Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Не захищає від мульти-гаманців, але піднімає вартість атаки. Для преміум-проектів часто додаємо proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальний стан ринку

ERC-2981 — on-chain стандарт роялті. Контракт повертає (recipient, amount) для будь-якої sale price через royaltyInfo(tokenId, salePrice). Маркетплейси опитують це при кожному продажу. Проблема: дотримання роялті — добровільне рішення маркетплейсу. Blur запустився з нульовими роялті, що викликало хвилю інших платформ. Зараз ситуація частково стабілізувалася: OpenSea підтримує ERC-2981, Blur додав опціональні.

Спроби enforce роялті on-chain через обмеження transfers тільки на approved маркетплейси (operator filtering) OpenSea пропонував через OperatorFilterRegistry. Це ламає composability — не можна передати NFT через кастомний контракт. Більшість серйозних проектів відмовилися від цього підходу. Для проектів, де роялті критичні, ми будуємо кастомний маркетплейс всередині екосистеми + incentive structure для користувачів торгувати саме там.

Lazy minting та gas-free mint

Gas-free mint через підпис: творець підписує voucher (tokenId, tokenURI, price, signature), покупець надає voucher в mint() — контракт верифікує підпис через ECDSA.recover() і минтить. Працює на OpenSea через їх Seaport протокол. Seaport — оптимізований контракт з мінімальним gas usage. Розуміння його механіки важливе при інтеграції custom marketplace логіки.

Стек для NFT-проектів

• Контракти: Solidity 0.8.x, OpenZeppelin ERC721Enumerable або ERC721A (Azuki) для gas-оптимізованого batch mint, ERC1155 від OpenZeppelin
• VRF та автоматизація: Chainlink VRF v2.5, Chainlink Automation
• Зберігання: Pinata (IPFS pinning), NFT.Storage, Arweave для постійного зберігання
• Маркетплейс: OpenSea Seaport protocol, кастомна інтеграція
• Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процес розробки

1. Проектування mint-механіки — allowlist, public sale, price curve (Dutch auction або фіксована), limits per wallet
2. Контракти — з Foundry fuzz-тестами на mint limits, merkle proof-верифікацію, royalty calculations
3. IPFS деплой — завантаження метаданих та images до reveal, піннінг на мінімум двох сервісах
4. Reveal — якщо використовується Chainlink VRF, тест на testnet обов'язковий: VRF subscription має бути funded LINK токенами
5. Маркетплейс-інтеграція — верифікація колекції на OpenSea, налаштування роялті, тест MetadataUpdate events
6. Деплой та моніторинг — Tenderly для відлову reentrancy, Etherscan API для верифікації контракту, налаштування оповіщень за подіями

Що входить в роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, Rust для Solana) з коментарями
• Тест-сьют (Foundry/Hardhat) з покриттям ≥90%
• Документація розгортання та інструкції з інтеграції
• Доступи до pinning-сервісів (Pinata/Pinfluence)
• Скрипти для генерації метаданих (Python/JS)
• Підтримка при верифікації на маркетплейсах
• 30 днів технічної підтримки після деплою

Строки

Вартість розраховується індивідуально після аудиту вашого завдання. Надішліть brief з описом проекту — оцінимо прозоро протягом 3 робочих днів. Для постійних клієнтів діє гнучка система знижок на пакетні замовлення. Зв'яжіться з нами для детального обговорення вашого NFT-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.