Разработка системы мониторинга vesting-расписаний токенов

После масштабного airdrop токенов в протоколе на Arbitrum мы наблюдали классическую картину: держатели начали дампить позиции мгновенно, а команда не успевала отследить распределение. Через неделю цена упала на 80%, и ретроспективный анализ показал, что 40% allocation было unlocked в первый день — часть из них принадлежала сибилам. Именно тогда стало очевидно: мониторинг vesting-расписаний — не опция, а необходимость. Без него любая разблокировка токенов — это игра в рулетку.

Контракт vesting сам по себе не даёт картины. Вы видите только адрес получателя и общую сумму. А после разблокировки токены мгновенно уходят на биржи, и команда узнаёт об этом постфактум, когда цена уже обвалилась. Наша система решает три ключевые задачи: ранние алерты о грядущих unlock, аналитика распределения и контроль над корпоративными и приватными сейлами.

Как работает система: архитектура

Система состоит из трёх слоёв:

1. Индексатор событий. Подключаемся к ноде (QuickNode или Alchemy) или используем The Graph. Сканируем контракты vesting (ERC-20, ERC-721, ERC-1155 с vesting-логикой) и сохраняем события Claim, VestingCreated, Withdraw. Данные пишутся в PostgreSQL.
2. Расчётный движок. На Python или TypeScript вычисляем для каждого адреса totalVested, claimed, remaining. Применяем формулу:

function vestedAmount(address user, uint256 total) public view returns (uint256) {
    uint256 elapsed = block.timestamp - vestingStart[user];
    if (elapsed < cliff) return 0;
    uint256 duration = vestingDuration[user];
    return (total * min(elapsed - cliff, duration)) / duration;
}

3. Дашборд и алерты. Веб-интерфейс (React + Viem) показывает таблицу по всем адресам: статус, дата следующего unlock, объём. Алерты через Telegram/Slack при приближении крупных unlock или подозрительной активности.

Какие проблемы мы решаем

Сибилы ликвидируют позиции сразу после unlock. Даже с vesting 90 дней кластер ферм может скоординированно сливать токены. Решение: on-chain кластерный анализ — адреса, получившие токены из одного источника и активные в одинаковые блоки, помечаются как рисковые. Для них включается дополнительный алерт при любом движении.

Отсутствие данных по кросс-чейн мониторингу. Многие протоколы разворачивают контракты на нескольких L2 (Arbitrum, Optimism, Base). Наша система агрегирует события из всех сетей в единый дашборд. Вы видите total supply по всем цепям, а не фрагменты.

Сложность расчёта для нестандартных контрактов. Некоторые проекты используют кастомные EIP — гибрид ERC-721 с vesting-логикой. Мы адаптируем indexer под любой ABI, добавляем кастомные обработчики. Опыт таких задач у нас уже есть для NFT-маркетплейсов с платёжными стримами.

Как мы это делаем: стек и инструменты

Бэкенд: Python + Pandas для трансформаций, PostgreSQL для хранения, Redis для кэша. Смарт-контракты: Solidity 0.8.x с Foundry. Индексация: The Graph (subgraph) или собственный event listener на ethers.js. UI: React + Wagmi + RainbowKit для кошелёчного подключения. Алерты: Webhooks + Telegram Bot API.

Пример взаимодействия с контрактом через viem:

import { createPublicClient, http, parseAbi } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http(process.env.RPC_URL)
})

const abi = parseAbi([
  'function getVestingSchedule(address beneficiary) view returns (uint256 total, uint256 claimed, uint256 start, uint256 cliff, uint256 duration)'
])

const schedule = await client.readContract({
  address: vestingContract,
  abi,
  functionName: 'getVestingSchedule',
  args: [userAddress]
})

Процесс работы

1. Аналитика (1 неделя): изучаем ваши контракты, согласовываем метрики для дашборда.
2. Проектирование (1 неделя): архитектура indexer'а, схема базы, прототип UI.
3. Реализация (2–3 недели): разработка core-логики, дашборда, алертов.
4. Тестирование (1 неделя): unit-тесты, интеграция с тестнетом, симуляция unlock.
5. Деплой и обучение (1 неделя): запуск в production, передача документации.

Сроки и стоимость

Типичные сроки: от 4 до 8 недель в зависимости от количества сетей и сложности правил. Стоимость рассчитывается индивидуально после оценки объёма контрактов и требуемого функционала. Напишите нам — оценим проект и предложим решение под ключ.

Почему стоит заказать систему у нас?

У нас за плечами 7+ лет разработки на Solidity и 15+ проектов по мониторингу токенов. Мы знаем, как отличить сибилов от органических держателей, как настроить алерты без false positives и как масштабировать индексер под миллионы событий. Удельная экономия на gas анализ — до 40% по сравнению с полным on-chain подсчётом. Гарантия на все компоненты системы — 6 месяцев, поддержка входит в стоимость.

Один из кейсов. Для протокола A (DEX на Arbitrum) мы развернули мониторинг vesting за 5 недель. Система выявила кластер из 1 200 сибилов, которые планировали дампнуть 3% supply через 72 часа после cliff. Благодаря алертам команда успела обратиться к инвесторам с просьбой отсрочить unlock, и падения удалось избежать.

Типичные ошибки при мониторинге vesting

Сравнение подходов: off-chain indexer vs on-chain расчёт

Off-chain indexer в 10 раз дешевле и в 50 раз быстрее для исторических данных. Это подтверждает наш опыт: для проектов с объёмом событий более 100 000 в месяц off-chain неизменно выигрывает.

Как повысить точность алертов

Свяжитесь с нами для консультации по вашему проекту. Мы разработаем систему мониторинга, которая даст полный контроль над разблокировкой токенов и предотвратит неожиданные дампы. Для получения коммерческого предложения достаточно указать количество контрактов и сетей — мы подготовим оценку за 2 рабочих дня.

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

• ERC-20 с permit и basic governance: 2–3 недели
• Vesting контракт с revocation и cliff: 2–4 недели
• Полный governance (Governor + Timelock + Token): 4–7 недель
• Токен + LBP + governance + vesting: 8–14 недель