Розробка системи моніторингу vesting-розкладів

Розробка системи ретроактивних балів для airdrop

Ретроактивний airdrop — це награда користувачам, які вже взаємодіяли з протоколом до моменту snapshot. Ідея: замість того щоб раздавати токени всім підряд по whitelist-у, проект вознаграджує реальних учасників — тих, хто торгував, надавав ліквідність, використовував governance. Перший масштабний прецедент — Uniswap в 2020 році. Після нього модель points + airdrop стала стандартом індустрії.

Проблема в тому, що наївна реалізація («взяв on-chain дані, розрахував баллы, роздав токени») не працює. Sybil-атаки — одна адресна ферма з сотнями гаманців з'їдає 30–60% allocation. Токени без vesting негайно дампляться. Тому система балів — це не просто SQL-запити по on-chain даним, а інфраструктура з багаторівневим захистом і продуманою механікою.

Архітектура points-системи

Off-chain vs on-chain підрахунок

Більшість production-систем рахують баллы off-chain та публікують Merkle root в смарт-контракт. Причина проста: повний on-chain підрахунок з історичними даними нереальний по газу. Схема:

1. Індексація on-chain подій через The Graph або власний indexer (PostgreSQL + event модель)
2. Розрахунок балів за правилами (Python/TypeScript скрипт, воспроизводимий та аудируємий)
3. Публікація підсумкової таблиці address → points в IPFS
4. Побудова Merkle tree з цієї таблиці
5. Запис Merkle root в контракт airdrop

Користувач при claim надає Merkle proof своєї адреси та кількості балів. Контракт перевіряє proof проти root — не потрібно зберігати on-chain усіх 500k+ адрес.

Структура правил нарахування балів

Хороша points-система багатовимірна. Приклад для DEX-протоколу:

Temporal decay — важливий параметр. Ранні користувачі отримують множитель, який зменшується по мірі наближення до snapshot. Це стимулює взаємодію заздалегідь, а не rush в останній момент.

Sybil-захист

Найбільш технічно складний компонент. Стандартні підходи:

On-chain кластерний аналіз. Адреси, які фінансуються з одного джерела, використовують однакові паттерни газу, взаємодіють в одинаковий UTC час — флагуються як потенціальні кластери. Інструменти: Hop Protocol використав аналіз транзакційних графів; Arbitrum застосував комбінацію фінансового аналізу та активності.

Мінімальні пороги. Адреса з обсягом менше $500 та менше 5 транзакцій — виключається повністю. Це відсікає більшість автоматичних ферм з мінімальними депозитами.

Верифікація через Gitcoin Passport або Worldcoin. Опціонально: користувач з верифікованою ідентичністю отримує бонусний множитель (1.5–2x). Це стимулює верифікацію без hard requirement-а.

Decay балів для швидких гаманців. Якщо гамань з'явився за 2 тижні до snapshot та одразу набрав максимум — баллы урізуються на 50–80%. Органічні користувачи взаємодіють протягом місяців.

Контракт airdrop з vesting

Базова Merkle-based структура

contract AirdropWithVesting {
    bytes32 public merkleRoot;
    mapping(address => uint256) public claimedAmount;
    mapping(address => uint256) public vestingStart;
    
    uint256 public constant CLIFF = 30 days;
    uint256 public constant VESTING_DURATION = 180 days;
    
    function claim(
        uint256 totalPoints,
        uint256 tokenAmount,
        bytes32[] calldata proof
    ) external {
        bytes32 leaf = keccak256(abi.encodePacked(msg.sender, tokenAmount));
        require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
        require(vestingStart[msg.sender] == 0, "Already claimed");
        
        vestingStart[msg.sender] = block.timestamp;
        // токени переводяться в контракт vesting, не сразу користувачу
        _startVesting(msg.sender, tokenAmount);
    }
}

Vesting замість мгновенного release — стандарт після того як airdrop-и без vesting (наприклад, раздача токенів новим L2-проектам) негайно дампилися на 80–90% в перший день.

Лінійний vesting з cliff

Після cliff-а (30–90 днів) починається лінійний vesting на 3–6 місяців. Claim в будь-який момент вивільняє накопичену частину:

function claimable(address user) public view returns (uint256) {
    if (block.timestamp < vestingStart[user] + CLIFF) return 0;
    uint256 elapsed = block.timestamp - (vestingStart[user] + CLIFF);
    uint256 vested = (totalAllocation[user] * min(elapsed, VESTING_DURATION)) / VESTING_DURATION;
    return vested - claimedAmount[user];
}

Інструменти індексації та розрахунку

The Graph — стандарт для індексації подій. Subgraph на AssemblyScript описує обробники для кожної события протоколу, дані зберігаються в GraphQL-доступній базі. Запити для розрахунку балів — GraphQL з агрегацією.

Dune Analytics — швидкий спосіб прототипувати правила нарахування через SQL без власної інфраструктури. Не підходить для production-розрахунків (немає гарантії реального часу), але відмінно для валідації методології.

Власний indexer — PostgreSQL + event listener (ethers.js або viem). Повний контроль над даними, можливість складних JOIN-запитів. Вимагає підтримки інфраструктури.

Stack та строки

Calculation backend: Python (pandas для трансформацій) або TypeScript. Merkle tree: OpenZeppelin merkle-tree бібліотека (JavaScript). Смарт-контракт: Solidity 0.8.x + Foundry. Тестування: генерація тестових Merkle proof-ів в Foundry-тестах.

Типові строки: дизайн правил та аналіз даних — 2–3 тижні, розробка контракту та indexer-а — 3–4 тижні, sybil-аналіз та фінальний snapshot — 1–2 тижні.

Вартість визначається після уточнення протоколу, кількості адрес та вимог до sybil-захисту.