Розробка NFT-колекції

Розробка NFT-колекції

Контракт NFT-колекції на перший погляд простий — OpenZeppelin ERC-721 з функцією mint(). Насправді більшість проблем виникають не в самому контракті, а в комбінації метаданих, зберігання, механіки мінтингу та деплою. Колекція, де метаданні зберігаються на централізованому сервері (HTTP URL у tokenURI), уразлива до "rug pull" у частині NFT — власник сервера може змінити зображення в будь-який момент. Це не гіпотетика: кілька колекцій у 2022–2023 років замінили артворк після продажу.

Вибір стандарту та механіки мінтингу

ERC-721 vs ERC-1155

ERC-721 — один токен, один власник. Підходить для PFP-колекцій та унікального мистецтва. ERC-1155 — один контракт, кілька типів токенів, можливий fungible та semi-fungible. Правильний вибір для ігрових предметів, де одинакові items можуть бути у тисяч гравців.

Для стандартної PFP-колекції (10 000 унікальних токенів) — використовуй ERC-721A (Azuki) замість стандартного ERC-721. ERC-721A оптимізує batch mint: мінтинг 10 токенів за одну транзакцію коштує майже стільки ж газу, скільки мінтинг одного в стандартному ERC-721. Економія для користувача — 50–80% на газі при мінтингу кількох токенів.

Механіки мінтингу

Whitelist / allowlist — адреси зі списку мінтять раніше публіки. Реалізація через Merkle Tree (не через маппінг): корінь дерева зберігається в контракті (32 байти), користувач надає Merkle proof при мінтингу. Економія газу на деплой та зберігання — колосальна порівняно з mapping(address => bool) на тисячі адрес.

Signature-based allowlist — альтернатива Merkle Tree. Backend підписує дозвіл конкретній адресі через ECDSA (EIP-712), користувач надає підпис при мінтингу. Зручніше для динамічного allowlist (можна додавати адреси без оновлення Merkle root), але вимагає backend інфраструктури.

Dutch Auction — ціна починається високою й знижується кожні N хвилин до floor price. Дозволяє ринку самому знайти рівноважну ціну, знижує газові війни на старті. Складніше в реалізації — потрібен коректний розрахунок ціни on-chain без офчейн даних.

Метаданні та зберігання

tokenURI має повертати JSON з полями name, description, image, attributes. Критичне питання — де зберігаються ці JSON та зображення.

IPFS + Pinata/NFT.Storage — децентралізоване зберігання, content-addressable посилання (ipfs://Qm...). Якщо піннинг припиниться — файл теоретично недоступний, але може бути відновлений будь-яким IPFS-вузлом, у якого є копія. Стандарт для більшості колекцій.

Arweave — permanent storage, одноразова оплата за вічне зберігання. Більш надійно ніж IPFS з точки зору persistence. Використовується для цінних колекцій та PFP.

On-chain SVG — зображення генеруються прямо в контракті як SVG рядки. Повністю децентралізовано, неможливо змінити. Дорого по газу на деплой (якщо trait-дані зберігаються on-chain), але ідеально для простих геометричних арт-проектів.

Reveal механіка: при деплої всі tokenURI вказують на placeholder. Після мінту — reveal, контракт оновлює baseURI на фінальний IPFS шлях. Randomness для генерації traits з Chainlink VRF (верифіковано випадковий) або blockhash (маніпулюємий, але дешево для non-high-value колекцій).

Стек та процес

Контракт — Solidity 0.8.x, ERC-721A або OpenZeppelin ERC-721. Тесты у Foundry: coverage >90%, тест batch mint газу, тест Merkle proof верифікації.

Генеруємо метаданні скриптом перед деплоєм: беремо trait layers, генеруємо combinatorics, перевіряємо rarity distribution, завантажуємо на IPFS через Pinata API. Фіксуємо фінальний IPFS CID до деплою.

Кошторис по часу

Базова колекція (ERC-721, whitelist через Merkle, public mint, IPFS метаданні) — 1–1.5 тижня включаючи тесты та деплой. З Dutch auction, кастомною reveal механікою, Chainlink VRF — 2 тижні. Вартість залежить від складності mint механіки та обсягу робіт по метаданим.