Розробка 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.







