Розробка 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 отримують трохи менше або трохи більше комісій, протокол накопичує борг або профіцит. Зовнішній аудит обходиться в $40 000 залежно від складності, але запобігає втратам у сотні тисяч доларів.
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 перед відправкою. Наша компанія має понад 5 років досвіду в блокчейн-розробці, тому ми гарантуємо якість.
- Деплой. 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. Отримайте консультацію вже сьогодні.