Чому інтеграція Paraswap ламається на піковому навантаженні
Агрегатор не зводить до одного джерела ліквідності: він опитує десятки пулів, збирає багатокроковий маршрут і віддає готову транзакцію на підпис. Поки котирування рахується й доходить до гаманця, стан пулів змінюється — і саме на піковому навантаженні цей розрив стає критичним.
Перший тип збою — розсинхронізація котирувань: ціна надійшла зі стану, який уже застарів, і обмін іде за умовами, яких на ринку більше немає.
Другий — відмова маршруту: якщо з ланцюжка вимивається хоча б один пул, уся транзакція відкочується, хоча решта кроків залишалися валідними.
Окремо стоять завислі транзакції — при сплеску газу підписана операція висить у черзі, її дедлайн спливає, а кошти блокуються до ручного скасування.
Частка неуспішних обмінів у години активності зростає кратно: користувач платить лише комісію мережі, сам обмін не проходить, але інтерфейс до останнього показує успішний результат.
Так виглядає типовий збій обмінів, через який інтеграція Paraswap у проді перестає тримати обіцяну надійність.
Розбираємо, як це закривається: де ставити перевірку актуальності маршруту, які пороги прослизання й дедлайну працюють у пік, і як віддавати зрозумілий статус замість завислої транзакції.
Що дає налагоджена маршрутизація обмінів
Маршрутизація обмінів — це розрахунок того, як провести угоду, а не вибір одного майданчика: агрегатор порівнює глибину пулів на множині децентралізованих обмінників, дробить суму на частини й збирає шлях так, щоб ціновий вплив і комісії пулів були мінімальні.
Paraswap тримає цю логіку на своєму боці, тому продукту не потрібно знати, де саме виконається обмін.
Звідси — вимірювані ефекти. Частка успішних обмінів зростає, бо маршрут перераховується прямо перед відправленням транзакції, а не береться зі збереженого розрахунку: котирування, застаріле в момент волатильності, більше не призводить до відмови через перевищення прослизання.
Час відгуку на підготовку маршруту залишається в десятих частках секунди й при сплеску запитів — розрахунок іде паралельно за майданчиками.
Стійкість до навантаження тримається на резервуванні шляхів. Якщо окремий майданчик недоступний або відповідає повільно, маршрут будується за рештою, а операція йде на повтор з оновленим котируванням замість відмови.
Частка обмінів, що потребують ручного втручання, знижується до поодиноких випадків: оператору не доводиться вручну підбирати пул або піднімати поріг прослизання.
Що це змінює в експлуатації: клас відмов «угода не пройшла через ціну» перестає бути помітним у зверненнях, а поведінка сервісу на піку навантаження стає передбачуваною.
Роботу маршрутизації видно в метриках — частка успішних обмінів, середній і хвостовий час відгуку, розподіл прослизання за угодами.
Варіанти підключення до джерел ліквідності
Джерела ліквідності відрізняються не лише глибиною, а й тим, як швидко з них змінюється ціна, яку ви показали користувачу.
Коли маршрут рахує один пул, велика угода поруч зсуває котирування, і своп виконується гірше очікуваного; коли маршрутів десятки — питання в тому, хто їх перебирає і з якою затримкою.
Ми закладаємо в архітектуру щонайменше два незалежні канали: основний через агрегатор обмінів і резервне пряме підключення до перевірених пулів. Це задає поведінку системи, коли зовнішній сервіс недоступний або віддає маршрут із прослизанням вище ліміту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до одного майданчика | Вузький набір активів, передбачувані обсяги, потрібен повний контроль над викликом контракту | Немає вибору ціни: при просіданні ліквідності в цьому пулі угода або не проходить, або йде за поганим курсом |
| Власний маршрутизатор | Свій набір пулів, нестандартна логіка обміну, готовність підтримувати індексацію й перерахунок маршрутів | Дорого в розробці й супроводі; конкурувати за ціною з готовими агрегаторами складно |
| Зовнішній агрегатор обмінів, наприклад Paraswap | Потрібна найкраща доступна ціна за широким набором майданчиків без власної інфраструктури | Залежність від зовнішнього сервісу: затримки, ліміти запитів, зміна правил і списку мереж |
| Гібридна схема з резервним маршрутом | Бойовий контур із вимогою до доступності й контролю прослизання | Складніше тестування: покрити потрібно обидва шляхи й правила перемикання між ними |
Гібридна схема дає передбачуваність: поки агрегатор відповідає в межах ліміту за ціною й часом, обмін іде через нього; при відхиленні спрацьовує резервний маршрут, і користувач не залишається з невиконаною заявкою.
Цей варіант ми найчастіше виносимо в основу, а решту — як ступені, поки навантаження або вимоги до контролю ще не зросли.
Як проходить інтеграція Paraswap: етапи робіт
Інтеграція агрегатора — не підключення одного виклику, а вбудовування в наявну схему обмінів: маршрут збирається з кількох джерел ліквідності, і підсумковий вихід залежить від параметрів запиту, лімітів прослизання й обробки відмов.
Наводимо послідовність етапів інтеграції Paraswap, за якою йдемо на проєктах — від аудиту поточних обмінів до передачі системи з регламентами супроводу.
- Аудит схеми обмінів. Збираємо поточні пари, обсяги й частки невдалих транзакцій. На виході — карта, де агрегатор дає виграш за виходом, а де вигідніший прямий обмін.
- Налаштування маршрутів. Задаємо пріоритети джерел ліквідності, обмеження прослизання, мінімальну суму виходу й поведінку за нестачі ліквідності. Резервне джерело фіксуємо заздалегідь.
- Підключення й конфігурація. Інтегруємо виклики, ключі й ліміти, описуємо обробку помилок і повторних спроб, щоб одиничний збій не зупиняв обмін.
- Перевірка коректності. Проганяємо сценарії на історичних даних і в тестовому середовищі: звіряємо розрахунковий вихід із фактичним, перевіряємо граничні суми й відмову одного з джерел.
- Спостережуваність і виведення трафіку. Налаштовуємо метрики частки успішних обмінів і відхилення фактичного виходу від розрахункового. Потік вмикаємо поступово — спочатку малою часткою.
- Передача системи. Віддаємо схеми маршрутів, конфігурації, регламенти супроводу й порядок дій при збоях, навчаємо вашу команду.
Артефакти постачання: схеми, політики, регламенти
Інтеграція завершується не працюючим кодом, а комплектом артефактів, за яким систему можна розвивати й супроводжувати власними силами. Нижче — що саме залишається в замовника після передачі.
- Конфігурації маршрутів — підтримувані мережі та пари токенів, пороги прослизання, пріоритет джерел ліквідності й правила обходу, коли найкращий маршрут недоступний.
- Політики доступу — розділення ключів підпису й читання, ролі операторів, порядок ротації та виведення облікових даних з експлуатації.
- Схеми потоків — шлях від запиту котирування до підтвердження угоди: де перевіряються ліміти, де фіксується результат, що відбувається при таймауті.
- Ліміти й запобіжники — разові та добові пороги обсягу, обмеження за парами, автоматична зупинка при аномальному просіданні ціни.
- Регламент супроводу — строки реакції на деградацію котирувань, порядок підключення нових джерел, планові перевірки відмовних сценаріїв.
- Документація з інтеграції — методи, формати запитів і відповідей, коди помилок, типові сценарії відновлення й відкату.
Комплект передаємо разом із власником на боці замовника: інженери проходять за схемами й регламентами з командою, щоб документи не залишилися невикористаними. Подальші зміни маршрутів або лімітів вносяться за описаними процедурами, без перезбирання інтеграції.
Кейс: обмін перестав зриватися на піках навантаження
Ситуація до
Обмін між токенами йшов через один маршрут: коли ліквідність на майданчику просідала або угода відкочувалася через прослизання, користувач отримував помилку й ішов пробувати знову.
На піках навантаження частка зірваних обмінів сягала кожного шостого звернення, а черговий інженер вручну піднімав допустиме відхилення ціни й перемикав джерело — на розбір ішло до пів години, і весь цей час обміни не проходили.
Що змінили
Підключили агрегатор Paraswap як шар маршрутизації: він порівнює доступні джерела ліквідності й розбиває велику угоду на частини, щоб не провалювати ціну на одному пулі.
Навколо нього поставили контроль допустимого відхилення ціни, попередню перевірку котирування до підпису транзакції й автоматичний повтор із перезбиранням маршруту, якщо джерело повернуло помилку.
Окремо налаштували перехід на резервне джерело при недоступності основного майданчика — уже без участі чергового.
Що стало
Частка неуспішних обмінів упала до одиниць відсотків: результат приходить з першого-другого звернення, а не з четвертої спроби. Час відновлення після збою майданчика скоротився з десятків хвилин ручної роботи до секунд — маршрут перебудовується сам.
Ручних розборів стало приблизно в десять разів менше: черговий більше не сидить на потоці зірваних обмінів, а займається задачами розвитку. Стабільність обмінів на піках перестала залежати від того, хто сьогодні на зміні.
Чим відрізняється агрегатор від прямого підключення до біржі?
Пряме підключення до однієї біржі — це один пул ліквідності й один маршрут: ціна визначається глибиною цього пулу, і на великому обсязі прослизання зростає. Агрегатор збирає маршрут із кількох майданчиків, дробить ордер між пулами й переставляє кроки під поточний стан книги. Різниця не в «середній ціні», а в тому, хто ухвалює рішення про маршрут.
Під час інтеграції Paraswap контроль маршруту залишається в агрегатора: ви задаєте рамки — допустиме прослизання, мінімальну ціну виконання, список мереж і токенів, — а розбивку угоди рахує його розрахунковий шар.
Передбачуваність ціни вища: кілька маршрутів конкурують, і угода виконується за найкращим із знайдених, а не за єдиним доступним.
| Критерій | Пряме підключення до DEX | Агрегатор |
|---|---|---|
| Контроль маршруту | Повний, але маршрут один | Рамки ваші, розбивку рахує агрегатор |
| Передбачуваність ціни | Залежить від глибини одного пулу | Конкуренція маршрутів, дроблення ордера |
| Залежність від майданчика | Зупинка пулу ламає обмін | Відмова одного майданчика лише звужує маршрути |
| Супровід | Свій код під кожну мережу | Стежите лише за рамками |
Пряма схема сильніше залежить від майданчика: пауза на контрактах або виведення ліквідності — і функція обміну перестає працювати цілком.
Звідси вибір схеми обміну: агрегатор закриває користувацькі обміни й довгий хвіст токенів, прямий коннект — свої стратегії, де потрібен точний контроль над виконанням. На практиці їх поєднують: агрегатор як основний шлях, пряме підключення — як резерв.
Технічні питання й обмеження маршрутизації
Маршрутизація в Paraswap — єдина ділянка інтеграції, яка залежить від зовнішніх майданчиків.
Якщо пул перезбирає ліквідність або джерело зупиняє торги, розбиття угоди на частини змінюється в момент підписання, і без явної обробки відмови користувач отримує завислу операцію замість зрозумілої помилки. Нижче — те, що найчастіше перевіряє технічна команда перед впровадженням.
Що відбувається, якщо майданчик недоступний?
Агрегатор виключає його з маршруту й перезбирає шлях за рештою джерел ліквідності. Якщо доступних пулів не залишилося або найкращий маршрут дає ціну гіршу за поріг, заданий при відправленні, обмін не виконується — транзакція не йде в мережу.
Чи можна замінити агрегатор без переписування сервісу?
Так. Шар маршрутизації виноситься за єдиний інтерфейс: отримання котирування, формат відповіді й обробка відмови описані в одному модулі інтеграції. Перехід на іншого провайдера — правка цього модуля й логіки вибору маршруту, решта коду й облік операцій не зачіпаються.
Які ліміти за обсягом і де межа просідання?
Обмеження задає не агрегатор, а глибина пулів: велика угода проходить за кількома рівнями ціни, і підсумковий курс відрізняється від показаного котирування.
Ми рахуємо просідання до підписання, задаємо верхню межу обсягу на одну угоду й допустиме відхилення ціни; при виході за них операція відхиляється або ділиться на кілька частин за часом.
Обговоримо вашу задачу: оцінка й план робіт
Оцінка робіт спирається на факти, а не на припущення, тому для старту потрібен зріз поточної схеми обмінів і вимог до неї. Частина пунктів нижче закривається описом, частина — доступом до тестового середовища або вивантаженням конфігурацій. Нижче — що надіслати, щоб ми повернулися з планом інтеграції, а не з уточнювальними питаннями.
- Поточна схема свопів: який контракт або сервіс виконує обмін сьогодні, де рахуються суми, які кроки робляться вручну, чи використовується зовнішній агрегатор на кшталт Paraswap.
- Перелік майданчиків і мереж: де потрібна ліквідність, які майданчики мусять залишитися в маршруті обміну, а які можна виключити без втрати виконання.
- Вимоги до обмінів: допустиме прослизання, мінімальна й максимальна сума угоди, поведінка при частковому заповненні, граничний час виконання заявки.
- Очікуване навантаження: скільки обмінів на годину в середньому й у піку, скільки гаманців і користувачів працює паралельно, чи є сезонні сплески.
- Ролі доступу й ключовий контур: хто ініціює і хто підписує операцію, де зберігаються ключі, чи є ліміти на окрему транзакцію й на денний оборот.
- Середовища: яка тестова мережа використовується, чим вона відрізняється від робочого контуру за доступною ліквідністю й налаштуваннями.
- Звітність і контроль: який журнал операцій потрібен, як відстежується розходження між заявкою й фактичним виконанням, куди йдуть події про помилки.
Якщо за частиною пунктів відповіді поки немає, це теж робочий варіант: зафіксуємо їх як відкриті в постановці задачі й закриємо на етапі розбору. Після цього повернемося з планом інтеграції — порядок робіт, точки відкату, критерії приймання — і почнемо з тестового контуру.
