Разработка системы quest/task-платформы для крипто-проекта

Разработка системы quest/task-платформы для крипто-проекта Мы создаём quest-платформы под ключ — от дизайна on-chain верификации до развёртывания смарт-контрактов для наград. Основная боль заказчика: как доказать, что пользователь выполнил задание, не доверяя его словам? On-chain действия требуют

Направления блокчейн-разработки

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1441
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    998
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1267
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    713
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1003

Разработка системы 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-систему, свяжитесь с нами — оценим проект бесплатно.