Розробка concentrated liquidity pools: що треба знати

Розробка 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.

Процес роботи

1. Аналітика (3–5 днів). Визначаємо параметри: fee tiers (0.01% / 0.05% / 0.3% / 1%), tickSpacing, чи потрібні кастомні hooks (V4-стиль), мультичейн деплой (Ethereum + Arbitrum + Optimism типово). Перевіряємо, чи потрібна апгрейдаємість пулу або immutable з admin-функціями тільки в периферії.
2. Проектування (5–7 днів). Storage layout, інтерфейси, математичні бібліотеки. Формальна верифікація інваріантів на папері до написання коду.
3. Розробка (4–8 тижнів). Core pool → математичні бібліотеки → position manager → router → quoter. Порядок важливий: кожен шар тестується незалежно.
4. Аудит. Concentrated liquidity — один з найскладніших класів DeFi-контрактів. Зовнішній аудит обов'язковий для будь-якого об'єму TVL. Внутрішній аудит через Slither + Echidna закриває low/medium перед відправкою. Наша компанія має понад 5 років досвіду в блокчейн-розробці, тому ми гарантуємо якість.
5. Деплой. Foundry forge script + Gnosis Safe мультисиг. Деплой на Sepolia/Arbitrum Goerli, навантажувальні тести, потім mainnet.

Терміни та вартість

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. Отримайте консультацію вже сьогодні.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.