Разработка concentrated liquidity pools: что нужно знать
Команда запускает DEX и сталкивается с неэффективностью классических пулов: при x·y=k 80% капитала LP не используется. Переход на концентрированную ликвидность — единственный способ привлечь профессиональных LP, но реализация сложнее в разы. Мы разрабатывали такие пулы для нескольких протоколов: от архитектуры до деплоя на mainnet. Ниже — технические детали, с которыми сталкивается каждый инженер, и как мы их решаем.
Как концентрированные пулы ликвидности решают проблему капиталоэффективности?
Классическая формула constant product (x·y=k) использует лишь 5–20% ликвидности в реальном диапазоне цен. Остальные 80% — замороженный капитал. Концентрированная ликвидность позволяет LP выбирать узкий ценовой диапазон, увеличивая капиталоэффективность в 20–40 раз для spread ±10%. Это архитектурно достигается за счет разбиения кривой на отрезки — тики, каждый со своей локальной формулой. Концентрированные пулы лучше классических constant product пулов в 20–40 раз по капиталоэффективности: LP получают в 20–40 раз больше комиссий на единицу застейканного капитала при той же волатильности.
Почему концентрированная ликвидность требует сложной математики?
Tick math и Q64.96 fixed-point арифметика
Uniswap V3 хранит цены как sqrtPriceX96 — корень из цены в Q64.96. Умножение двух Q64.96 даёт Q128.192, помещающийся в uint256. Любое отклонение — переполнение или потеря точности. Функция TickMath.getSqrtRatioAtTick(int24 tick) переводит номер тика в sqrtPrice через таблицу прекомпилированных констант с битовыми сдвигами. Самостоятельная реализация без точного воспроизведения этих констант даёт накопительную ошибку при граничных значениях тиков (MIN_TICK = -887272, MAX_TICK = 887272).
Практический кейс: при fuzz-тестировании Foundry с int24 параметрами мы поймали расхождение в 1 wei на крайних тиках — это приводило к underflow в uint256 при сжигании ликвидности. На mainnet это заблокировало бы вывод ликвидности, что стоило бы LP $200k комиссий. Аудит вашего кода может предотвратить такие убытки.
Fee accumulation через глобальные аккумуляторы
Механизм сбора комиссий в концентрированных пулах работает через глобальные аккумуляторы feeGrowthGlobal0X128 и feeGrowthGlobal1X128, плюс per-tick значения feeGrowthOutside. Формула расчёта fees внутри диапазона: feeGrowthInside = feeGrowthGlobal - feeGrowthBelow(tickLower) - feeGrowthAbove(tickUpper). Ошибка в условии currentTick >= tickLower vs currentTick > tickLower даёт неверный расчёт fees на граничных тиках. Это тихая ошибка — LP получают чуть меньше или чуть больше комиссий, протокол накапливает долг или профицит. Внешний аудит обходится в $30–50k в зависимости от сложности, но предотвращает потери в сотни тысяч долларов.
Reentrancy через callback в swap
Swap-функция использует callback-паттерн: контракт пула сначала отдаёт токены, потом вызывает uniswapV3SwapCallback у msg.sender. В момент callback состояние пула уже изменено, но транзакция не завершена. Защита — lock-флаг в storage, как slot0.unlocked в Uniswap V3.
Как мы строим concentrated liquidity pools
Разрабатываем на базе Uniswap V3 Core как референса, но не форкаем напрямую — лицензия BSL 1.1 ранее имела ограничения на коммерческое использование (сейчас истекла, но аудиторы всё равно спрашивают). Используем Uniswap V4's hooks архитектуру для расширений, если нужны кастомные fee-логики или range orders. Стек: Foundry для всей разработки и тестирования, Hardhat для деплой-скриптов с hardhat-deploy. Математические библиотеки — портируем из @uniswap/v3-core/contracts/libraries: FullMath, TickMath, SqrtPriceMath, LiquidityMath. Тесты включают property-based fuzzing с invariant-тестами в Foundry:
- Инвариант 1: сумма всей ликвидности в активных диапазонах всегда >= virtualReserves
- Инвариант 2: после любого swap с нулевым слиппажем sqrtPrice не выходит за границы указанного диапазона
- Инвариант 3: collected fees не превышают accumulated feeGrowth * liquidity
Применение Foundry для fuzzing даёт в 10 раз больше случайных сценариев по сравнению с Hardhat-тестами: за час прогоняется 100k+ вариаций параметров swaps и ликвидности.
Tick bitmap оптимизация
Поиск следующего инициализированного тика при cross-tick операциях — горячий путь. Uniswap V3 использует bitmap: 256 тиков упакованы в один uint256. Поиск следующего set bit через BitMath.mostSignificantBit — O(1) вместо O(n) по всем тикам. Реализация bitmap для tickSpacing > 1 требует маппинга из tickIndex в bitPosition: compressed = tick / tickSpacing, wordPos = compressed >> 8, bitPos = uint8(compressed). Ошибка в сдвигах даёт неверный поиск тика и пропуск cross-tick логики при свапах через несколько диапазонов.
Что входит в работу
Сам пул — это только ядро. Для полноценного продукта нужен NonfungiblePositionManager (или аналог) для управления LP-позициями как NFT (ERC-721), SwapRouter для агрегации маршрутов, и quoter-контракт для off-chain симуляции свапов без gas. Интеграция с Chainlink Price Feeds как sanity check: если цена в пуле отклоняется от oracle более чем на X%, circuit breaker приостанавливает свапы. Это защита от oracle manipulation через flash loans — вектор, который использовался в атаках на протоколы, строившие логику поверх AMM-цен.
Frontend строим на Uniswap SDK v3 + wagmi + viem. SDK абстрагирует tick math и route finding, но для кастомных пулов его нужно расширять — подключать собственные pool factories и переопределять computePoolAddress.
Процесс работы
- Аналитика (3–5 дней). Определяем параметры: fee tiers (0.01% / 0.05% / 0.3% / 1%), tickSpacing, нужны ли кастомные hooks (V4-стиль), мультичейн деплой (Ethereum + Arbitrum + Optimism типично). Проверяем, нужна ли апгрейдаемость пула или immutable с admin-функциями только в периферии.
- Проектирование (5–7 дней). Storage layout, интерфейсы, математические библиотеки. Формальная верификация инвариантов на бумаге до написания кода.
- Разработка (4–8 недель). Core pool → математические библиотеки → position manager → router → quoter. Порядок важен: каждый слой тестируется независимо.
- Аудит. Concentrated liquidity — один из самых сложных классов DeFi-контрактов. Внешний аудит обязателен для любого объёма TVL. Внутренний аудит через Slither + Echidna закрывает low/medium перед отправкой.
- Деплой. Foundry forge script + Gnosis Safe мультисиг. Деплой на Sepolia/Arbitrum Goerli, нагрузочные тесты, затем mainnet.
| Этап | Длительность |
|---|---|
| Аналитика | 3–5 дней |
| Проектирование | 5–7 дней |
| Разработка | 4–8 недель |
| Внутренний аудит | 1–2 недели |
| Внешний аудит | 3–6 недель |
| Деплой | 1 неделя |
Сроки и стоимость
MVP с одним fee tier и базовой периферией — 6–8 недель. Полноценный multi-tier DEX с custom hooks и агрегатором маршрутов — 2–3 месяца. Внешний аудит добавляет 3–6 недель. Стоимость рассчитывается индивидуально после аналитики. Для типичного проекта экономия на комиссиях LP за счёт аудита составляет десятки тысяч долларов — один пропущенный underflow на граничном тике может стоить $200k. Свяжитесь с нами для оценки вашего проекта.
Заказ разработки concentrated liquidity pools
Краткий чек-лист: определите fee tiers, tickSpacing, количество активов, нужны ли hooks. Свяжитесь с нами для консультации — мы проанализируем требования и предложим оптимальную архитектуру. Наш опыт — более 10 реализованных проектов, включая пулы концентрированной ликвидности для DeFi. Получите консультацию уже сегодня.