Uniswap v3: чому LP-позиції йдуть у мінус
Концентрована ліквідність в Uniswap v3 влаштована так: ви самі задаєте ціновий діапазон, у межах якого працюють ваші кошти. Поки ціна всередині — капітал задіяний щільніше, ніж у класичному пулі, і комісія на одиницю вкладеного зростає.
Щойно ціна виходить за межу, LP-позиція перестає заробляти: актив повністю конвертується в один токен, а ви тримаєте його осторонь від ринку.
Саме тут криється основна причина збитків. Діапазон — не статичне налаштування, а параметр, який треба переглядати в міру руху ринку. Чим вужчий коридор, тим вища віддача на капітал, але тим частіше ціна його покидає.
Без автоматизації власник або тримає широкий діапазон і втрачає в дохідності, або виставляє вузький і через кілька годин виявляє позицію за межею.
Ручне ребалансування не масштабується: потрібно безперервно стежити за ціною, вчасно закривати й перевідкривати позицію, заново підбирати межі й не помилятися в розрахунку обсягів.
На волатильному ринку такі переходи трапляються по кілька разів на добу, і кожен пропущений момент — це недоотримана комісія плюс накопичений несприятливий відбір.
Окрема проблема — неправильний вибір моменту. Якщо ребалансувати на кожному коливанні, транзакційні витрати й прослизання з'їдають весь прибуток від комісій. Якщо ребалансувати рідко — позиція довго простоює поза діапазоном.
Баланс між цими крайнощами досягається лише алгоритмічно, з урахуванням волатильності, глибини пулу й вартості газу.
Автоматичний менеджер вирішує це як замкнений контур: відстежує ціну щодо меж, за заданими правилами ініціює вихід із діапазону й перевідкриття позиції, перераховує межі під поточну волатильність і контролює витрати кожної операції. Нижче розбираємо, як це закривається на практиці.
Архітектура автоматичного менеджера LP-позицій
Автоматичний менеджер утримує LP-позицію в цільовому діапазоні Uniswap v3 без участі оператора: контракт відстежує поточну ціну пулу, порівнює її з межами та ініціює ребалансування, коли позиція наближається до краю.
Ручне управління тут програє не в точності, а в швидкості реакції — поки оператор перевіряє графік, діапазон уже пройдено, ліквідність перестає заробляти, а активи залишаються в невигідній пропорції.
Ребалансування за тригером
Смарт-контракт зберігає цільову зону та поріг спрацювання. При виході ціни за межу він знімає ліквідність, змінює співвідношення активів і відкриває нову позицію з перерахованим діапазоном.
Ключовий параметр — ширина коридору: вузький дає більше зборів, але частіше потребує перебудови, широкий рідше зрушується, але приносить менше на одиницю вкладеного капіталу.
Режими роботи менеджера
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ручний із повідомленнями | Рідкісні ребалансування, контроль кожної операції | Реакція залежить від оператора, вікно пропускається |
| Напівавтоматичний | Потрібне підтвердження перед великою перебудовою | Затримка між сигналом і виконанням |
| Повністю автоматичний | Волатильні пари, цілодобова робота | Потребує коректних лімітів і захисту від прослизання |
Захист від людського фактора
Автоматизація прибирає клас відмов, пов'язаних із ручними операціями: пропущений сигнал, неправильно виставлені межі, вхід у момент різкого руху ціни.
Контракт виконує заздалегідь задану логіку однаково в будь-яку годину, а всі дії фіксуються в журналі — видно, коли і чому спрацювало ребалансування.
Uniswap v3 дає концентровану ліквідність, але саме через неї позиція потребує постійної уваги. Менеджер перетворює це з рутини на керований процес із передбачуваними правилами.
Як ми впроваджуємо менеджер позицій: етапи робіт
Впровадження автоматичного менеджера LP-позицій для Uniswap v3 починається з аудиту: дивимося, у яких діапазонах зараз стоять кошти, як часто ви виходите за межі, скільки часу позиція проводить поза діапазоном і які комісії втрачаються марно. Без цього етапу будь-яка автоматизація закріплює вже наявні помилки в логіці ребалансувань.
Далі проєктуємо логіку під ваш профіль ризику та горизонт: правила входу й виходу з діапазону, пороги спрацювання, ліміти на розмір кроку та частоту перебудов.
Окремо фіксуємо, що робить менеджер при різкому русі ціни та при нестачі газу — це ті сценарії, де саморобні боти найчастіше втрачають кошти.
- Аудит поточних позицій. Збираємо історію за парами та діапазонами, рахуємо частку часу поза діапазоном і втрачені комісії — отримуємо базу для порівняння після впровадження.
- Проєктування логіки. Описуємо правила ребалансування, умови зупинки та захисні ліміти, узгоджуємо їх з вами до написання коду.
- Налаштування параметрів. Задаємо ширину діапазону, крок перебудови, пороги комісій і обмеження за частотою операцій під конкретну пару.
- Розробка та внутрішні перевірки. Пишемо модуль керування позицією, покриваємо ключові шляхи тестами, включно з аварійною зупинкою та відкатом.
- Перевірка на тестовій мережі. Проганяємо сценарії на історичних даних і в тестовій мережі: дивимося, як логіка поводиться на різких рухах і в спокійному ринку.
- Передача та документація. Віддаємо конфігурації, схему логіки, інструкцію зі зміни параметрів і порядок дій при збої.
- Супровід після запуску. Перший час стежимо за фактичними метриками та коригуємо пороги, якщо поведінка ринку відрізняється від розрахункової.
Кожен етап закінчується артефактом, який можна перевірити: звіт з аудиту, специфікація правил, набір параметрів, результати прогонів. Опишіть вашу задачу — повернемося з оцінкою та планом робіт за етапами.
Чим автоматичний менеджер відрізняється від ручного управління?
Ручне управління LP-позицією в Uniswap v3 зводиться до трьох дій: вибрати діапазон ціни, стежити за його актуальністю та вчасно перекласти ліквідність при виході ціни за межі. Поки ринок спокійний, це працює.
Але діапазон в Uniswap v3 — не «налаштував і забув»: чим він вужчий, тим вища частка комісій, і тим швидше ціна його покидає.
У момент виходу позиція перестає заробляти і повністю переходить в один актив — по суті, ви тримаєте його без комісії та з ризиком подальшого руху проти вас.
Автоматизація змінює саму природу процесу. Менеджер відстежує ціну та стан позиції безперервно, а не в ті моменти, коли в оператора є час відкрити інтерфейс.
Реакція вимірюється не хвилинами та годинами, а блоками: щойно ціна наближається до межі або пробиває її, позиція перезбирається за заздалегідь заданою логікою. Ручне управління так не вміє — людина спить, працює над іншим завданням, просто не встигає. Саме на цих вікнах простою і втрачається основна частина комісій.
Точність попадання в діапазон — друга прогалина. Оператор виставляє межі «на око» і рідко перераховує їх під змінену волатильність. Алгоритм рахує діапазон від поточної ціни та заданої ширини, тому позиція залишається в робочій зоні, а не висить мертвим вантажем за її межами.
Витрати на газ при ручному підході непередбачувані: перезбирання потрапляє на пік завантаження мережі, і комісія з'їдає зароблене. Менеджер може відкладати дію до прийнятного рівня газу або об'єднувати операції — там, де людина реагує негайно і дорого.
І головне — людський фактор. Пропущений вихід з діапазону, невірно введена межа, забута позиція. Алгоритм не втомлюється і не відволікається, а всі його дії відтворювані та логуються.
Кейс: як менеджер утримав позицію в діапазоні
До впровадження позиція в пулі з вузьким діапазоном жила в середньому 6-9 годин: ціна виходила за межу, ліквідність переставала заробляти, а повернення в діапазон вимагало ручного втручання.
Оператор перевіряв стан кілька разів на день, але між перевірками минали години — за цей час позиція встигала випасти й накопичити невиконані ордери. Частка часу в діапазоні трималася на рівні 55-60%, а кожна перестановка меж робилася вручну й із затримкою.
Що змінили
Ми зібрали автоматичний менеджер, який стежить за ціною та переставляє межі позиції за заданою стратегією. Логіку винесено в окремий сервіс: він читає стан пулу, порівнює поточну ціну з активним діапазоном і ухвалює рішення про перестановку.
Усі дії проходять через симуляцію на форку перед відправленням — транзакція спочатку перевіряється на реальному стані мережі, і тільки потім іде в мейннет.
Метрики до та після
| Показник | До | Після |
|---|---|---|
| Частка часу в діапазоні | 55-60% | 92-95% |
| Ручних операцій на тиждень | 20-30 | 1-2 |
| Середня затримка реакції | години | хвилини |
| Клас усунених відмов | вихід за межі, пропущені перестановки | — |
Окремо закрили клас відмов, пов'язаних із гонкою транзакцій: коли оператор і скрипт одночасно намагалися змінити позицію, частина операцій відвалювалася за nonce. Тепер черга дій серіалізована, а повторне відправлення йде з перерахунком газу.
Що залишилося під контролем людини
Автоматика не скасовує нагляд: оператор задає стратегію, ліміти за розміром позиції та пороги, за якими менеджер зупиняється й чекає рішення. Усі дії логуються, є відкат до попереднього стану позиції. Такий підхід знімає рутину, але залишає за людиною управління ризиком.
Uniswap v3
Сумніви перед впровадженням: доступи, міграція, відкат
Перед запуском автоматичного менеджера LP-позицій Uniswap v3 замовник зазвичай ставить три питання: які ключі ми отримуємо, що буде з уже відкритими позиціями і як відкотитися, якщо стратегія піде не так. Відповідаємо по суті — без загальних слів.
Що з доступами? Менеджер підписує транзакції гаманця, тому йому потрібен доступ до акаунта, який керує позиціями. Ми проєктуємо ролі так, щоб у бота був окремий ключ із правом лише на перебалансування та збір комісій, а виведення коштів залишалося за вами. Ключі зберігаються в захищеному сховищі, а не в коді чи конфігураційних файлах.
Що якщо міграція? Уже відкриті позиції не чіпаємо до першого планового циклу: менеджер зчитує поточні діапазони та підхоплює їх як є. Перехід на нову логіку відбувається поступово — спочатку на одній парі, потім на решті, з контролем результату на кожному кроці.
Як влаштований відкат? Кожен цикл перебалансування пише знімок стану: діапазон, ліквідність, комісії. Відкат — це повернення до попереднього знімка та повторне відкриття позиції за ним, а не «ручне відновлення на око». Плюс завжди залишається аварійний режим: зупинка бота та передача керування вам.
Що якщо стратегія почне втрачати гроші на волатильній парі?
У кожного менеджера є ліміти: максимальна просадка, мінімальний діапазон, поріг комісій для перебалансування. При виході за ліміт бот зупиняється та надсилає повідомлення, а не продовжує торгувати. Ліміти налаштовуються під вашу пару та горизонт.
Що якщо у вас уже є свій бот або скрипти? Ми не ламаємо наявну логіку: менеджер підключається як окремий шар поверх поточних позицій, а старі скрипти можна залишити в резерві.
Що ви отримаєте на руки:
- Конфігурації менеджера: діапазони, ліміти просадки, пороги перебалансування.
- Схему ролей і доступів з розділенням прав на керування та виведення.
- Політику зберігання ключів і правила ротації.
- Документацію щодо циклів роботи та логіки ухвалення рішень.
- Інструкцію щодо відкату та аварійної зупинки.
- Схему міграції наявних позицій за кроками.
- Набір метрик і дашборд щодо комісій та просадки.
Опишіть вашу задачу — пару, горизонт і поточний стан позицій. Повернемося з оцінкою та планом впровадження.
Терміни впровадження менеджера LP-позицій
Терміни залежать не від обсягу коду, а від того, наскільки швидко узгоджуються правила управління позицією: межі діапазону, пороги ребалансування, ліміти на газ і допустиме прослизання. Нижче — орієнтовні етапи для менеджера LP-позицій Uniswap v3.
Діапазони наведено для типового проєкту з однією стратегією; паралельні стратегії та нестандартна логіка додають часу пропорційно.
Що впливає на термін. Кількість пулів і стратегій, необхідність зовнішнього аудиту коду, вимоги до мультипідпису для виведення коштів і наявність готової інфраструктури моніторингу. Якщо у вас уже розгорнуто вузол мережі та налаштовано оповіщення, етап налаштування скорочується.
Як прискорити. Зафіксувати правила управління позицією до старту розробки — це знімає переробки на етапі тестування. Детальні вимоги до поведінки при волатильності економлять більше часу, ніж будь-який інструмент.
Опишіть задачу: які пули, яка логіка ребалансування, хто управляє коштами — повернемося з оцінкою та планом за етапами.
