NFT-мінтинг сторінка: розробка під навантаженням на Ethereum та L2

Розробка NFT-мінтинг сторінки

Колекція з 10 000 токенів, запуск через 48 годин, 500 осіб одночасно — і половина йде через гальмуючу сторінку. Ми часто бачимо таку помилку: мінтинг-сторінка написана за вечір, кнопка «Mint», MetaMask підключення, все просто. У момент дропу MetaMask не встигає, транзакції зависають, whitelist не верифікується, прогрес-бар показує 0 навіть після 200 замінених NFT. Це не проблема хайпу — це проблема frontend-архітектури під навантаження. Розробка надійної мінтинг-сторінки потребує глибокого розуміння Web3-стеку. Команда з 7+ річним досвідом і 30+ реалізованими проєктами (обсягом понад 2000 ETH) знає, як це зробити.

Які компоненти критичні для мінтинг-сторінки?

Підключення гаманця та chain management. Wagmi v2 + viem — поточний стандарт для Web3 React додатків. useConnect, useAccount, useNetwork хуки покривають базові сценарії. Критичний момент — перевірка та перемикання мережі. Якщо користувач підключений до Ethereum, а мінтинг на Base, потрібен useSwitchChain з автоматичним запитом. Якщо відмовив — показуємо блокуюче попередження.

const { switchChain } = useSwitchChain() const { chain } = useAccount() if (chain?.id !== TARGET_CHAIN_ID) { return <SwitchNetworkPrompt onSwitch={() => switchChain({ chainId: TARGET_CHAIN_ID })} /> } 

Як ми вирішуємо проблему верифікації whitelist?

Два підходи: on-chain mapping та Merkle proof. On-chain mapping (mapping(address => bool) public whitelist) — дорого. Додати 5000 адрес у whitelist = 5000 транзакцій (до 1 ETH на mainnet). Merkle proof — стандарт для великих whitelist. Root зберігається on-chain (один bytes32), доказ для кожного адресу — off-chain, передається при мінтингу. Налаштування start коштує в 10 разів дешевше — одна транзакція замість тисяч. Frontend отримує proof через API або зберігає в публічному JSON.

Верифікація на frontend до відправки транзакції:

import { MerkleTree } from 'merkletreejs' import { keccak256 } from 'viem' const proof = merkleTree.getHexProof(keccak256(address)) const isValid = merkleTree.verify(proof, keccak256(address), merkleRoot) 

Важливо: верифікація на frontend — тільки для UX. Фінальна перевірка — у смарт-контракті. Ніколи не довіряй frontend-верифікації.

Порівняння методів whitelist

Merkle proof знижує витрати на setup з $10,000 (on-chain) до $100 — економія 99%. Детальніше в Wikipedia.

Чому реальний прогрес-бар потребує WebSocket?

Проблема stale data. totalSupply() змінюється з кожним заміненим NFT. Якщо читати через useReadContract з дефолтним polling — дані застарілі на 1-3 блоки. На гарячому дропі це означає, що прогрес-бар бреше.

Рішення: WebSocket підписка на Transfer події контракту. useWatchContractEvent з wagmi оновлює дані в 50 разів швидше, ніж polling, і не витрачає зайві RPC-запити.

useWatchContractEvent({ address: CONTRACT_ADDRESS, abi: NFT_ABI, eventName: 'Transfer', onLogs: (logs) => { const mints = logs.filter(log => log.args.from === zeroAddress) setMintedCount(prev => prev + mints.length) } }) 

Це дає realtime оновлення без polling.

Стани транзакції

Користувач натиснув «Mint» — потрібно показати мінімум 4 стани явно:

useWriteContract + useWaitForTransactionReceipt з wagmi покривають всі стани через isPending, isLoading, isSuccess, isError. Типова помилка: показувати spinner без transaction hash. Користувач не знає, чи пройшла транзакція, закриває вкладку і мінтить знову. Завжди показуй transaction hash щойно він з'явився.

Обробка помилок з контракту

Revert messages з Solidity custom errors потрібно декодувати. viem робить це автоматично, якщо в ABI є error definitions. Але користувачу не можна показувати технічне повідомлення на кшталт ERC721: transfer to non ERC721Receiver implementer. Маппінг помилок у user-friendly текст:

• MaxSupplyReached → «Всі NFT вже замінені»
• NotWhitelisted → «Ваш адрес не в whitelist»
• MintingPaused → «Мінтинг тимчасово призупинено»
• InsufficientFunds → «Недостатньо коштів»

Продуктивність під навантаження

У момент дропу сотні користувачів одночасно звертаються до RPC-провайдера. Публічні RPC (Infura free tier) мають rate limits. Рішення: Alchemy або QuickNode з платним планом + кешування статичних даних (totalSupply, mintPrice, whitelistRoot) у власному backend з TTL 2-5 секунд. Merkle proof-и для whitelist віддаємо через CDN (Cloudflare) — sub-50ms відповідь без навантаження на сервер.

Що входить у розробку

• Документація: опис архітектури, інструкція з деплою, специфікація контрактів.
• Доступи до репозиторію, тестової мережі та інструментів моніторингу (Tenderly, Etherscan).
• Навчання команди: 1-2 години онлайн-сесія з управління мінтинг-сторінкою.
• Підтримка після запуску: 2 тижні моніторингу та виправлення помилок.

Процес розробки

• Розробка (3-4 дні). Next.js + wagmi + viem. Компоненти: wallet connector, mint button з усіма станами, progress bar з WebSocket, whitelist checker.
• Інтеграція з контрактом (1 день). ABI підключення, тестування на testnet (Sepolia), перевірка edge cases: wrong network, not whitelisted, sold out, paused.
• Оптимізація (1 день). RPC кешування, CDN для proof-ів, gas estimate перед транзакцією.

Орієнтири за термінами

Стандартна мінтинг-сторінка з whitelist та прогрес-баром — 3-5 днів. Складна з фазами мінтингу (presale, public), multiple wallet types та кастомним дизайном — до 2 тижнів. Вартість розраховується після уточнення функціональних вимог та дизайну.

Типові помилки при розробці мінтинг-сторінки

• Не перевіряти мережу користувача – мінтинг в іншій мережі провалиться.
• Показувати тільки spinner без transaction hash – користувач не знає статус.
• Використовувати polling для totalSupply – дані stale, прогрес-бар бреше.
• Довіряти frontend-верифікації whitelist – потрібно перевіряти в контракті.
• Не кешувати Merkle proof – навантаження на backend при великому whitelist.
• Не обробляти додавання другого мінтингу з тим самим гаманцем – потрібно перевіряти володіння токеном.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми оцінимо складність та терміни безкоштовно. Замовте розробку мінтинг-сторінки з гарантією стабільності під навантаженням до 1000 одночасних користувачів.

Наша команда: 7+ років досвіду, 30+ реалізованих проєктів із загальним обсягом понад 2000 ETH. Гарантуємо стабільну роботу та економію на gas за рахунок Merkle proof та кешування.