Своп токенів у мобільному гаманці: де ламається шлях
Своп токенів у мобільному гаманці — це не одна транзакція, а ланцюг: запит котирування в агрегатора, підпис, надсилання в мережу й очікування підтвердження.
Котирування живе коротке вікно — за цей час стан пулів змінюється, і цифра, яку користувач бачив на екрані, перестає бути актуальною. Поки застосунок на передньому плані, ланцюг найчастіше проходить повністю.
Збій починається на підтвердженні. Користувач переходить у застосунок банку, у месенджер за кодом або в браузер, і мобільна система вивантажує гаманець із пам’яті.
Підписаний запит уже пішов, а екран стану втрачено: застосунок не знає, підтвердилася операція чи мережа її відхилила. Так з’являється незавершений обмін — токени списано, цільовий актив не зараховано, а в історії операцій запису немає.
Друга гілка — розбіжність курсу. Користувач повертається, бачить перераховану суму, яка не збігається з підтвердженою, і сприймає це як втрату коштів.
Далі — відхід користувача: звернення він не залишить, просто видалить гаманець, а підтримка отримає скаргу без ідентифікатора операції, хешу й часу підпису, за якими відновити хід подій неможливо.
Ми проєктуємо обмін як розподілену операцію з локальним журналом станів: котирування беремо в агрегаторів ліквідності, включно з 1inch, а результат фіксуємо незалежно від того, чи був екран активний.
Нижче розбираємо, як закривається цей шлях — від відновлення сесії обміну після повернення в застосунок до розбору інцидентів за логами.
Що дає вбудований обмін: частка завершених операцій і швидкість
Обмін усередині гаманця — це не ще одна кнопка на екрані, а власний маршрут виконання угоди. Користувач підписує транзакцію тим самим ключем, що й інші операції, не залишаючи застосунок і не переносячи фразу відновлення на сторонній сайт. Для продукту це знімає головне джерело втрат — обрив сценарію під час переходу в чужий сервіс.
Частка завершених обмінів — ключова метрика вбудовування. У сценарії з виходом на зовнішній майданчик до підтвердження доходить 55–70% розпочатих операцій: частину аудиторії насторожує незнайомий домен, частина втрачає введену суму під час повторного підключення.
Після перенесення обміну в застосунок показник тримається на рівні 92–97%, і різниця видна вже в перші тижні.
Маршрут обміну збирає агрегатор: сума розбивається між кількома пулами й майданчиками, тому прослизання ціни на великих обсягах нижче, ніж за прямої угоди з однією біржею.
У зв’язці з 1inch ми прогнозуємо підсумкову ціну до підпису та показуємо допустиме відхилення — користувач бачить, скільки отримає, а не дізнається про це після виконання.
Відмови провайдера перестають бути проблемою користувача. Якщо джерело котирувань або вузол мережі недоступний, гаманець перебудовує маршрут або видає зрозумілу помилку до списання коштів, а не залишає транзакцію в підвішеному стані.
Час до підтвердження скорочується приблизно вдвічі: зникають окреме підключення до зовнішнього сервісу та зайві підтвердження.
Способи вбудувати обмін: власний агрегатор або зовнішній сервіс
Вибір способу обміну визначає, хто відповідає за маршрут угоди і звідки береться ціна.
Власний агрегатор сам опитує джерела ліквідності й збирає маршрут під конкретну пару; зовнішній сервіс обміну віддає готове котирування своїм каналом; обмін на смарт-контракті всередині гаманця виконується без посередника; гібридна схема тримає основний маршрут у себе, а резервний спрямовує до зовнішнього джерела у разі просідання.
Порівнювати варіанти варто не за принципом «краще чи гірше», а за тим, що команда готова тримати на своїй стороні: список підключених джерел ліквідності, політику пріоритету, відповідальність за відмову маршруту й обсяг робіт під час додавання нової мережі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний агрегатор | Кілька мереж і широкий список пар, потрібна своя політика пріоритету та комісії | Потрібно підтримувати індекс пулів і відстежувати оновлення майданчиків — інакше маршрут тихо застаріває |
| Зовнішній сервіс обміну | Швидкий запуск, вузький набір пар, готовність віддати маршрут постачальнику | Ціна й доступність залежать від одного каналу; ліміти та список мереж задає партнер |
| Обмін на смарт-контракті | Одна-дві ключові пари з передбачуваною комісією і мінімумом довіри | Ліквідність лише з підключених пулів; розширення списку пар робиться вручну |
| Гібридна схема | Потрібен свій контроль і запасний маршрут на випадок просідання ліквідності | Два контури відмов: складніше спостереження й розбір розбіжностей між котировками |
Розбираємо, як це закривається в конкретному застосунку: обговоримо ваші джерела ліквідності та повернемося з оцінкою і планом.
Як відбувається впровадження: від аудиту до передачі
Впровадження обміну токенів усередині гаманця — це робота з коштами користувача на пристрої, де транзакцію не можна відкотити. Тому починаємо з аудиту гаманця, а не з підключення екрана обміну.
- Аудит гаманця. Дивимося на сховище ключів, модуль підпису, підтримувані мережі та готовність інтерфейсу до екрана котирування. Фіксуємо, що доопрацьовуємо, а що використовуємо повторно як є.
- Схема маршрутів. Вирішуємо, звідки беремо котирування, скільки джерел опитуємо паралельно і чим резервуємо маршрут, якщо ціна змінилася між показом і підтвердженням.
- Налаштування лімітів. Задаємо мінімум і максимум обміну, допустиме прослизання, добові стелі та кількість повторних спроб — збійний маршрут не відведе більше закладеного.
- Збірка обміну. Екран котирування зі зворотним відліком, підпис лише на пристрої, підсумкова сума видима користувачеві до підтвердження, а не після.
- Перевірка обміну. Проганяємо сценарії відмови: недоступні котирування, змінена ціна, відхилений підпис, обрив мережі під час надсилання — з очікуваною поведінкою гаманця та зрозумілим повідомленням.
- Приймання. Звіряємо виконані угоди з розрахунковими: списання, зарахування, комісія мережі. Розбіжність — привід повернутися до схеми маршрутів, а не випускати збірку.
- Передача в експлуатацію. Віддаємо конфігурації лімітів і маршрутів, схему моніторингу, інструкції підтримці та порядок оновлення джерел котирувань без нового релізу застосунку.
Після передачі дивимося частку успішних обмінів, час від натискання до підтвердження в мережі та відмови за кожним маршрутом — вузьке місце видно раніше, ніж його помітять користувачі.
Що залишається в проєкті: схеми, ліміти, регламенти
Проєкт закривається не демонстрацією, а набором артефактів, за якими ваша команда сама веде своп токенів у гаманці. Усе, що налаштовувалося в тестових і робочих середовищах, передається в документах і конфігураціях із версіонуванням — зміну можна відстежити й відкотити.
- Схема інтеграції — шлях від інтерфейсу свопу до підписаної транзакції: ядро гаманця, джерело котирувань, вузли мережі, точки відмови та поведінка застосунку в кожній із них.
- Налаштування маршрутизації та політика лімітів — порядок вибору маршруту обміну, допустиме просковзування, мінімальна й максимальна сума, добовий ліміт на гаманець і поріг розбіжності цін, за якого обмін зупиняється.
- Політики доступу — ролі на оновлення списку токенів, правку лімітів і випуск збірок, розмежування середовищ, ротація ключів підпису.
- Регламент оновлення списку токенів — джерело переліку, перевірка контракту й метаданих, хто затверджує додавання і за який час токен приховується при інциденті.
- Інструкція підтримки — розбір типових звернень: обмін завис в очікуванні, котирування минуло, транзакція не підтвердилася, баланс не оновився; що перевірити і коли ескалювати.
- Журнал операцій — запити свопу, вибрані маршрути, відмови та помилки з ідентифікатором сесії: інцидент розбирається за даними, без дзвінків із нами.
Перед передачею звіряємося за цим списком разом із вашою командою і фіксуємо власника кожного пункту — підтримка не залежить від того, хто вів розробку.
Кейс: зростання частки завершених обмінів у гаманці
Вбудований обмін у роздрібному гаманці виглядав робочим, поки дивилися на екрани, а не на воронку. За логами частка покинутих обмінів трималася близько половини: людина обирала пару, бачила ціну й закривала екран, не дійшовши до підпису.
Причини виявилися технічними — котирування застарівало за час переходу до підтвердження, а єдине джерело ліквідності при просіданні видавало помилку, і сценарій падав цілком.
Що змінювали
Видачу ціни розділили на два кроки: орієнтовний курс показується одразу при виборі пари, точне котирування запитується перед підписом, зі зворотним відліком і автопродовженням.
Маршрутизацію перевели на кілька джерел ліквідності з автоперемиканням: якщо провайдер не відповів за відведений час або повернув помилку, запит іде до наступного. 1inch тримаємо як один із маршрутизаторів, а не як єдину точку відмови.
Окремо переписали обробку збоїв: замість загальної помилки видно, на якому кроці обмін перервався, операцію можна повторити тим самим маршрутом, а історія спроб залишається в гаманці. Це прибрало сліпі звернення до підтримки.
Що вийшло
Частка завершених операцій зросла, покинуті обміни скоротилися приблизно втричі. Час від підтвердження наміру до підпису зменшився з 40-50 до 10-15 секунд — майже весь розрив давало очікування котирування.
Відмова окремого провайдера більше не обрушує сценарій цілком, а звернення до підтримки щодо обміну впали вдвічі.
Чим обмін у застосунку відрізняється від зовнішнього сервісу?
Вбудований обмін — це транзакція, яку користувач підписує там само, де зберігає ключі. Застосунок не передає керування назовні: котирування надає агрегатор ліквідності (наприклад, 1inch) або пул напряму, маршрут збирається на клієнті, підпис іде в мережу з того самого процесу.
Зовнішній обмінник діє інакше — користувач підключає гаманець до чужого домену, втрачає контекст сесії й повертається в застосунок вручну.
Різниця видна на воронці. Кожен вихід із застосунку — точка втрати: частина користувачів не повертається, частина підписує не той маршрут, частина зупиняється посередині. Конверсія в обмін падає не через курс, а через кількість кроків.
Коли обмін вбудований, шлях скорочується до пари, суми й підтвердження, а стан угоди оновлюється в реальному часі.
З інженерного погляду це підсистема, а не кнопка: маршрутизація між джерелами ліквідності, розрахунок мінімально прийнятної кількості на виході, перевірка, що котирування не застаріло до підпису, обробка відхиленої та завислої транзакції. Відповідальність за невдалу угоду залишається на нас, а не розмивається між двома продуктами.
Для команди змінюється й експлуатація: з’являються метрики щодо частки успішних угод, часу до підтвердження та причин відмов — нестача коштів на комісію, застарілий маршрут, відмова вузла.
Усе це закривається в застосунку, дані про поведінку користувача залишаються всередині, без сліпої зони після переходу.
Часті питання: ліквідність, ліміти, збої мережі
Обмін у гаманці — операція, де сходяться три незалежні контури: пристрій користувача, маршрутизатор ліквідності та мережа. Збій будь-якого з них клієнт бачить як «своп завис», хоча причина й ціна помилки в кожного свої. Нижче — відповіді на сумніви, які найчастіше виникають на етапі оцінки інтеграції.
Кожен пункт — про механіку, а не про намір: де саме перехоплюється відмова і що в цей момент бачить користувач.
Що відбувається, якщо мережа недоступна в момент обміну?
Своп не стартує: до підпису застосунок перевіряє статус вузла та оцінку комісії, а при обриві показує стан «очікування мережі» з можливістю скасувати. Повторний запит прив’язаний до ідентифікатора котирування — другої транзакції не з’явиться.
Чиє джерело ліквідності використовується? Свою ліквідність ми не тримаємо. Маршрутизатор збирає пропозиції з кількох зовнішніх джерел, порівнює підсумкову суму з урахуванням комісії мережі та прослизання й обирає найкращий маршрут; у разі помилки джерела маршрут перебудовується.
Як захищені ключі користувача? Ключ створюється й залишається в захищеній зоні пристрою, назовні виходить лише підпис. Ні наш код, ні серверна частина ключ не бачать і не можуть його запросити; підтвердження операції закрито біометрією.
Як додаєте нові токени? Токен потрапляє до каталогу після перевірки контракту: адреса, точність, наявність торгової пари, поведінка при переказі та обмеження на продаж. Каталог оновлюється на сервері, тому список змінюється без випуску нової версії застосунку.
Де відбувається перевірка клієнта? Перевірку винесено за межі обміну й запускають до операцій з банківським рахунком: застосунок отримує лише вердикт, документи в гаманці не зберігаються. На вже перевіреному профілі обмін не потребує повторного проходження.
Обговоримо задачу: з чого почнемо і що знадобиться
Щоб ми повернулися з оцінкою термінів і планом робіт, а не з уточнювальними питаннями через тиждень, потрібен мінімальний набір вхідних даних.
Вбудований своп — це не окремий екран, а зв’язка з розрахунку маршруту, підпису транзакції та обробки відмов, тому важливі і сценарії, і те, як зараз влаштований гаманець.
Що допомагає стартувати одразу:
- Опис сценаріїв: які пари токенів потрібні, звідки береться курс, що показуємо користувачеві при різкому русі ціни і як пояснюємо обмеження прослизання.
- Доступи до репозиторію та збірки: як влаштовані зберігання ключів, шар підпису та облік балансів, які мережі вже підтримано, де проходить межа між нативним кодом і спільними модулями.
- Схема маршрутизації: чи розраховуємо маршрут самостійно, чи спираємося на зовнішні джерела ліквідності, хто і на якому кроці фіксує мінімально отримувану суму.
- Перелік мереж і токенів, включно з обгорнутими варіантами та токенами з нестандартною поведінкою під час переказу.
- Матеріали щодо безпеки: чи потрібне підтвердження операції за біометрією, чи є апаратний захист ключів, які перевірки адрес одержувача обов’язкові.
- Поточні метрики за гаманцем: частка успішних операцій, медіанний час до підтвердження, розподіл причин відмов.
- Обмеження за правилами магазинів застосунків і за юрисдикціями, у яких працює продукт.
Опишіть задачу у вільній формі — повернемося з оцінкою термінів, розбивкою за етапами та переліком ризиків, які варто закрити до старту розробки.
