Разработка ERC-721 токена (NFT)
ERC-721 — стандарт, который знает каждый, но пишут правильно немногие. Типичная история: проект деплоит коллекцию, через месяц обнаруживает, что royalty не выплачивается на OpenSea (потому что не реализован EIP-2981), metadata вернее загружается из централизованного сервера (который упал), а mint через _safeMint вместо _mint позволяет повторный reentrancy через onERC721Received в кастомных контрактах-получателях. Правильный 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: royalty на уровне контракта
// Настройка роялти через ERC2981
_setDefaultRoyalty(royaltyReceiver, royaltyBps); // bps: 500 = 5%
OpenSea и большинство современных маркетплейсов читают royaltyInfo() из EIP-2981. Старые маркетплейсы использовали off-chain конфиг через Operator Filter Registry — этот подход устарел. Реализация EIP-2981 — минимальный стандарт для любой коллекции 2024+.
Важно: royaltyBps не обеспечивается on-chain принудительно — это информационный стандарт. Маркетплейс может его игнорировать. Для принудительного royalty нужны кастомные transfer hooks (EIP-2981 + transfer restrictions через operator whitelist).
Metadata и хранение
URI токена возвращает JSON с полями name, description, image, attributes. Где хранить:
IPFS — децентрализованно, дёшево, но нет гарантии доступности без pinning. Используем Pinata или nft.storage для pinning. CID фиксируется в контракте, metadata не изменяется.
Arweave — постоянное хранение за разовую плату. Дороже IPFS на старте, но надёжнее для долгосрочных коллекций.
On-chain — metadata в base64 прямо в tokenURI(). Полностью децентрализовано, но дорого по gas на mint. Подходит для generative art с небольшими коллекциями (< 1000 токенов).
Централизованный сервер — только для pre-reveal фазы. После reveal URI должен переключиться на IPFS. Реализуем через флаг revealed и два baseURI.
Gas-оптимизация 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+ токенов. Trade-off: transfer первого токена в batch чуть дороже из-за lazy initialization.
Процесс работы
Аналитика (0.5-1 день). Supply, mint механика (public/whitelist/free), royalty, нужны ли Enumerable и URIStorage, чейн деплоя.
Разработка (1-2 дня). Контракт + Foundry тесты + скрипт деплоя с верификацией.
Деплой. Testnet (Sepolia), затем mainnet. Верификация на Etherscan автоматически через Foundry.
Базовый ERC-721 с royalty и IPFS metadata — 2-3 дня. С whitelist (Merkle proof), reveal механикой и кастомным mint сайтом — 5-7 дней. Стоимость рассчитывается индивидуально.