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

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

Quest-платформи — це Galxe, Zealy, Layer3 у ролі моделі. Механіка зрозуміла: користувач виконує завдання (підписується на Twitter, робить swap, тримає токен), отримує XP або NFT. Технічна складність не в самих завданнях, а в верифікації — як довести, що користувач дійсно зробив on-chain дію, а не просто нажав кнопку.

Верифікація завдань: 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 в контракті, індексувати його.

Sybil resistance

Головна проблема 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 з сервера та клеймить сам, платячи газ. Це знижує нагрузку на сервер та децентралізує claiming.

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.

Розробка займає 1–2 тижні: базова система з кількома типами завдань, верифікацією та простою системою наград — 1 тиждень. Повна платформа з anti-sybil, Merkle-based claiming, social integrations та leaderboard — 2 тижні.