Разработка системы виртуального AMM для perpetuals

Разработка системы виртуального AMM для perpetuals

Perpetual futures без виртуального AMM — это либо orderbook (требует маркет-мейкеров, сложно для децентрализованного запуска), либо funding rate arbitrage с oracle price (уязвимо к manipulation). vAMM решает задачу price discovery для бессрочных фьючерсов через виртуальные резервы: реальных токенов в пуле нет, но механизм ценообразования работает как будто они есть. Perpetual Protocol v1 первым внедрил эту модель, v2 переехал на Uniswap V3 как ценовой движок.

Математика vAMM и её проблемы

Виртуальные резервы и k

vAMM использует x * y = k, где x и y — виртуальные резервы, не реальные токены. Трейдер открывает long ETH: виртуальный USDC уходит в пул, виртуальный ETH выходит. Цена сдвигается как в обычном AMM.

Главная проблема: выбор начального k определяет глубину рынка. Слишком малый k — высокий price impact, торговать невыгодно. Слишком большой k — позиции можно открыть без заметного сдвига цены, но funding rate не работает как должен.

В Perpetual Protocol k пересчитывался при изменении ликвидности — механизм называется liquidity migration. При смене k все открытые позиции должны быть пересчитаны по новым виртуальным резервам. Ошибка в этом пересчёте = неверное PnL для всех держателей позиций.

Формально: если трейдер открыл long при x1, y1 и ищет свою exit price при новых x2, y2 после k-resizing — нужно корректно маппить его entry point через invariant ratio. Без этого протокол занижает или завышает PnL.

Funding rate mechanism

Funding rate — механизм привязки vAMM цены к spot oracle. Если vAMM цена выше oracle (long premium): long-держатели платят short-держателям. Это создаёт арбитражный стимул открывать short, что возвращает цену к oracle.

Формула funding rate (8-часовой): FR = (markPrice - indexPrice) / indexPrice / 8

Где markPrice — TWAP vAMM за последние 8 часов, indexPrice — oracle price (Chainlink).

Уязвимость: при низкой ликвидности vAMM кто-то с достаточным капиталом может сдвинуть markPrice, собрать несправедливый funding с контрпозиций. Это не flash loan атака — flash loan не переживает более одного блока, но multi-block manipulation возможна.

Защита: cap на funding rate (обычно 0.1% за 8 часов = 0.3% в день = ~109% годовых), что делает manipulation дорогостоящей относительно профита.

Insurance fund и bad debt

При резком движении цены против большой позиции с leverage — liquidation может не успеть закрыть позицию до того, как collateral уйдёт в ноль. Протокол принимает убыток — bad debt. Insurance fund покрывает эти случаи.

Источники insurance fund:

• Часть trading fees (обычно 10-25%)
• Ликвидационные штрафы от трейдеров
• Начальное финансирование от команды/DAO

При нулевом insurance fund bad debt размазывается по всем держателям обратной стороны — socialised loss. Это существенно нарушает ожидания пользователей, поэтому нужен явный механизм и мониторинг balance insurance fund.

Архитектура контрактов

ClearingHouse — центральный координатор

ClearingHouse управляет открытием/закрытием позиций, расчётом PnL, ликвидациями и funding payments. Это самый сложный контракт системы.

Ключевые функции:

function openPosition(OpenPositionParams calldata params) external returns (uint256 base, uint256 quote);
function closePosition(ClosePositionParams calldata params) external returns (uint256 base, uint256 quote);
function liquidate(address trader, address baseToken) external;
function settleFunding(address trader, address baseToken) external;

PnL трейдера: openNotional (USDC эквивалент при открытии) vs closeNotional (при закрытии) + accumulated funding payments.

Хранение позиций: маппинг trader → token → Position. Position включает openNotional, openNotionalSharesAsBase (для concentrated liquidity модели), lastTwPremiumGrowthGlobal (для расчёта накопленного funding).

AccountBalance — изоляция margin

Isolated margin vs cross margin — архитектурное решение с серьёзными trade-off-ами:

Cross margin: весь collateral трейдера используется как маржа для всех позиций. Более капиталоэффективно, но потеря на одной позиции может ликвидировать все.

Isolated margin: каждая позиция имеет отдельный collateral. Ликвидация одной позиции не затрагивает другие. Сложнее в реализации — нужен AccountBalance контракт с per-position collateral tracking.

Для initial launch рекомендуем cross margin с опциональной изоляцией на уровне UI (пользователь сам ограничивает размер позиции). Изолированный margin добавляет сложность ликвидации — нужно определять какой collateral принадлежит какой позиции при частичных ликвидациях.

Vault и collateral management

Vault принимает USDC (или другой collateral), выдаёт internal accounting token. При открытии позиции funds lock-ируются в vault, при закрытии — возвращаются с PnL.

ERC-4626 стандарт применим если vault yield-bearing (collateral инвестируется в Aave пока не задействован). Это улучшает UX: tradeры получают yield на неиспользуемый collateral. Риск: Aave exploit = потеря collateral. Нужен circuit breaker: мгновенный вывод из Aave при аномальных событиях через guardian multisig.

Oracle интеграция

Oracle — критически важный компонент. Используем Chainlink aggregator для index price (ETH/USD). Но Chainlink heartbeat = 1 час для стейблкоинов, 1 час для ETH — слишком редко для активной торговли.

Решение: Chainlink Data Streams (pull-based, обновления каждые 100ms) или Pyth Network (Solana native, но есть Evm-совместимая версия через pythnet с суб-секундными обновлениями). Для perpetuals на Ethereum L2 — Pyth + Chainlink composite: Pyth для realtime mark price, Chainlink для settlement.

Защита от stale price: если oracle не обновлялся > N минут (configurable), приостанавливаем открытие новых позиций. Ликвидации продолжаются — это критично для solvency протокола.

Ликвидации

Partial vs full liquidation

При partial ликвидации закрывается часть позиции, достаточная чтобы вернуть margin ratio выше maintenance margin. Пользователь теряет меньше. Но вычисление оптимального partial liquidation amount — нетривиально: нужно решить уравнение margin_after_partial = (notional - liquidated_notional) * maintenance_margin.

Full liquidation — проще, но агрессивнее. Для small positions (< $500) — full ликвидация оправдана gas-экономией.

Liquidation incentives

Ликвидаторам нужен стимул. Стандартная схема: ликвидационный penalty = 2.5% от notional позиции, из которых 1.25% идёт ликвидатору, 1.25% в insurance fund.

Проблема с MEV: ликвидации видны в mempool, боты делают sandwich, атакуя сам протокол или вынуждая ликвидации раньше времени через oracle manipulation. Flashbots Protected Transactions для ликвидационных ботов.

Стек и тестирование

Solidity 0.8.x + Foundry + OpenZeppelin. Chainlink + Pyth для oracle. Foundry fork-тесты на Arbitrum mainnet state: тестируем ликвидационные сценарии с реальными ценами ETH из исторических данных. Echidna с invariant тестами:

• Инвариант: totalLongExposure == totalShortExposure + netSkew (vAMM zero-sum)
• Инвариант: vaultBalance >= sum(allPositionCollateral) + insuranceFund
• Инвариант: после любой ликвидации marginRatio(trader) >= maintenanceMarginRatio

Нарушение любого инварианта — критический баг.

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

Аналитика (5-7 дней). Экономическая модель: leverage limits, funding rate caps, insurance fund initial size, collateral types (single collateral vs multi-collateral). Выбор чейна: Arbitrum One наиболее популярен для perp DEX.

Проектирование (7-14 дней). Formal specification инвариантов. Storage layout ClearingHouse (критично — миграция дорого). Интерфейсы между контрактами.

Разработка (8-12 недель). vAMM → Vault → AccountBalance → ClearingHouse → Oracle adapters → Liquidation engine. Параллельно — фронтенд (wagmi + viem + recharts для P&L графиков).

Аудит (обязателен). Perp протокол — один из самых аудируемых классов DeFi. Минимум два независимых аудита рекомендовано для TVL > $5M.

Ориентиры по срокам

Базовый vAMM с одним market, cross margin, full liquidation — 6-8 недель. Production-ready мультимаркет протокол с isolated margin, partial liquidation, insurance fund и multi-oracle — 2-4 месяца. Аудит — 4-8 недель дополнительно.

Стоимость зависит от количества market-ов, collateral типов и требований к децентрализации governance.