Разработка системы quest/task-платформы для крипто-проекта
Мы создаём quest-платформы под ключ — от дизайна on-chain верификации до развёртывания смарт-контрактов для наград. Основная боль заказчика: как доказать, что пользователь выполнил задание, не доверяя его словам? On-chain действия требуют проверки транзакций через RPC, а off-chain — интеграции OAuth. При этом любой просчёт в верификации открывает путь для sybil-атак, когда один пользователь накручивает рейтинг сотнями кошельков.
На практике верификация транзакций на Ethereum занимает 2–5 секунд, а проверка баланса токенов — до 10 секунд при загруженности сети. Для off-chain заданий, таких как подписка в Twitter, время проверки не превышает 1 секунды. Однако скоростная верификация не гарантирует защиту от накруток — здесь нужен комплексный подход с использованием снимков состояния и анти-sybil фильтров.
Мы используем комбинацию методов: для off-chain — OAuth 2.0 с PKCE (Twitter, Discord), для on-chain — вызовы RPC через publicClient с подтверждением событий. Каждый запрос логируется, а данные кешируются на 5 минут, чтобы избежать лишних запросов к блокчейну.
Верификация заданий: on-chain vs off-chain
Off-chain задания
Twitter follow, Discord join, email подписка — верификация через OAuth:
- Twitter: OAuth 2.0 с PKCE, проверка через Twitter API v2 (
GET /2/users/:id/following) - Discord: OAuth2 + Discord Bot API для проверки членства в сервере и наличия роли
- Telegram: Telegram Login Widget + Bot API (
getChatMember)
Всё это серверная логика. Важно хранить OAuth токены зашифрованными и обновлять их — Twitter access token живёт 2 часа.
On-chain задания
Это интереснее и сложнее. Типичные категории:
Holder verification — пользователь должен держать X токенов или NFT определённой коллекции. Верификация: balanceOf(address) вызов через RPC. Просто, но нужно решить проблему времени проверки — баланс мог быть на момент snapshot, а сейчас нет.
Transaction verification — пользователь сделал swap, предоставил ликвидность, сделал бридж. Верификация через индексер или RPC:
// Проверяем, делал ли адрес swap на Uniswap v3 за последние N дней const logs = await publicClient.getLogs({ address: UNISWAP_V3_ROUTER, event: parseAbiItem('event Swap(address indexed sender, address indexed recipient, ...)'), args: { recipient: userAddress }, fromBlock: BigInt(fromBlock), toBlock: 'latest', }) const completed = logs.length > 0 Contract interaction — пользователь вызвал конкретную функцию вашего контракта. Самый надёжный способ: emit event в контракте, индексируй его.
Сравнение on-chain и off-chain верификации
| Критерий | Off-chain | On-chain |
|---|---|---|
| Время проверки | <1 сек | 2-10 сек |
| Надёжность | Средняя (OAuth подделать можно) | Высокая (неизменяемые данные) |
| Затраты на инфраструктуру | Низкие | Средние (RPC) |
Как защититься от sybil-атак?
Главная проблема quest-платформ — sybil атаки. Один человек создаёт 1000 кошельков, выполняет все задания, собирает награды. Мы используем комбинацию методов:
- Gitcoin Passport — score на основе Web2 и Web3 активности. API:
GET /registry/score/:address. Порог score (например, 15+) отсекает большинство sybil аккаунтов. - Proof of Humanity / Worldcoin — biometric proof of unique human. Более надёжно, но friction для пользователей.
- On-chain activity score — проверяем возраст кошелька, количество транзакций, наличие ETH/активов. Новый кошелёк с нулевой историей — красный флаг.
- Rate limiting по IP + fingerprint — не безупречно, но отсекает ленивых ботоводов.
Архитектура системы
Backend
REST API (Next.js API routes или Express) ├── /api/quests — список квестов, статус ├── /api/verify/:taskId — верификация конкретного задания ├── /api/claim — получение награды после выполнения всех заданий └── /api/leaderboard — топ пользователей по XP База данных — PostgreSQL:
-
users: address, twitter_id, discord_id, passport_score -
quests: id, title, reward_type, reward_amount, requirements JSON -
task_completions: user_id, task_id, verified_at, proof JSON -
rewards_claimed: user_id, quest_id, tx_hash
Smart contract для наград
Если награда — токены или NFT, нужен контракт:
contract QuestRewards { mapping(address => mapping(uint256 => bool)) public claimed; function claimReward( uint256 questId, bytes32[] calldata merkleProof ) external { require(!claimed[msg.sender][questId], "Already claimed"); require( MerkleProof.verify(merkleProof, questRoots[questId], keccak256(abi.encodePacked(msg.sender))), "Invalid proof" ); claimed[msg.sender][questId] = true; token.transfer(msg.sender, questRewards[questId]); } } Merkle tree подход: бэкенд формирует список eligible адресов, считает Merkle root, публикует его on-chain. Пользователь получает Merkle proof с сервера и клеймит сам, платя gas. Это снижает нагрузку на сервер и decentralizes claiming. Подробнее о Merkle tree можно прочитать в Wikipedia.
Frontend
Ключевые экраны:
- Dashboard — активные квесты, прогресс, накопленный XP
- Quest detail — список заданий с статусами (locked/available/completed/claimed)
- Leaderboard — топ участников, можно делать по неделям/всего
- Profile — история наград, connected socials
UX-деталь: статус проверки задания не должен быть синхронным. Пользователь нажал "Verify" — показываем spinner, делаем запрос на бэкенд, бэкенд проверяет on-chain/off-chain данные, возвращает результат. Типичное время — 2–5 секунд для on-chain verification.
Что входит в разработку под ключ?
| Компонент | Описание |
|---|---|
| Backend API | REST-сервер с PostgreSQL, интеграция с Twitter/Discord/Telegram OAuth |
| Смарт-контракты | Контракт на Solidity 0.8.x с Merkle-дропом наград |
| Anti-sybil | Подключение Gitcoin Passport, проверка on-chain активности |
| Frontend | Next.js / React приложение с wallet connect (RainbowKit) |
| Документация | API-документация, инструкция по развертыванию |
Наши инженеры имеют 10+ лет опыта в разработке смарт-контрактов и более 50 успешных проектов в DeFi и NFT. Мы используем Foundry для тестирования контрактов и Tenderly для мониторинга.
Ориентировочные сроки
Базовая система с несколькими типами заданий и верификацией — от 1 недели. Полная платформа с anti-sybil, Merkle-based claiming и интеграциями — до 2 недель. Точную оценку дадим после анализа ваших требований.
Типичные ошибки при разработке quest-платформ
- Использование только off-chain верификации без on-chain — пользователи обманывают систему.
- Отсутствие snapshot-логики — награды получают те, у кого баланс был секунду.
- Синхронная верификация — пользователь ждёт ответа, интерфейс зависает.
- Нет защиты от sybil — награды уходят ботам.
Избежать этих проблем помогает правильная архитектура и опыт команды. Если вы разрабатываете крипто-проект и хотите внедрить quest-систему, свяжитесь с нами — оценим проект бесплатно.







