Чому AI-оптимізація DeFi-портфеля ламається в мобільному застосунку
AI-оптимізація DeFi-портфеля в мобільному застосунку ламається не на моделі, а на стику між сигналом і виконанням угоди.
Модель будує рекомендацію за останнім знімком пулів ліквідності, але між розрахунком і підписом транзакції минає час: затримка котирувань у кілька секунд на волатильній парі вже зсуває ціну входу, і рекомендація приходить до користувача застарілою. На десктопі з постійним каналом це непомітно, у мобільній мережі — регулярний сценарій.
Далі в ланцюжок втручається мережа. Поки застосунок показує «оптимальний» маршрут, комісія мережі встигає зрости, а сам маршрут — перебудуватися під чужу угоду.
Підсумок: прослизання ціни з'їдає розрахункову дохідність, а за перевантаження мережі транзакція або зависає в очікуванні, або відкочується — і портфель залишається в тому стані, який модель уже вважає неоптимальним.
Окрема проблема — застарілі дані на пристрої. Кеш котирувань, відкладена синхронізація балансів і розрив між станом блокчейну та тим, що бачить інтерфейс, призводять до рішень за неіснуючими цінами. Користувач бачить одну дохідність, а виконання дає іншу.
Ми розбираємо, як це закривається: де потрібен свіжий знімок стану, де — запас за комісією та допуском прослизання, а де — повторна перевірка перед підписом. Нижче — за кожним вузьким місцем.
Що дає оптимізація портфеля: вимірюваний ефект
AI-оптимізація DeFi-портфеля в мобільному застосунку — це не «розумна кнопка», а контур, який безперервно перераховує маршрут угоди та цільову структуру портфеля.
Модуль тримає актуальні резерви пулів і глибину ліквідності, тому маршрут будується не за одним протоколом, а за сукупністю майданчиків з урахуванням комісій і ціни газу.
На щільному ринку це помітно знижує прослизання: велика заявка розбивається на частини й проходить там, де ціна менше зміщується від обсягу.
Швидкість відгуку тут — не косметика. Розрахунок маршруту й підпис транзакції виконуються на боці застосунку, а не у веб-обгортці, тому користувач бачить актуальну котировку без затримки на завантаження сторінки.
Чим коротший шлях від натискання до підтвердження, тим менша ймовірність, що ціна піде між розрахунком і відправленням — а саме на цьому стику найчастіше й народжуються невдалі угоди.
Ребалансування портфеля працює за цільовими вагами: при відхиленні від заданих часток система пропонує набір угод, що мінімізує сумарні витрати, а не просто «продати одне, купити інше».
Частину операцій можна об'єднувати в один маршрут, частину — відкладати до моменту, коли витрати опускаються нижче порогу.
Частка невдалих угод падає не за рахунок відмови від ризику, а за рахунок того, що застосунок заздалегідь перевіряє достатність ліквідності й не надсилає наперед програшні заявки.
Кожен із цих ефектів вимірюваний: прослизання у відсотках від обсягу, час від розрахунку до підтвердження, частка відхилених і скасованих транзакцій. Нижче розбираємо, як це влаштовано і що саме закриває кожне вузьке місце.
Порівняння підходів до оптимізації портфеля
Оптимізація DeFi-портфеля в мобільному застосунку вирішується чотирма різними способами, і вибір між ними — це компроміс між швидкістю реакції, вартістю обчислень і автономністю пристрою. Нижче — порівняння за тим, коли підхід підходить і де впирається в обмеження.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Ручне ребалансування | Портфель із 3-5 активів, рідкісні зміни стратегії, користувач хоче повний контроль | Реакція залежить від людини: пропущене вікно дохідності, помилки в розрахунку часток, затримка між сигналом і угодою |
| Правила-тригери | Прості пороги: частка активу вийшла за коридор, дохідність упала нижче рівня | Не враховує кореляції між активами та комісії мережі; на різкому ринку спрацьовує каскадом і ріже дохідність |
| Модель на пристрої | Приватність важливіша за точність, немає стабільної мережі, потрібен відгук без затримки | Обмежена пам'ять і обчислювальний бюджет телефона — модель спрощена, рідше перенавчається |
| Хмарна модель із кешем | Складні стратегії, багато активів, потрібна свіжа ринкова картина | Залежить від каналу зв'язку; при обриві працює на останньому кеші, розрахунок може відставати від ринку |
Як вибирати під задачу
Ручне ребалансування та правила-тригери дають передбачуваність і не потребують інфраструктури, але програють у швидкості на волатильному ринку. Локальна модель виграє у приватності та відгуку, хмарна — у якості прогнозу завдяки свіжим даним.
На практиці робоча схема — гібрид: хмара рахує рекомендації та кешує їх на пристрої, локальна модель страхує при втраті зв'язку, а правила-тригери закривають прості сценарії без звернення до моделі. Так застосунок залишається керованим, а користувач бачить, чому портфель перебудувався.
Як ми впроваджуємо оптимізацію: етапи роботи
Роботу починаємо з аудиту поточної логіки: дивимося, як застосунок зараз збирає дані про позиції, де рахуються дохідність і ризики, які ліміти зашиті в код.
На виході — карта вузьких місць: де розрахунок запізнюється, де правила конфліктують між собою, а де рішення взагалі ухвалюється вручну.
Далі проєктуємо схему потоків даних — від джерел котирувань і стану пулів до моменту, коли рекомендація потрапляє на екран. Фіксуємо, які дані потрібні в реальному часі, що можна кешувати, а що перераховувати за розкладом.
Це знімає головну причину розсинхрону: коли інтерфейс показує одне, а логіка виконання спирається на застарілий зріз.
- Аудит логіки — розбираємо наявні правила розподілу та межі ризику, відзначаємо, що перевикористовуємо, а що переписуємо.
- Схема потоків даних — описуємо джерела, частоту оновлення та точки відмови, узгоджуємо з вашою командою.
- Налаштування моделі та лімітів — задаємо цільову функцію, пороги ребалансування та жорсткі обмеження, які модель не має права порушувати.
- Перевірка на історичних даних — проганяємо логіку на минулих періодах, включно з різкими рухами ринку, і звіряємо поведінку з очікуваною.
- Навантажувальна перевірка — моделюємо пікові сценарії, дивимося час відгуку та поведінку за недоступності зовнішнього джерела.
- Передача та навчання команди — віддаємо конфігурації, розбір рішень та інструкції, щоб ваші інженери могли змінювати параметри без нас.
Кожен етап закінчується артефактом, який можна перевірити: карта вузьких місць, схема потоків, набір лімітів, звіт за історичними прогонами, результати навантажувальних сценаріїв.
Так ви бачите, на чому ґрунтуються рішення, і можете зупинитися на будь-якому кроці, не оплачуючи наосліп наступний.
Що отримує замовник після впровадження
Впровадження AI-оптимізації DeFi-портфеля завершується не демонстрацією працюючого прототипу, а передачею комплекту, за яким ваша команда та підрядник на підтримці зможуть експлуатувати систему без нас. Нижче — що саме залишається у замовника.
- Конфігурація моделі — файли параметрів рекомендацій (горизонт прогнозу, пороги спрацювання, ваги факторів ризику) з описом, як змінювати їх без перезбирання застосунку.
- Схеми інтеграцій — карта зв'язків з блокчейн-вузлами, агрегаторами дохідності та гаманцем: точки відмови, резервні маршрути, поведінка при недоступності зовнішнього сервісу.
- Політики лімітів і ризику — правила, що обмежують розмір позиції, допустиму просадку та набір протоколів, з явним описом, що відбувається при пробої кожного ліміту.
- Регламент оновлення — як викочується нова версія моделі, хто затверджує зміни, як відкотитися на попередню конфігурацію за один крок.
- Документація підтримки — інструкції для чергової зміни: типові інциденти, діагностика розбіжностей між рекомендацією та фактичним виконанням, ескалація.
- Метрики та дашборд — набір показників якості рекомендацій та їхніх відхилень, за якими видно деградацію моделі до того, як її помітить користувач.
- Доступи та ролі — розмежування прав на зміну лімітів, конфігурації моделі та торгових параметрів, з журналом дій.
Такий комплект знімає залежність від одного інженера: підтримку можна передати всередині команди або іншому підряднику без зворотного проєктування. Опишіть вашу задачу — повернемося з оцінкою та планом передачі.
Кейс: як знизили просковзування та відмови угод
Клієнт — команда, яка керує некастодіальним DeFi-портфелем через мобільний застосунок. Користувач отримував сигнал про зміну дохідності пулу, відкривав застосунок і вручну збирав транзакцію: approve, swap, додавання ліквідності.
Поки він проходив три екрани, ціна йшла — угода виконувалася за гіршим курсом або відвалювалася через вичерпаний час очікування. Частка невдалих угод сягала чверті, а просковзування на волатильних парах з'їдало помітну частину дохідності.
Що змінили в архітектурі
Ми перенесли розрахунок маршруту обміну на бік сервісу: застосунок отримує вже готову послідовність викликів із розрахованими мінімумами на виході та запасом за часом. Локально залишилися тільки підпис і надсилання — ключі не залишають пристрій.
Сигнал про зміну дохідності надходить пуш-повідомленням, а не опитуванням екрана, тому реакція не залежить від того, чи відкрито застосунок.
Окремо переробили повторні спроби: замість сліпого ретраю транзакція перезбирається з актуальними котируваннями, а якщо ціна вийшла за допустимий поріг — скасовується до надсилання, без списання комісії мережі.
Метрики до та після
| Показник | До | Після |
|---|---|---|
| Частка невдалих угод | ~24% | 4-6% |
| Середнє просковзування | 1,8-2,2% | 0,4-0,6% |
| Час відгуку на сигнал | 40-90 сек | 3-5 сек |
Цифри підтверджуються вивантаженням із Dune Analytics за адресами контрактів клієнта — динаміка тримається на дистанції кількох місяців, а не на одному вдалому релізі.
Чим відрізняється оптимізація на пристрої від хмарної?
Оптимізація портфеля може обчислюватися у двох місцях: на самому телефоні або на віддалених серверах. Різниця не в тому, де «потужніше», а в тому, який клас задач ви розв'язуєте.
Модель на пристрої тримає всю логіку перерахунку ваг і перевірки умов угоди локально: застосунок отримує ринкові дані, обчислює новий розподіл і формує транзакцію, не надсилаючи на сторону ні склад портфеля, ні пороги ризику.
Затримка сигналу тут — це час між надходженням ціни та готовою транзакцією, і вона вимірюється десятками мілісекунд, тому що немає мережевого кола до сервера. Приватність даних стає властивістю архітектури: чутливі параметри фізично не залишають телефон.
Хмарна модель обчислює те саме на сервері. Вона виграє там, де потрібна важка аналітика: навчання на довгій історії, одночасний перерахунок за десятками ринків, складні сценарії дохідності.
Але кожне рішення потребує мережевого обміну, і в момент перевантаження мережі або недоступності сервісу застосунок залишається без логіки — користувач бачить застарілі ваги й не може виконати ребалансування.
Вартість трафіку теж переходить в операційні витрати: чим частіше перерахунок, тим більше запитів і тим помітніше навантаження на канал і на серверну частину.
На практиці вибір рідко буває бінарним. Розумна схема — гібрид: на пристрої живе швидкий контур, який ухвалює рішення за захисними правилами та ребалансуванням у реальному часі, а хмара підключається для періодичного перенавчання моделі, бектестів і агрегованої аналітики. Тоді стійкість до навантаження забезпечує локальний контур, а якість прогнозу — серверний.
Критерій простий: якщо рішення має ухвалюватися за секунди й спиратися на приватні дані — обчислюйте на пристрої. Якщо потрібна важка аналітика й допустима затримка — виносьте в хмару.
Ми проєктуємо обидва контури й стикуємо їх так, щоб застосунок продовжував працювати за будь-якого стану мережі.
Технічні сумніви та відповіді щодо оптимізації
Модель перенавчається на історичних дохідностях пулів і волатильності пар, оновлення відбувається за розкладом і за подією — різкий рух ставок або ліквідності запускає перерахунок поза чергою.
Версія моделі фіксується, тому кожне рішення можна відтворити й пояснити: чому сигнал з'явився саме в цей момент.
Збій мережі або недоступність вузла не залишає портфель у підвішеному стані. Застосунок працює з кількома джерелами котирувань, розбіжність між ними вище порогу позначає дані як недостовірні та блокує виконання до підтвердження. Якщо зв'язок зник, активні операції ставляться на паузу, а не виконуються за застарілою ціною.
Перевірка сигналів відбувається до угоди, а не після. Сигнал проходить фільтр на аномалії, звіряється з лімітами ризику за часткою в одному пулі, загальним навантаженням і допустимим падінням, і лише потім перетворюється на дію. Ліміти задає власник портфеля, і вони мають приоритет над будь-якою рекомендацією моделі.
Що відбувається, якщо модель помилилася?
Помилковий сигнал не виконується наосліп: спрацьовують ліміти ризику та захист від аномалій. Портфель залишається в заданих межах, а інцидент потрапляє до журналу з повним контекстом — за ним видно, який сигнал і який поріг спрацював.
Чи можна відкотити невдалу зміну?
Так. Версії моделі та конфігурації лімітів зберігаються окремо, тому повернення до попереднього набору правил — це перемикання версії, а не ручна правка. Історія рішень зберігається, щоб порівняти результат до і після.
Як перевіряється коректність сигналів на реальних даних?
Перед випуском модель проганяється на історичних періодах, включно з різкими обвалами ліквідності, і звіряється з фактичною поведінкою портфеля. Розбіжність вище допустимої повертає модель на доопрацювання.
Хто має доступ до управління портфелем?
Доступ розмежовано за ролями: перегляд, зміна лімітів і підтвердження операцій — різні права. Ключі зберігаються на пристрої, а не на сервері, і не залишають його під час звичайної роботи застосунку.
Обговоримо ваше завдання з оптимізації портфеля
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібно зрозуміти ваше завдання у ваших термінах: які мережі та протоколи вже в портфелі, як зараз рахуються дохідність і ризики, де саме ручні рішення з'їдають час.
Чим конкретніші вхідні дані, тим точніша оцінка термінів впровадження і менше ітерацій на переробку.
На першій розмові уточнюємо вимоги та межі: які активи та стратегії підтримуємо, чи потрібен ребаланс за розкладом або за подіями ринку, як застосунок отримує дані про позиції та куди віддає команди.
Окремо проговорюємо, що робимо при недоступності джерела даних і як користувач підтверджує дії з капіталом.
Далі наші інженери готують оцінку та план: розбивку за етапами, склад робіт і точки, де ви приймаєте результат. Нижче — що варто підготувати до обговорення завдання.
- Список мереж і протоколів, де зараз розміщено портфель, і як ви бачите пріоритети між ними.
- Логіку поточного управління: правила входу та виходу, пороги дохідності, ліміти на позицію.
- Джерела ринкових даних і вимоги до їхньої точності та частоти оновлення.
- Сценарії ребалансу: за часом, за відхиленням від цільових часток, за ринковою подією.
- Вимоги до підтвердження операцій користувачем і до журналу дій.
- Обмеження щодо доступів, зберігання ключів і розмежування ролей у команді.
- Очікувані терміни впровадження і те, який результат вважаєте успішним на першому етапі.
Опишіть завдання у вільній формі — повернемося з оцінкою, планом і наступними кроками. Якщо частину даних поки не зібрано, зафіксуємо це як окремий пункт плану, щоб не гальмувати старт.
