Розробка NFT-колекції
Багато хто вважає, що запуск NFT-колекції — це просто скопіювати OpenZeppelin ERC-721 з mint(). Але реальні проблеми починаються з синхронізації метаданих, вибору сховища та безпечного деплою. Централізоване зберігання tokenURI — прямий шлях до rug pull: власник сервера може замінити зображення після продажу. Ми бачили такі інциденти десятки разів. Тому кожна наша колекція використовує децентралізовані схеми: IPFS або Arweave, а контракти проходять аудит. Ми запускаємо NFT-колекції під ключ: від концепції до верифікації на OpenSea.
Як вибрати стандарт смарт-контракту: ERC-721, ERC-1155 чи ERC-721A?
ERC-721 — один токен, один owner. Підходить для PFP-колекцій та унікального арту. ERC-1155 — один контракт, декілька типів токенів, можливий fungible і semi-fungible. Правильний вибір для ігрових предметів, де однакові items можуть бути у тисяч гравців.
Для стандартної PFP-колекції (10 000 унікальних токенів) — ERC-721A (Azuki) замість стандартного ERC-721. ERC-721A оптимізує batch mint: mint 10 токенів за одну транзакцію коштує майже стільки ж газу, скільки mint одного в стандартному ERC-721. Економія для користувача — 50–80% на газі при mint декількох токенів.
Як захистити колекцію від rug pull?
Використовуйте децентралізоване зберігання метаданих (IPFS/Arweave), відмовтеся від централізованого сервера в tokenURI, застосовуйте перевірені бібліотеки OpenZeppelin і проходьте аудит з Slither та Mythril. Контракт повинен бути неоновлюваним (immutable) після reveal, щоб ніхто не міг змінити baseURI.
Які механіки мінтінгу підходять для вашої колекції?
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 без оффчейн даних.
Де зберігати метадані та зображення: IPFS, Arweave чи On-chain?
tokenURI повинен повертати JSON з полями name, description, image, attributes. Критичне питання — де зберігається цей JSON і самі зображення.
IPFS + Pinata/NFT.Storage — децентралізоване зберігання, контент-адресовані посилання (ipfs://Qm...). Якщо пінінг припиняється — файл теоретично недоступний, але може бути відновлений будь-яким IPFS-вузлом, у якого є копія. Стандарт для більшості колекцій. Детальніше про технологію — IPFS на Wikipedia.
Arweave — permanent storage, одноразова оплата за вічне зберігання. Більш надійно ніж IPFS з точки зору persistence. Використовується для цінних колекцій та PFP.
On-chain SVG — зображення генеруються прямо в контракті як SVG рядки. Повністю децентралізовано, неможливо змінити. Дорого по газу на деплой (якщо trait-дані зберігаються on-chain), але для простих геометричних арт-проєктів — ідеально.
| Критерій | IPFS | Arweave | On-chain SVG |
|---|---|---|---|
| Вартість зберігання | Безкоштовно при пінінгу, але потрібен пінінг-сервіс | Одноразова оплата за вічність | Включено в газ деплою |
| Надійність | Залежить від пінів | Гарантовано мережею | Абсолютно |
| Розмір даних | Практично безлімітний | До ~100 KB | Обмежений газом |
| Змінюваність | Незмінно (при правильній реалізації) | Незмінно | Незмінно |
Reveal механіка: при деплої всі tokenURI вказують на placeholder. Після мінта — reveal, контракт оновлює baseURI на фінальний IPFS шлях. Randomness для генерації traits беремо з Chainlink VRF (верифіковано випадковий) або з blockhash (маніпульовано, але дешево для non-high-value колекцій). Chainlink VRF забезпечує доведену випадковість.
Стек і процес
Контракт — Solidity 0.8.x, ERC-721A або OpenZeppelin ERC-721. Тести в Foundry: coverage >90%, тест на газ batch mint, тест Merkle proof verification. Бібліотеки OpenZeppelin — стандарт індустрії (OpenZeppelin Contracts).
Метадані генеруємо скриптом перед деплоєм: беремо trait layers, генеруємо combinatorics, перевіряємо rarity distribution, завантажуємо на IPFS через Pinata API. Фінальний IPFS CID фіксуємо до деплою.
| Етап | Зміст |
|---|---|
| Контракт | ERC-721A + whitelist + public mint + withdraw |
| Метадані | JSON генерація, upload на IPFS, CID в контракт |
| Тести | Foundry unit + fuzz, газ-репорт |
| Деплой | Sepolia testnet → Ethereum mainnet через Gnosis Safe |
| Верифікація | Etherscan + OpenSea collection verify |
Типові помилки при запуску: централізований tokenURI, відсутність тестів на reentrancy при withdraw, невірний random reveal, ігнорування gas optimization, неверифікація контракту. Всі ці моменти ми перевіряємо в рамках аудиту.
Що входить в роботу
- Смарт-контракт з обраною механікою мінтінгу (whitelist, auction, public)
- Генерація метаданих та завантаження на IPFS/Arweave
- Повні unit + fuzz тести (Foundry) з coverage >90%
- Деплой в mainnet та верифікація на Etherscan/OpenSea
- Документація по взаємодії (hardhat/ethers.js)
- Пост-запускна підтримка 30 днів
Оцінимо ваш проєкт за 1 день. Зв'яжіться з нами для консультації. Отримайте консультацію по вашому проєкту — ми допоможемо обрати оптимальне рішення.
Наш досвід та гарантії
Ми запустили 50+ NFT-колекцій на Ethereum, Polygon та BNB Chain. Команда з 6+ років досвіду в Web3 розробці. Гарантуємо коректну роботу контракту та безпеку — всі контракти проходять внутрішній аудит з використанням Slither та Mythril. Надаємо документацію та інструкції з подальшого управління.