Розробка лендінгу NFT-мінту
Уявіть: відкриття мінту, 10 хвилин до soldout. Тисячі одночасних транзакцій, MetaMask у половини користувачів завис, галерея не завантажується, таймер показує нулі, а кнопка мінту неактивна. Кожна секунда простою — втрачені гроші та довіра. Ми створюємо mint landing page — лендінг сторінку мінту, яка витримує хайп. Наш досвід у Web3 та 30+ запущених NFT-проєктів дозволяють передбачити вузькі місця до їх прояву. Економія на інфраструктурі та зниження витрат на газ закладені в архітектуру.
Які технічні ризики виникають при піковому мінті?
Лендінг мінту — це не красива картинка. Це правильна обробка станів гаманця, коректний gas estimate, обробка черги транзакцій та graceful degradation при RPC перевантаженні. Ми гарантуємо, що ваш лендінг не впаде в першу ж годину. Кожен компонент спроектований з урахуванням пікових навантажень.
Як ми гарантуємо стабільність RPC?
У момент хайпового мінту публічні Alchemy/Infura endpoint'и перевантажуються. Транзакції не відправляються, eth_call не відповідає. Критично важливо мати кілька RPC endpoint'ів з fallback через wagmi fallbackTransport:
const transport = fallback([ http(process.env.ALCHEMY_RPC), http(process.env.INFURA_RPC), http('https://eth.llamarpc.com'), ]) При failure одного — автоматично перемикається на наступний. Додатково налаштовуємо ретраї з експоненційною затримкою (до 3 спроб). У таблиці нижче порівняння стратегій:
| Стратегія | Надійність | Час перемикання |
|---|---|---|
| Один RPC | Низька (єдина точка відмови) | — |
| Fallback з 3 провайдерами | Висока | <50 мс |
| Fallback + ретраї | Дуже висока | <500 мс (з ретраями) |
Чому важлива корекція станів до публікації?
Навіть невелика розбіжність між фронтендом та контрактом призводить до помилок користувачів. Наприклад, таймер рахує хвилини до дати, а контракт стартує на блок пізніше — кнопка неактивна. Або необроблене pending дозволяє повторно відправити транзакцію. Ми використовуємо формальну перевірку всіх станів на тестнеті.
Критичні технічні компоненти
Таймер і синхронізація з блокчейном
Таймер має відраховувати час до конкретного блоку або unix timestamp з контракту, а не хардкоджену дату. Інакше: маркетинг оголошує мінт «о 18:00», розробник деплоїть контракт з startTime на 5 хвилин пізніше через затримку деплою — кнопка мінту неактивна ще 5 хвилин після «старту».
Коректна реалізація: читаємо mintStartTime() з контракту через wagmi useReadContract, вираховуємо різницю з Date.now(). Таймер на клієнті, джерело правди — контракт.
Обробка станів мінту
Приклад коду кінцевого автомата станів кнопки
const states = [ 'disconnected', 'wrong-network', 'not-started', 'allowlist-only', 'ready', 'pending', 'success', 'sold-out' ] as const; Кожен стан — окремий UI. Кнопка «Mint» без обробки pending стану призводить до подвійних транзакцій: користувач думає що натиснув даремно, тисне знову, обидві проходять.
Allowlist перевірка: якщо контракт має публічний та WL-етап, клієнт має перевірити Merkle proof до показу кнопки. Локально — згенерувати proof для підключеної адреси з tree, викликати isWhitelisted(address, proof) або MerkleProof.verify() view-функцію контракту. Це off-chain, газу не коштує.
Gas estimation та динамічний maxFeePerGas
Фіксований gasLimit у транзакції — помилка. Якщо контракт додав логіку між тестом та деплоєм — газ змінився. Використовуємо estimateGas через viem перед відправкою + буфер 20%.
Для EIP-1559 транзакцій: maxFeePerGas має враховувати поточний baseFee. При високому навантаженні в момент мінту baseFee може зрости в 5x. Кнопка «Mint» з maxFeePerGas з моменту завантаження сторінки, але відправлена через 30 секунд, може ревертитися з max fee per gas less than block base fee. Рішення: перераховувати maxFeePerGas безпосередньо перед відправкою транзакції.
| Параметр | Рекомендація |
|---|---|
| gasLimit | estimateGas + 20% буфер |
| maxFeePerGas | Перерахунок перед відправкою |
| maxPriorityFeePerGas | 2-3 gwei для швидкого включення |
Галерея колекції
Lazy loading з intersection observer: завантажуємо лише видимі зображення. Для 10k колекції — віртуалізація списку через @tanstack/react-virtual. IPFS зображення через Pinata dedicated gateway (в 10x швидше публічних gateway). Fallback при недоступності IPFS — заглушка-плейсхолдер, не зламаний img тег.
Що входить в роботу
- Технічне завдання з описом усіх станів та інтеграцій.
- Вихідний код на Next.js 14 TypeScript з коментарями.
- Конфігурація деплою (Vercel / Docker) та CI/CD.
- Тестування на testnet зі звітом.
- Документація по архітектурі та API.
- Підтримка 30 днів після запуску.
Процес і терміни
- Дизайн (1 день) — Figma макет з компонентами, мобільна версія.
- Розробка (2–3 дні) — галерея, таймер, mint-компонент з усіма станами, wallet integration.
- Інтеграція контракту (0.5 дня) — підключення ABI, тестування на testnet.
- QA та оптимізація (0.5 дня) — тест на різних гаманцях, мобільні браузери, всі стани мінту.
Разом: 3–5 днів. Вартість розраховується індивідуально після аналізу вашого контракту та макетів.
Отримайте консультацію по архітектурі лендінгу. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно. Замовте розробку лендінгу під ваш NFT-проєкт.