Разработка lazy-minting NFT
Мы часто видим ситуацию: независимый художник хочет выпустить коллекцию из 100 NFT на Ethereum, но предоплата за газ при стандартном минте достигает $3000–5000 при 30 gwei. Для автора, который не уверен в продажах, это высокий порог входа. Lazy minting решает эту проблему: создатель подписывает voucher офф-чейн, а газ за минтинг платит покупатель в момент покупки. Никаких предварительных затрат — оплата только после продажи. Такой подход экономит в среднем 95% средств создателя на этапе запуска.
Как работает lazy minting на уровне криптографии?
Voucher = подписанная структура данных
Создатель подписывает офф-чейн данные своим приватным ключом. Voucher содержит все параметры будущего NFT:
struct NFTVoucher { uint256 tokenId; uint256 minPrice; // минимальная цена в wei string uri; // IPFS URI метаданных bytes signature; // подпись создателя } Подпись создаётся через EIP-712 (typed structured data signing), а не через сырой eth_sign. EIP-712 важен: пользователь видит читаемые данные в MetaMask при подписи, а не hex-строку. Это защищает от phishing — поддельный домен не может создать валидную EIP-712 подпись для чужого контракта.
On-chain верификация подписи
При вызове redeem(voucher, recipient) контракт восстанавливает адрес подписанта через ecrecover:
function _verify(NFTVoucher calldata voucher) internal view returns (address) { bytes32 digest = _hashTypedDataV4(keccak256(abi.encode( keccak256("NFTVoucher(uint256 tokenId,uint256 minPrice,string uri)"), voucher.tokenId, voucher.minPrice, keccak256(bytes(voucher.uri)) ))); return ECDSA.recover(digest, voucher.signature); } Если восстановленный адрес совпадает с MINTER_ROLE — подпись валидна, минт разрешён. Контракт использует ECDSA из OpenZeppelin 5.x для безопасного recover.
Какие уязвимости нужно учесть при lazy minting?
Replay attack — без уникального nonce или tokenId одну подпись можно использовать многократно. Защита: проверка _exists(tokenId) перед минтом + tokenId является частью подписанных данных. Уже заминтированный tokenId вернёт revert.
Cross-contract replay — подпись валидна для конкретного контракта на конкретной сети. EIP-712 domain включает chainId и verifyingContract адрес. Подпись с Ethereum mainnet не пройдёт верификацию на Polygon — они имеют разные chainId. Разные контракты — разные verifyingContract — разные domain separator.
Front-running voucher — технически любой, кто видит voucher в мемпуле, может попробовать заминтить на свой адрес. Защита: recipient включён в подписанные данные. Voucher валиден только для конкретного адреса получателя.
Чем lazy minting отличается от стандартного mint?
| Параметр | Стандартный mint | Lazy mint |
|---|---|---|
| Затраты создателя на газ | 30–50 ETH на 10 000 токенов | 0 ETH до продажи |
| Время до появления NFT в кошельке | Сразу после деплоя | Только после первой покупки |
| Риск нераспроданных токенов | Газ потрачен впустую | Нулевой |
| Сложность реализации | Низкая | Средняя (требуется signing service) |
Lazy mint выгоднее для авторов: порог входа ниже в 2 раза, а газ оплачивает покупатель. Также дополнительная экономия: при стандартном минте 80% коллекций не окупаются, с lazy mint убыток по газу исключён.
Какие типичные затраты на газ?
| Этап | Стандартный mint (10 000 токенов) | Lazy mint (10 000 токенов) |
|---|---|---|
| Деплой контракта | $500–1000 | $500–1000 |
| Mint всех токенов | $3000–5000 | $0 |
| Итого | $3500–6000 | $500–1000 |
Экономия для создателя составляет до 85% на этапе запуска.
Стек и инструменты
- Контракт: Solidity 0.8.x, OpenZeppelin ERC721URIStorage, EIP-712 через
EIP712из OpenZeppelin,AccessControlдляMINTER_ROLE. - Бэкенд: voucher generation сервис — Node.js с
viemдля signing, хранение в PostgreSQL или Redis. - Фронтенд: wagmi хуки для
writeContract, отображение состояния транзакции, интеграция с IPFS через NFT.Storage для загрузки метаданных. - Тесты: Foundry — тест корректной верификации, тест replay attack (должен revert), тест cross-contract (должен revert), fork-тест на mainnet для проверки ECDSA совместимости.
Процесс работы и сроки
- Аналитика — определяем количество токенов, роялти, тип продажи (публичная/whitelist).
- Проектирование контракта — архитектура с lazy mint логикой, EIP-712, AccessControl.
- Реализация — написание смарт-контракта, создание voucher сервиса, frontend компонента.
- Тестирование — Foundry unit-тесты, проверка всех атак (replay, cross-contract, front-running).
- Деплой и поддержка — загрузка метаданных в IPFS, верификация контракта в Etherscan, настройка dashboard.
Ориентировочные сроки: от 3 до 5 дней на MVP, от 1 до 2 недель на платформу с несколькими создателями. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Получите консультацию и точную смету.
Что входит в работу
- Исходный код смарт-контракта с тестами.
- Voucher signing service (Node.js).
- Frontend компонент для покупки/минта.
- Документация по развертыванию и интеграции.
- Поддержка в течение 1 месяца после сдачи.
Наш опыт
Более 5 лет на рынке блокчейн-разработки, 50+ реализованных проектов в сфере NFT и DeFi. Гарантируем безопасный код с формальной верификацией ключевых контрактов. Для получения консультации по lazy minting — пишите, оценим ваш проект бесплатно. Закажите разработку lazy minting для вашей коллекции уже сегодня.
Примечание: Для изучения спецификации EIP-712 обратитесь к официальной документации. Используйте актуальные версии библиотек OpenZeppelin.
Чек-лист для проверки lazy minting контракта
- Подпись использует EIP-712 с корректным domain separator.
- Каждый voucher содержит уникальный tokenId или nonce.
- Контракт проверяет
_exists(tokenId), чтобы избежать двойного минтинга. -
recipientвключён в подписанные данные для защиты от front-running. - Код протестирован на replays и cross-contract атаки.
- Используется
ECDSA.recoverиз OpenZeppelin, а не собственныйecrecover.







