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