Мы проектируем и разрабатываем ERC-721 контракты, которые не ломаются. Типичная история: проект деплоит коллекцию, через месяц обнаруживает, что роялти не выплачивается на OpenSea (потому что не реализован EIP-2981), metadata вернее загружается из централизованного сервера (который упал), а mint через _safeMint вместо _mint позволяет повторный reentrancy через onERC721Received в кастомных контрактах-получателях. Итог — потеря доверия сообщества, судебные иски, переделка контракта заново. Из нашей практики: в одном проекте отсутствие EIP-2981 привело к потере 15% роялти на вторичных продажах — около 120 ETH (~$300k). Правильный ERC-721 — это не просто соответствие интерфейсу, это понимание, как маркетплейсы, кошельки и агрегаторы взаимодействуют с контрактом. Предлагаем разработку под ключ с аудитом и поддержкой — свяжитесь для оценки проекта.
Базовая имплементация через OpenZeppelin
Отправная точка — ERC721 из OpenZeppelin 5.x. Не пишем стандарт с нуля: OZ прошёл десятки аудитов, любая кастомная реализация добавляет риск без очевидной выгоды. Расширяем через наследование:
contract MyNFT is ERC721, ERC721Enumerable, ERC721URIStorage, ERC2981, Ownable { uint256 private _nextTokenId; uint256 public constant MAX_SUPPLY = 10000; constructor(address initialOwner) ERC721("My Collection", "MYC") Ownable(initialOwner) {} } ERC721Enumerable нужен, если контракт должен возвращать список токенов владельца (tokenOfOwnerByIndex). Добавляет ~20K gas к каждому transfer из-за дополнительных storage операций. Если маркетплейс не требует — лучше обойтись без него и читать данные через The Graph.
ERC721URIStorage позволяет хранить отдельный URI для каждого токена. Альтернатива — baseURI + tokenId паттерн, где все токены используют единый базовый путь. Второй вариант дешевле в gas при mint.
EIP-2981: роялти на уровне контракта
_setDefaultRoyalty(royaltyReceiver, royaltyBps); // bps: 500 = 5% OpenSea и большинство современных маркетплейсов читают royaltyInfo() из EIP-2981. Старые маркетплейсы использовали off-chain конфиг через Operator Filter Registry — этот подход устарел. Реализация EIP-2981 — минимальный стандарт для любой современной коллекции.
Важно: royaltyBps не обеспечивается on-chain принудительно — это информационный стандарт. Маркетплейс может его игнорировать. Для принудительного роялти нужны кастомные transfer hooks (EIP-2981 + transfer restrictions через operator whitelist).
Metadata и хранение
URI токена возвращает JSON с полями name, description, image, attributes. Где хранить — сравнение методов:
| Метод | Стоимость | Децентрализация | Долговечность | Лучше для |
|---|---|---|---|---|
| IPFS | Низкая | Да (с pinning) | Требует pinning | Большинство коллекций |
| Arweave | Средняя (разовая) | Да | Постоянная | Долгосрочные проекты |
| On-chain | Высокая | Полная | Постоянная | Generative art (<1000 токенов) |
| Централизованный сервер | Низкая | Нет | Зависит от оператора | Pre-reveal фаза |
Централизованный сервер — только для pre-reveal фазы. После reveal URI должен переключиться на IPFS. Реализуем через флаг revealed и два baseURI.
Как оптимизировать mint и снизить газ?
Стандартный _safeMint дороже _mint из-за проверки IERC721Receiver на адресах-контрактах. Если mint предназначен только для EOA — используем _mint. Если нужна поддержка контрактных кошельков (multisig) — _safeMint с явным reentrancy guard.
Для batch mint используем ERC-721A (Azuki) вместо стандартного OZ ERC-721. ERC-721A хранит данные владельца только при первом mint в batch, последующие токены дедуцируются — экономия до 70% gas при mint 10+ токенов. Для коллекции из 10 000 токенов это экономит около 50 ETH (~$100k) на комиссиях. Trade-off: transfer первого токена в batch чуть дороже из-за lazy initialization.
Сравнение методов mint:
| Метод | Gas на 1 mint | Gas на 10 mint | Защита от reentrancy |
|---|---|---|---|
_mint |
~60k | ~600k | Нет |
_safeMint |
~80k | ~800k | Частичная |
| ERC-721A | ~60k | ~150k | Нет (нужен guard) |
Какие ещё уязвимости нужно закрыть?
Reentrancy через onERC721Received
Если контракт-получатель реализует IERC721Receiver, он может вызвать обратно ваш контракт во время mint. Решение: использовать ReentrancyGuard из OpenZeppelin или _mint и проверять balance после transfer.
Unchecked low-level calls
Избегайте прямых call без проверки возвращаемого значения. В современном Solidity компилятор требует явного указания success.
Процесс работы
- Аналитика (0.5-1 день). Определяем supply, mint механику (public/whitelist/Merkle), роялти, нужны ли Enumerable и URIStorage, целевой чейн.
- Проектирование и разработка (1-2 дня). Пишем контракт на Solidity 0.8.x с тестами в Foundry. Собираем скрипт деплоя и верификации.
- Аудит и газ-оптимизация (0.5 дня). Проверяем код статическим анализатором Slither, фаззинг Echidna. Оптимизируем gas: убираем избыточные storage переменные, используем unchecked блоки.
- Деплой на testnet (0.5 дня). Sepolia, проверка взаимодействия с маркетплейсами.
- Mainnet деплой и поддержка (1 день). Верификация на Etherscan, передача прав, мониторинг. Пост-деплой поддержка 30 дней.
Что входит в работу
- Полный исходный код контракта с комментариями.
- Документация по функциям, событиям и модификаторам.
- Скрипты деплоя и верификации на Etherscan.
- Инструкция по настройке metadata (IPFS/Arweave).
- Обучение команды: проверка mint, раскрытие reveal.
- Техническая поддержка на 30 дней после деплоя.
Преимущества работы с нами
Наша команда имеет 7+ лет опыта в блокчейн-разработке, выполнено более 50 проектов по смарт-контрактам. Мы не просто копируем шаблон OpenZeppelin — мы адаптируем каждую коллекцию под конкретные требования маркетплейсов, gas-лимиты и модель распространения. Получите консультацию — пришлите описание вашего проекта, и мы оценим сроки и стоимость.
// Пример контракта с whitelist и reveal contract AdvancedNFT is ERC721, ERC2981, Ownable { using MerkleProof for bytes32[]; bytes32 public whitelistRoot; string public baseURI; string public placeholderURI; bool public revealed; uint256 public mintPrice = 0.08 ether; function whitelistMint(bytes32[] calldata proof) external payable { require(MerkleProof.verify(proof, whitelistRoot, keccak256(abi.encodePacked(msg.sender)))); _safeMint(msg.sender, _nextTokenId++); } function reveal(string memory _newBaseURI) external onlyOwner { revealed = true; baseURI = _newBaseURI; } } Ориентировочные сроки: базовый ERC-721 с роялти и IPFS metadata — 2-3 дня; с whitelist, reveal и mint сайтом — 5-7 дней. Стоимость рассчитывается индивидуально. Закажите разработку ERC-721 контракта с аудитом и поддержкой.