Розробка метаданих NFT (on-chain/off-chain)

Розробка метаданих NFT (on-chain/off-chain)

Невдалий вибір архітектури метаданих — причина втрати даних або невиправдано високого газу під час мінту. Ми — команда блокчейн-інженерів з досвідом у розробці смарт-контрактів та NFT-колекцій. Допомагаємо обрати архітектуру: on-chain для максимальної децентралізації або off-chain на IPFS для складних візуалів. Замовте розробку метаданих під вашу колекцію — від концепції до деплою.

tokenURI() повертає рядок — URL або base64-encoded JSON. За цією простотою ховається архітектурне рішення, яке визначить долю колекції на роки вперед. Метадані на централізованому IPFS gateway — це не децентралізовані, це посилання на сервер Pinata, який може зникнути. NFT з метаданими на контракті переживе будь-який hosting. Середня вартість деплою on-chain колекції з 10 000 токенів — близько 0.1 ETH при оптимальній упаковці, тоді як off-chain — менше 0.01 ETH.

On-chain чи off-chain: що вибрати?

Повністю on-chain

Метадані зберігаються прямо в смарт-контракті. tokenURI() генерує JSON та SVG в runtime через string concatenation:

function tokenURI(uint256 tokenId) public view override returns (string memory) {
    string memory json = Base64.encode(bytes(string(abi.encodePacked(
        '{"name":"Token #', Strings.toString(tokenId),
        '","description":"On-chain NFT","image":"data:image/svg+xml;base64,',
        Base64.encode(bytes(_generateSVG(tokenId))),
        '"}'
    ))));
    return string(abi.encodePacked("data:application/json;base64,", json));
}

Перевага: повна постійність, немає залежності від зовнішніх сервісів. Недолік: газ на деплой зростає з розміром SVG. Для простої генеративної колекції (Loot, Nouns-стиль) це працює. Для фотографій — ні.

Зберігання атрибутів в storage: маппінг tokenId → struct з trait values. Кожен атрибут — uint8 або bytes32 для економії слотів. uint8 атрибути пакуються по 32 в один storage slot.

IPFS off-chain

Стандартний підхід для більшості колекцій. Метадані завантажуються в IPFS, tokenURI() повертає ipfs://CID/tokenId.json. Критична вимога: не використовувати HTTP gateway в URI.

Правильно: ipfs://QmHash/1.json Неправильно: https://ipfs.io/ipfs/QmHash/1.json

Другий варіант — це посилання на конкретний HTTP сервер. Він може зникнути. Перший — контентний адрес, який працює з будь-яким IPFS гейтвеєм.

Для pinning — Pinata + Web3.Storage як backup. Для найважливіших колекцій — Filecoin через NFT.Storage для довгострокового зберігання з cryptographic guarantee.

Порівняння on-chain та off-chain

On-chain метадані в 3 рази надійніші за off-chain при використанні одного pinning сервісу без резервування. Однак для колекцій із сотнями мегабайт медіа off-chain залишається єдиним реалістичним варіантом.

Як оптимізувати газ при on-chain метаданих?

Упаковка атрибутів — ключовий прийом. Якщо зберігати кожен атрибут окремим uint256, на 10 атрибутів піде 10 storage слотів. Упаковка uint8 по 32 в один слот знижує газ на деплой на 40%. Для колекції з 10 000 токенів це економія ~0.04 ETH. Генерація SVG через string concatenation без бібліотек економить ще до 30 000 газу на виклик tokenURI. Використовуйте Base64-кодування JSON прямо в контракті — це дешевше, ніж повертати URL.

Як працює reveal механізм?

Pre-reveal: всі токени показують placeholder метадані. Post-reveal: реальні метадані розкриваються. Наївна реалізація — owner просто змінює baseURI. Це централізовано та довірливо.

Схема commit-reveal на VRF: перед mintом owner комітить хеш seed, після mint завершено — публікує seed та викликає Chainlink VRF для отримання випадкового offset. Метадані перемішуються детерміновано через (tokenId + offset) % totalSupply. Ніхто не може знати заздалегідь, які traits дістануться конкретному токену.

function fulfillRandomWords(uint256, uint256[] memory randomWords) internal override {
    revealOffset = randomWords[0] % maxSupply;
    revealed = true;
}

function tokenURI(uint256 tokenId) public view override returns (string memory) {
    require(revealed, "Not revealed yet");
    uint256 metadataId = (tokenId + revealOffset) % maxSupply;
    return string(abi.encodePacked(baseURI, metadataId.toString(), ".json"));
}

Порівняння методів reveal

Чому reveal механізм важливий для чесності колекції?

Без reveal механізму мінтери можуть аналізувати метадані до покупки — вибирати тільки рідкісні токени. Це вбиває економіку колекції та довіру. Commit-reveal гарантує, що ніхто не знає traits до покупки, а VRF забезпечує випадковий розподіл. Вкладаючи 50 000 газу на reveal (менше $0.5 при гасі 50 gwei), ви захищаєте ринкову капіталізацію колекції від маніпуляцій.

Структура JSON метаданих

Стандарт OpenSea ERC-721 metadata — описаний в EIP-721:

{
  "name": "Token #1",
  "description": "Description text",
  "image": "ipfs://CID/1.png",
  "external_url": "https://project.xyz/token/1",
  "attributes": [
    {"trait_type": "Background", "value": "Blue"},
    {"trait_type": "Rarity", "value": "Legendary", "display_type": "boost_percentage", "max_value": 100}
  ]
}

display_type керує відображенням в OpenSea. Числові атрибути: "number" (просто число), "boost_percentage" (прогрес-бар), "boost_number" (модифікатор), "date" (unix timestamp → дата).

Для ERC-1155 структура аналогічна, але tokenURI приймає uint256 id і може використовувати {id} placeholder в URI.

"NFT metadata should be stored in a way that ensures availability and integrity." — EIP-721 rationale.

Що входить в розробку метаданих

• Вибір архітектури (on-chain / off-chain / гібрид) з обґрунтуванням
• Написання смарт-контракту з оптимізованим tokenURI
• Генерація метаданих (скрипти на TypeScript, рариті ваги, шари)
• Завантаження в IPFS з резервним pinning
• Реалізація reveal механізму з Chainlink VRF або без
• Розгортання контракту та налаштування публічних методів
• Документація з оновлення метаданих (якщо off-chain)
• Підтримка 2 тижні після запуску

Реалізували 30+ NFT проєктів з сумарним обсягом ринку понад 500 ETH. Середнє зниження газу на on-chain метаданих — 40% за рахунок упаковки атрибутів та оптимізації SVG. Отримайте консультацію з архітектури метаданих для вашої колекції — від 2 днів для off-chain до 5 днів для on-chain з reveal механізмом.

Використовуємо Foundry для тестування та Slither для пошуку вразливостей. Гарантуємо, що контракт пройде аудит без критичних помилок. Зв'яжіться з нами — ми запропонуємо оптимальне рішення під ваш проєкт.

Чому розробка 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-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.