Разработка лендинга 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-проект.