Разработка пулов ликвидности
Команда принесла контракт пула с классической механикой x*y=k. На тестнете всё работало. На mainnet через три дня после запуска сэндвич-бот извлёк из пула $180k — цена входа на 12% выше реальной, цена выхода на 11% ниже. Никакого слиппеж-контроля на уровне контракта не было, только фронтенд проверял. Это типичная история, когда разработчики копируют механику AMM, не разбираясь в том, как работает MEV-инфраструктура Ethereum.
Где AMM-контракт ломается при деплое
Impermanent loss как архитектурное решение, а не баг
IL — это не ошибка, это математическое следствие постоянного перебалансирования. Но протоколы, которые не объясняют LP-провайдерам реальную математику, теряют ликвидность: люди видят APY 40%, забирают позицию через месяц и не понимают, почему в USD они в минусе. Задача контракта — предоставлять точные данные о позиции: текущую стоимость, накопленные комиссии, расчётный IL.
В Uniswap v3 это усложняется концентрированной ликвидностью: позиция активна только в диапазоне [tickLower, tickUpper]. Когда цена выходит из диапазона, позиция перестаёт зарабатывать комиссии и полностью конвертируется в один токен. LP-провайдер без мониторинга может неделями держать "мёртвую" позицию.
Price manipulation через flash loan в однобоких оракулах
AMM-пул, который сам является оракулом цены — точка атаки. Flash loan на 50M USDC, одна транзакция на swap — spot-цена в пуле сдвигается в 10 раз. Если ваш лендинговый протокол читает цену из этого пула — он выдаёт кредиты под манипулированный collateral. Именно так работает вектор атаки на Mango Markets ($114M в 2022).
Решение: TWAP (Time-Weighted Average Price) через Uniswap v3 oracle — IUniswapV3Pool.observe() с окном наблюдения минимум 30 минут. Или Chainlink как внешний оракул с circuit breaker: если spot и Chainlink расходятся более чем на 5% — транзакция реверсируется.
Reentrancy в callback-механике
Uniswap v2/v3 использует callback-паттерн: uniswapV2Call и uniswapV3SwapCallback. Если ваш пул реализует похожую механику и не ставит nonReentrant на функцию, которая вызывает callback — классический вектор. Атакующий через callback повторно входит в пул до обновления резервов.
В практике встречали контракт пула с функцией swap, которая обновляла reserve0 и reserve1 после вызова _callback. Reentrancy позволяла получить токены дважды при одном входе. OpenZeppelin ReentrancyGuard нужен на swap, addLiquidity, removeLiquidity — все три.
Как мы строим пулы ликвидности
Архитектурные решения
Для большинства задач не нужно писать AMM с нуля. Протоколы Uniswap v2/v3, Balancer, Curve — battle-tested код с миллиардами TVL. Задача — правильно выбрать механику под токеномику:
| Механика | Подходит для | Пример |
|---|---|---|
| x*y=k (Uniswap v2) | Общий случай, два токена | Любая пара ERC-20 |
| Concentrated liquidity (Uniswap v3) | Стейблкоины, коррелированные активы | USDC/USDT, ETH/stETH |
| StableSwap (Curve) | Стейблкоины с минимальным slippage | 3pool, FRAX |
| Weighted pools (Balancer) | 2-8 токенов с кастомными весами | 80/20 WETH/TOKEN |
| CPMM с кастомными fees | Протокольные пулы с fee-sharing | Собственный DEX |
Если задача — кастомный пул под конкретный протокол, за основу берём Uniswap v4 Hooks (если чейн поддерживает) или Balancer v2 Vault архитектуру, где общий vault хранит токены, а пулы — только логику.
LP-токены и учёт позиций
Стандарт ERC-20 для LP-токенов в Uniswap v2 — самый простой случай. Доля в пуле = lpBalance / lpTotalSupply. Проблема: при большом количестве LP-провайдеров каждый transfer LP-токена меняет относительные доли без ведома других участников.
Для Uniswap v3-style позиций используем NFT (ERC-721) — каждая позиция уникальна по тикам и размеру. Это усложняет интеграцию с другими протоколами (нельзя просто застейкать в фарм), но даёт точный учёт концентрированной ликвидности.
Fee accumulation: в Uniswap v3 комиссии накапливаются через feeGrowthInside0LastX128 и feeGrowthInside1LastX128 — глобальный счётчик минус счётчик на момент открытия позиции. При collect() происходит пересчёт. Если реализуете похожую механику — overflow в uint128 при длинных периодах без сбора комиссий даст неверные цифры; нужен unchecked arithmetic с явным комментарием.
Защита от MEV на уровне контракта
Несколько механик, которые снижают профит сэндвич-ботов:
Commit-reveal для крупных свапов. Пользователь сначала публикует хэш транзакции, через N блоков — саму транзакцию. Боты не знают параметры заранее. Трение для пользователя высокое, подходит только для крупных свапов.
Dynamic fees. Fee растёт при высокой волатильности (детектируется через отклонение от TWAP). Это делает сэндвич менее прибыльным. Реализуется через Uniswap v4 Hook или custom fee tier.
Private mempool. На уровне контракта не решается — это инфраструктурный вопрос (Flashbots Protect, MEV Blocker). Но важно предупредить клиента до деплоя.
Процесс разработки
Спецификация (2-3 дня). Определяем механику пула, токеномику LP-токенов, fee structure, роли (owner, fee collector, pause guardian). Рисуем state diagram: все переходы состояний пула, включая emergency pause.
Разработка (1-2 недели). Контракты на Solidity 0.8.x с Foundry. Fuzz-тесты на инварианты: reserve0 * reserve1 >= k никогда не нарушается, сумма всех LP-долей = totalSupply, комиссии не превышают объём свапа.
Fork-тестирование. Тесты на форке mainnet/Arbitrum — реальные цены, реальные токены, реальные MEV-боты в mempool. Используем vm.createFork в Foundry.
Внутренний аудит + Slither. Минимум за неделю до деплоя. Для TVL > $500k рекомендуем внешний аудит (Code4rena, Sherlock, Spearbit).
Деплой. forge script с верификацией, мультисиг Gnosis Safe на owner-функции, timelock на изменение fee параметров (минимум 48 часов).
Ориентиры по срокам
Базовый пул с механикой x*y=k и LP-токенами ERC-20 — от 2 недель с тестами. Пул с концентрированной ликвидностью в стиле Uniswap v3 — от 6 недель. Кастомная механика с несколькими токенами, интеграцией с внешними оракулами и fee-sharing — 2-3 месяца. Сроки аудита не включены.