Система алертов о token unlock: мониторинг vesting-контрактов

Представьте: вы держите портфель альткоинов, и внезапно цена одного из проектов обваливается на 15% за час. Причина — крупный token unlock, о котором вы не знали. Такие события предсказуемы, но без автоматизации их сложно отследить вовремя. Мы создаём систему, которая за 3 дня предупреждает о разблокировках, давая время скорректировать стратегию. Своевременный алерт позволяет трейдерам и инвесторам заранее хеджировать позиции или выйти из токена до распродажи. Наш опыт в blockchain-разработке превышает 10 лет, и мы внедрили аналогичные решения для 20+ криптофондов.

Какие риски несут анлоки?

Каждый анлок создаёт предсказуемое давление продаж. Команды, инвесторы и advisors получают токены после клиффа — это известное событие. Автоматизированная система обнаруживает анлоки в среднем на 3-4 дня раньше ручного отслеживания. Это время — решающее для принятия решения. Гарантия точности данных подтверждается on-chain верификацией. Своевременный алерт сокращает затраты на мониторинг примерно на $2,000–$4,000 в месяц для инвестиционных команд, экономя ресурсы аналитиков.

Как работает система алертов о token unlock?

Система каждые 5 минут сканирует on-chain данные vesting-контрактов (Ethereum, Polygon, Arbitrum, BNB Chain). Используем стандартные паттерны: Vesting от OpenZeppelin, TokenVesting от Gnosis, а также кастомные реализации. Для каждого контракта вычисляем releasable количество и дату end(). Если до анлока остаётся менее 7 дней и объём превышает порог — формируется алерт.

Пример кода для мониторинга через ethers.js:

// Отслеживание VestingWallet событий
const vestingABI = [
    "event ERC20Released(address indexed token, uint256 amount)",
    "function releasable(address token) view returns (uint256)",
    "function end() view returns (uint256)"
];

async function checkUpcomingUnlocks(vestingAddresses, tokenAddress, provider) {
    const alerts = [];
    const now = Math.floor(Date.now() / 1000);
    const sevenDaysFromNow = now + 7 * 24 * 3600;
    
    for (const addr of vestingAddresses) {
        const contract = new ethers.Contract(addr, vestingABI, provider);
        
        try {
            const endTime = await contract.end();
            const releasable = await contract.releasable(tokenAddress);
            
            if (releasable > 0n && Number(endTime) <= sevenDaysFromNow) {
                alerts.push({
                    vestingContract: addr,
                    unlockAmount: ethers.formatUnits(releasable, 18),
                    unlockTimestamp: Number(endTime),
                    daysUntilUnlock: (Number(endTime) - now) / 86400
                });
            }
        } catch (e) {
            // Контракт не реализует интерфейс — пропускаем
        }
    }
    
    return alerts;
}

Какие источники данных использует система?

Основных источника три: on-chain данные из vesting-контрактов, off-chain расписания из баз данных (TokenUnlocks, Vesting.vc, CryptoRank) и аналитика из первичных документов (whitepaper, tokenomics sheets). Сравнение подходов:

Как настроены пороги значимости?

Пороги задаются в процентах от circulating supply, а не по абсолютному объёму. Рекомендуемые значения:

Для проекта с малым supply (10M) даже 0.5% — это 50k токенов, что может быть критично. Система автоматически адаптирует рекомендации.

Какие каналы доставки мы поддерживаем?

Алерт содержит проект, объём unlock в токенах и долларах (по текущей цене), категорию получателей, дату, ссылку на on-chain источник. Сравнение каналов:

Приоритет канала настраивается пользователем.

Что такое vesting-контракт?

Vesting-контракт — это смарт-контракт, который блокирует токены на определённый срок (клифф) и постепенно разблокирует их по расписанию. Стандарт OpenZeppelin VestingWallet позволяет гибко настраивать параметры. Мы работаем как с готовыми реализациями, так и с кастомными контрактами, обеспечивая совместимость с любым блокчейном.

Процесс разработки

1. Анализ требований и выбор источников данных.
2. Проектирование архитектуры: сборщики, парсеры, очередь сообщений.
3. Реализация мониторинга и отправки алертов.
4. Тестирование на тестовых контрактах (Tenderly, hardhat fork).
5. Деплой и настройка мониторинга.

Что входит в работу

• Документация по интеграции API.
• Доступ к тестовому стенду.
• Обучение команды работе с панелью управления.
• Сопровождение в течение 1 месяца после запуска.
• Гарантия исправления ошибок в течение 30 дней.

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

MVP с мониторингом топ-100 проектов, Telegram + Email алертами и веб-интерфейсом занимает 6–8 недель. Полноценная платформа с API, поддержкой кастомных vesting-контрактов и аналитикой — 3–4 месяца. Стоимость рассчитывается индивидуально. Оценим ваш проект бесплатно — свяжитесь с нами.

Закажите разработку системы алертов уже сегодня. Наши инженеры готовы помочь. Получите консультацию для предварительной оценки.

Разработка токенов: 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 недель