Розробка Discord-бота верифікації NFT-холдерів
NFT-проєкт без системи верифікації холдерів втрачає контроль над ком'юніті: власники токенів не відрізняються від випадкових відвідувачів, holder-only канали пустують, ранній доступ до мінтів та governance-голосувань стає формальністю. Ми пропонуємо готове рішення — Discord-бота для перевірки володіння NFT з видачею ролей, який інтегрується з будь-якими L1/L2 та оновлює статус при кожному трансфері. Наш підхід знижує навантаження на адміністраторів і виключає людські помилки при ручній видачі ролей.
Технічно задача складається з трьох шарів: on-chain перевірка через RPC, OAuth авторизація через Discord та періодична ревалідація ролей при зміні балансу. Використовуємо сучасний стек: Discord.js v14, viem, PostgreSQL, Redis. Середній час розгортання — 3–5 днів під ключ. Замовте розробку — отримайте консультацію з архітектури та демо-версію.
Процес верифікації: від команди до видачі ролі
Стандартний flow без зберігання приватних ключів:
- Користувач натискає
/verifyу Discord. - Бот надсилає йому DM з унікальним challenge message (UUID + timestamp).
- Користувач підписує message в MetaMask через WalletConnect або інший гаманець.
- Надсилає підпис боту.
- Бот відновлює адресу через
ecrecover(абоviem.verifyMessage()), перевіряє баланс NFT через RPC.
import { verifyMessage } from 'viem'; const recoveredAddress = await verifyMessage({ address: claimedAddress, message: challengeMessage, signature: userSignature, }); if (!recoveredAddress) throw new Error('Invalid signature'); const balance = await publicClient.readContract({ address: NFT_CONTRACT, abi: erc721Abi, functionName: 'balanceOf', args: [claimedAddress], }); Challenge message містить timestamp з TTL 5–10 хвилин — це захист від signature replay. Використані challenge зберігаються в Redis з автоматичним закінченням терміну дії.
Які контракти підтримуються?
Більшість реальних проєктів верифікують кілька контрактів: основну колекцію + companion-колекцію + стейкінг. Підтримка ERC-721 та ERC-1155, а також кастомні контракти з функцією stakedTokensOf. Ролі видаються за комбінацією умов:
| Роль | Умова |
|---|---|
| Gold holder | balance(MainNFT) >= 1 AND balance(CompanionNFT) >= 1 |
| Diamond holder | balance(MainNFT) >= 5 |
| Staker | stakedBalance(StakingContract, address) >= 1 |
Для стейкінг-контрактів потрібен окремий виклик: стандартний balanceOf ERC-721 не враховує застейкані токени. Викликаємо stakedTokensOf(address) або аналог з кастомного ABI.
Чому важлива автоматична ревалідація ролей?
Якщо користувач продав NFT, його роль має бути відкликана. Ми реалізуємо це двома способами:
- Cron-задача: кожні 6–24 години (залежить від активності колекції) перевіряє всіх користувачів і синхронізує ролі.
- Event-driven: підписка на Transfer-події контракту через WebSocket — ролі оновлюються миттєво, але потребує стабільного з'єднання 24/7.
Технічні деталі реалізації event-driven підходу
Для підписки на Transfer-події використовуємо WebSocket-провайдера Infura або Alchemy. При виявленні події бот отримує адресу відправника та отримувача, порівнює з базою верифікованих користувачів і оновлює ролі. Щоб знизити навантаження, впроваджено чергу завдань на базі Bull з Redis.| Параметр | Cron-підхід | Event-driven |
|---|---|---|
| Актуальність | До 24 годин затримки | Миттєво |
| Навантаження на RPC | Низьке (періодичні запити) | Високе (постійний стрім) |
| Складність реалізації | Низька | Середня (WebSocket) |
| Рекомендується для | Повільних колекцій (<100 tx/день) | Активних (>100 tx/день) |
Ми гарантуємо uptime 99.9% та своєчасне оновлення ролей. Для активних колекцій event-driven підхід окупається за рахунок миттєвої реакції — це знижує ризики витоку даних у закритих каналах. Згідно з дослідженнями ринку, 80% великих NFT-проєктів використовують подібну архітектуру.
Процес роботи та терміни
| Етап | Терміни | Результат |
|---|---|---|
| Налаштування | 0.5 дня | Discord Application, permissions, конфігурація ролей |
| Розробка | 2–3 дні | Core-бот, verify flow, мультиконтрактна логіка, ревалідація, БД |
| Тестування | 0.5–1 день | Перевірка на staging, edge cases, коректність ролей |
| Деплой та документація | 0.5 дня | Деплой на VPS (Docker + PM2), README, навчання команди |
Базовий бот з верифікацією одного контракту — 2–3 дні. З мультиконтрактною логікою, кастомними ролями та event-driven ревалідацією — 4–5 днів. Вартість розраховується індивідуально.
Склад послуги
- Вихідний код бота з коментарями
- Документація з розгортання та налаштування
- Доступи до приватного репозиторію
- Навчання адміністраторів сервера (1 година)
- Підтримка протягом 14 днів після здачі
Ми автоматизували понад 50 проєктів з верифікації холдерів за 5 років роботи. Наш підхід швидший та надійніший за готові рішення в 2–3 рази: ми не використовуємо публічні API, налаштовуємо ревалідацію під активність колекції та гарантуємо uptime 99.9%. Рішення на основі готових ботів часто вимагають щомісячної підписки — наш варіант дозволяє заощадити до 40% бюджету в довгостроковій перспективі.
Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати консультацію з архітектури. Пишіть у Telegram або на пошту — оцінимо задачу за один день.