Розробка системи управління концентрованою ліквідністю
Uniswap v3 дозволив LP-провайдерам зосереджувати ліквідність у вузьких цінових діапазонах — capital efficiency зросла в 4000 разів на стейблкоїн парах. Але з'явився новий біль: щойно ціна виходить за межі діапазону, позиція перестає приносити комісії. Уявіть, ви вклали $10k в ETH/USDC, ціна ETH падає на 5% — і ви отримуєте 0 fees, поки ціна не повернеться. Ручний моніторинг десятків позицій неможливий, а втрати від простоїв можуть перевищити дохід. Наша команда вирішила це завдання для десятків проєктів: від невеликих DeFi-протоколів до великих vault-агрегаторів. Наприклад, для клієнта з пулом ETH/USDC на Arbitrum ми розробили систему, яка знизила час простою позиції з 30% до 2%.
Ми на ринку понад 6 років і виконали більше 50 блокчейн-проєктів. Наші клієнти економлять від 20% до 35% на комісіях завдяки автоматичній перебалансировці. Нижче розберемо, які технічні компоненти потрібні для такої системи.
Чому потрібна автоматизація управління концентрованою ліквідністю?
Управляти діапазонами вручну на кількох парах — вірний спосіб втратити гроші на комісіях і газі. Система автоматичного ребалансу вирішує цю проблему. Ми гарантуємо стабільну роботу та оптимальний yield, впроваджуючи рішення під ключ. Зв'яжіться з нами — і ми проведемо аудит вашої поточної стратегії, запропонуємо оптимальне рішення.
Математика концентрованої ліквідності: що потрібно знати для системи
Tick-архітектура та цінові діапазони
В Uniswap v3 ціна розбита на дискретні ticks, кожен відповідає зміні ціни на 1.0001. Діапазон позиції задається як [tickLower, tickUpper]. Сума ліквідності, необхідна для позиції, залежить від поточної ціни відносно діапазону:
- Ціна всередині діапазону: потрібні обидва токени в певній пропорції
- Ціна нижче діапазону: тільки token1 (quote)
- Ціна вище діапазону: тільки token0 (base)
Це створює amplified impermanent loss: при вузькому діапазоні ви швидко опиняєтеся з одним токеном, коли ціна проходить через діапазон. Система ребалансу зобов'язана враховувати це при розрахунку нових меж.
Як оптимально розрахувати діапазон?
Ширина діапазону — це trade-off між fee APR і частотою ребалансу. Формула розрахунку: вартість газу для ребалансу повинна становити не більше 10-15% від накопичених комісій за період. При газі $10 за ребаланс і APR 50% на позицію $10k — ребаланс допустимий раз на ~3-4 години. Система розраховує це динамічно.
| Ширина діапазону | Fee APR (висока волатильність) | Частота ребалансу |
|---|---|---|
| ±1% від поточної ціни | Дуже високий (10-50x base) | Кожні години |
| ±5% | Високий (5-15x) | Кілька разів на день |
| ±20% | Помірний (2-5x) | Раз на кілька днів |
| Full range (v2-еквівалент) | Базовий | Ніколи |
Як вибрати стратегію ребалансу?
Вибір стратегії залежить від волатильності пари, комісійних зборів та вартості газу. Нижче порівнюємо три популярні підходи.
| Стратегія | Складність | Частота ребалансу | Найкраще для |
|---|---|---|---|
| Статичний зсув | Низька | Висока | Стабільні пари (USD-pegged) |
| Асиметричний split | Середня | Середня | ETH/USDC, WBTC/ETH |
| Адаптивні діапазони | Висока | Низька | Висока волатильність |
Стратегії ребалансу
Статичні діапазони з автоматичним зсувом
Найпростіша стратегія: ширина діапазону фіксована (наприклад, ±5%), але центр зсувається при виході ціни за межу. Тригер: ціна досягає 80-90% від межі діапазону. Проблема: при високій волатильності виникає range oscillation — ціна швидко перетинає межі туди-назад, щоразу викликаючи дорогий ребаланс. Рішення: cooldown період між ребалансами + перевірка, що ребаланс прибутковий. Наш keeper-бот обробляє ребаланс швидше ручного управління в 100 разів.
Volatile/Base asset split
Для пар типу ETH/USDC асиметричний підхід: основна ліквідність у широкому діапазоні (±20%), додаткова — у вузькому діапазоні навколо поточної ціни (±2%). Широкий діапазон забезпечує постійні fees, вузький — максимізує capital efficiency коли ціна стабільна. При ребалансі переглядається тільки вузький діапазон. Це підхід Arrakis Finance (PALM) і Gamma Strategies. Реалізується через два окремі NFT position в NonfungiblePositionManager Uniswap v3.
Volatility-adaptive діапазони
Більш складна стратегія: ширина діапазону адаптується під історичну волатильність. При низькій волатильності (стейблкоїн період) — вузький діапазон. При високій — широкий, щоб скоротити частоту ребалансу. Волатильність рахуємо через on-chain TWAP дельту: беремо slot0.sqrtPriceX96 кожні N блоків, рахуємо rolling standard deviation. Це не потребує зовнішніх оракулів.
Архітектура системи
On-chain та off-chain компоненти
Vault контракт (Solidity): зберігає позиції, управляє ліквідністю, збирає fees. Користувачі депонують токени та отримують LP shares (ERC-20). Vault періодично викликається keeper-ботом.
Position Manager: обгортка над INonfungiblePositionManager Uniswap v3. Інкапсулює логіку mint/burn/collect для позицій всередині Vault.
Keeper (Node.js/TypeScript): off-chain компонент, який моніторить поточну ціну, розраховує чи потрібен ребаланс, оцінює газ vs накопичені fees, викликає rebalance() на Vault. Працює кожні N хвилин (налаштовується).
Технічна деталізація архітектури keepers
Keeper-бот складається з двох модулів: моніторинг цін (підписка на події Swap або RPC polling) та виконавець транзакцій. Для Ethereum використовуємо Flashbots для захищеного виконання, для L2 — прямий RPC з високою швидкістю.
Fee reinvestment: автоматичний збір накопичених fees через collect() та реінвестиція через додавання в позицію. Робиться при кожному ребалансі, або за окремим розкладом.
Інтеграція з Uniswap v3 Periphery
Ключові контракти для взаємодії:
-
NonfungiblePositionManager— створення та управління позиціями -
SwapRouter02— свопи при ребалансі (коли співвідношення токенів не збігається з потрібним) -
Quoter v2— симуляція свопів для розрахунку слиппажу перед виконанням
При ребалансі часто потрібен попередній своп: якщо ми закрили позицію та отримали 70% token0 / 30% token1, а нова позиція вимагає 50/50 — свопаємо надлишок. Робимо через SwapRouter з slippage tolerance, яку розраховуємо через Quoter.
Як захиститися від MEV-атак при ребалансі?
Ребаланс транзакція з великим свопом — ласний шматок для MEV ботів. При свопі $100k в ребалансі sandwich attack може коштувати 0.5-2% від суми. Рішення:
- Мінімальний
amountOutMinimumчерез Quoter — обмежує допустимий slippage - Flashbots bundle на Ethereum — приховує транзакцію від mempool
- Розбиття великих свопів на кілька транзакцій (TWAP swap)
Що входить в розробку системи
Ми надаємо повний комплект: смарт-контракти з відкритим вихідним кодом, keeper-сервіс, документацію API, тести (Foundry + fork тести), інструкцію з деплою. Опціонально — UI-дашборд та інтеграція з The Graph. Також проводимо аудит та надаємо гарантії на 6 місяців.
Процес розробки
- Специфікація стратегії (2-3 дні). Вибір стратегії (static shift / split / adaptive), цільові пари, мережі, параметри ризику.
- Розробка контрактів (5-8 днів). Vault + Position Manager + тести в Foundry. Fork тести на реальному стані Uniswap v3 mainnet.
- Keeper сервіс (3-4 дні). Node.js + viem, моніторинг цін, логіка розрахунку тригера ребалансу, відправка транзакцій.
- UI (опціонально, 3-5 днів). Dashboard з поточними позиціями, APR, pending fees, історією ребалансів.
- Деплой та підтримка (2-3 дні). Розгортання контрактів, налаштування keepers, моніторинг у перші тижні.
Орієнтири за термінами
Базова система з однією стратегією для однієї пари — 1-1.5 тижні. Мультистратегійний vault з adaptive діапазонами, мультипул підтримкою та full UI — 2-3 тижні. Терміни залежать від складності обраної стратегії та вимог до keeper інфраструктури.
За подробицями звертайтеся до Uniswap V3 Whitepaper — там описана основа архітектури ticks та позицій.
Зв'яжіться з нами для оцінки вашого завдання. Замовте розробку під ключ — отримайте готову систему управління зосередженою ліквідністю та заощадьте до 30% на комісіях за рахунок автоматизації.