Встроенный своп токенов для мобильного криптокошелька

Своп токенов в мобильном кошельке: где ломается путь

Своп токенов в мобильном кошельке — это не одна транзакция, а цепочка: запрос котировки у агрегатора, подпись, отправка в сеть и ожидание подтверждения. Котировка живёт короткое окно — за него состояние пулов меняется, и цифра, которую пользователь видел на экране, перестаёт быть актуальной. Пока приложение на переднем плане, цепочка чаще всего проходит целиком.

Сбой начинается на подтверждении. Пользователь уходит в приложение банка, в мессенджер за кодом или в браузер, и мобильная система выгружает кошелёк из памяти. Подписанный запрос уже ушёл, а экран состояния потерян: приложение не знает, подтвердилась операция или сеть её отклонила. Так появляется незавершённый обмен — токены списаны, целевой актив не зачислен, а в истории операций записи нет.

Вторая ветка — расхождение курса. Пользователь возвращается, видит пересчитанную сумму, которая не совпадает с подтверждённой, и читает это как потерю средств. Дальше — уход пользователя: обращение он не оставит, просто удалит кошелёк, а поддержка получит жалобу без идентификатора операции, хеша и времени подписи, по которой восстановить ход событий невозможно.

Мы проектируем обмен как распределённую операцию с локальным журналом состояний: котировку берём у агрегаторов ликвидности, включая 1inch, а результат фиксируем независимо от того, был ли экран активен. Ниже разбираем, как закрывается этот путь — от восстановления сессии обмена после возврата в приложение до разбора инцидентов по логам.

Что даёт встроенный обмен: доля завершённых операций и скорость

Обмен внутри кошелька — это не ещё одна кнопка на экране, а собственный маршрут исполнения сделки. Пользователь подписывает транзакцию тем же ключом, что и остальные операции, не покидая приложение и не перенося фразу восстановления на сторонний сайт. Для продукта это снимает главный источник потерь — обрыв сценария на переходе в чужой сервис.

Доля завершённых обменов — ключевая метрика встраивания. В сценарии с выходом на внешнюю площадку до подтверждения доходит 55–70% начатых операций: часть аудитории настораживает незнакомый домен, часть теряет введённую сумму при повторном подключении. После переноса обмена в приложение показатель держится на уровне 92–97%, и разница видна уже в первые недели.

Маршрут обмена собирает агрегатор: сумма разбивается между несколькими пулами и площадками, поэтому проскальзывание цены на крупных объёмах ниже, чем при прямой сделке с одной биржей. В связке с 1inch мы прогнозируем итоговую цену до подписи и показываем допустимое отклонение — пользователь видит, сколько получит, а не узнаёт об этом после исполнения.

Отказы провайдера перестают быть проблемой пользователя. Если источник котировок или узел сети недоступен, кошелёк перестраивает маршрут либо отдаёт понятную ошибку до списания средств, а не оставляет транзакцию в подвешенном состоянии. Время до подтверждения сокращается примерно вдвое: исчезают отдельное подключение к внешнему сервису и лишние подтверждения.

Способы встроить обмен: свой агрегатор или внешний сервис

Выбор способа обмена определяет, кто отвечает за маршрут сделки и откуда берётся цена. Собственный агрегатор сам опрашивает источники ликвидности и собирает маршрут под конкретную пару; внешний сервис обмена отдаёт готовую котировку по своему каналу; обмен на смарт-контракте внутри кошелька исполняется без посредника; гибридная схема держит основной маршрут у себя, а резервный уводит во внешний источник при просадке.

Сравнивать варианты стоит не по принципу «лучше или хуже», а по тому, что команда готова держать на своей стороне: список подключённых источников ликвидности, политику приоритета, ответственность за отказ маршрута и объём работ при добавлении новой сети.

Разбираем, как это закрывается в конкретном приложении: обсудим ваши источники ликвидности и вернёмся с оценкой и планом.

Как проходит внедрение: от аудита до передачи

Внедрение обмена токенов внутри кошелька — работа с деньгами пользователя на устройстве, где транзакцию нельзя откатить. Поэтому начинаем с аудита кошелька, а не с подключения экрана обмена.

1. Аудит кошелька. Смотрим хранилище ключей, модуль подписи, поддержанные сети и готовность интерфейса к экрану котировки. Фиксируем, что дорабатываем, а что переиспользуем как есть.
2. Схема маршрутов. Решаем, откуда берём котировки, сколько источников опрашиваем параллельно и чем резервируем маршрут, если цена изменилась между показом и подтверждением.
3. Настройка лимитов. Задаём минимум и максимум обмена, допустимое проскальзывание, суточные потолки и число повторных попыток — сбойный маршрут не уведёт больше заложенного.
4. Сборка обмена. Экран котировки с обратным отсчётом, подпись только на устройстве, итоговая сумма видна пользователю до подтверждения, а не после.
5. Проверка обмена. Прогоняем сценарии отказа: недоступные котировки, изменившаяся цена, отклонённая подпись, обрыв сети при отправке — с ожидаемым поведением кошелька и понятным сообщением.
6. Приёмка. Сверяем исполненные сделки с расчётными: списание, зачисление, комиссия сети. Расхождение — повод вернуться к схеме маршрутов, а не выпускать сборку.
7. Передача в эксплуатацию. Отдаём конфигурации лимитов и маршрутов, схему мониторинга, инструкции поддержке и порядок обновления источников котировок без нового релиза приложения.

После передачи смотрим долю успешных обменов, время от нажатия до подтверждения в сети и отказы по каждому маршруту — узкое место видно раньше, чем его заметят пользователи.

Что остаётся в проекте: схемы, лимиты, регламенты

Проект закрывается не демонстрацией, а набором артефактов, по которым ваша команда сама ведёт своп токенов в кошельке. Всё, что настраивалось на тестовых и рабочих средах, передаётся в документах и конфигурациях с версионированием — изменение можно отследить и откатить.

• Схема интеграции — путь от интерфейса свопа до подписанной транзакции: ядро кошелька, источник котировок, узлы сети, точки отказа и поведение приложения в каждой из них.
• Настройки маршрутизации и политика лимитов — порядок выбора маршрута обмена, допустимое проскальзывание, минимальная и максимальная сумма, суточный лимит на кошелёк и порог расхождения цен, при котором обмен останавливается.
• Политики доступа — роли на обновление списка токенов, правку лимитов и выпуск сборок, разграничение сред, ротация ключей подписи.
• Регламент обновления списка токенов — источник перечня, проверка контракта и метаданных, кто утверждает добавление и за какое время токен скрывается при инциденте.
• Инструкция поддержки — разбор типовых обращений: обмен завис в ожидании, котировка истекла, транзакция не подтвердилась, баланс не обновился; что проверить и когда эскалировать.
• Журнал операций — запросы свопа, выбранные маршруты, отказы и ошибки с идентификатором сессии: инцидент разбирается по данным, без созвонов с нами.

Перед передачей сверяемся по этому списку вместе с вашей командой и фиксируем владельца каждого пункта — поддержка не зависит от того, кто вёл разработку.

Кейс: рост доли завершённых обменов в кошельке

Встроенный обмен в розничном кошельке выглядел рабочим, пока смотрели на экраны, а не на воронку. По логам доля брошенных обменов держалась около половины: человек выбирал пару, видел цену и закрывал экран, не дойдя до подписи. Причины оказались техническими — котировка устаревала за время перехода к подтверждению, а единственный источник ликвидности при просадке отдавал ошибку, и сценарий падал целиком.

Что меняли

Выдачу цены развели на два шага: ориентировочный курс показывается сразу при выборе пары, точная котировка запрашивается перед подписью, с обратным отсчётом и автопродлением. Маршрутизацию перевели на несколько источников ликвидности с автопереключением: если провайдер не ответил в отведённое время или вернул ошибку, запрос уходит к следующему. 1inch держим как один из маршрутизаторов, а не как единственную точку отказа.

Отдельно переписали обработку сбоев: вместо общей ошибки видно, на каком шаге обмен прервался, операцию можно повторить тем же маршрутом, а история попыток остаётся в кошельке. Это убрало слепые обращения в поддержку.

Что получилось

Доля завершённых операций выросла, брошенные обмены сократились примерно втрое. Время от подтверждения намерения до подписи уменьшилось с 40-50 до 10-15 секунд — почти весь разрыв давало ожидание котировки. Отказ отдельного провайдера больше не роняет сценарий целиком, а обращения в поддержку по теме обмена упали вдвое.

Чем обмен внутри приложения отличается от внешнего сервиса?

Встроенный обмен — это транзакция, которую пользователь подписывает там же, где хранит ключи. Приложение не отдаёт управление наружу: котировку отдаёт агрегатор ликвидности (например, 1inch) или пул напрямую, маршрут собирается на клиенте, подпись уходит в сеть из того же процесса. Внешний обменник устраивает иначе — пользователь подключает кошелёк к чужому домену, теряет контекст сессии и возвращается в приложение вручную.

Разница видна на воронке. Каждый выход из приложения — точка потери: часть пользователей не возвращается, часть подписывает не тот маршрут, часть бросает на середине. Конверсия в обмен падает не из-за курса, а из-за числа шагов. Когда обмен встроенный, путь сокращается до пары, суммы и подтверждения, а состояние сделки обновляется в реальном времени.

Инженерно это подсистема, а не кнопка: маршрутизация между источниками ликвидности, расчёт минимально приемлемого количества на выходе, проверка, что котировка не протухла до подписи, обработка отклонённой и зависшей транзакции. Ответственность за неудачную сделку остаётся на нас, а не размывается между двумя продуктами.

Для команды меняется и эксплуатация: появляются метрики по доле успешных сделок, времени до подтверждения и причинам отказов — нехватка средств на комиссию, устаревший маршрут, отказ узла. Всё это закрывается в приложении, данные о поведении пользователя остаются внутри, без слепой зоны после перехода.

Частые вопросы: ликвидность, лимиты, сбои сети

Обмен в кошельке — операция, где сходятся три независимых контура: устройство пользователя, маршрутизатор ликвидности и сеть. Сбой любого из них клиент видит как «своп завис», хотя причина и цена ошибки у каждого свои. Ниже — ответы на сомнения, которые чаще всего всплывают на этапе оценки интеграции.

Каждый пункт — про механику, а не про намерение: где именно перехватывается отказ и что в этот момент видит пользователь.

Чей источник ликвидности используется?

Свою ликвидность мы не держим. Маршрутизатор собирает предложения из нескольких внешних источников, сравнивает итоговую сумму с учётом комиссии сети и проскальзывания и берёт лучший маршрут; при ошибке источника маршрут перестраивается.

Как защищены ключи пользователя?

Ключ создаётся и остаётся в защищённой зоне устройства, наружу уходит только подпись. Ни наш код, ни серверная часть ключ не видят и не могут запросить; подтверждение операции закрыто биометрией.

Как добавляете новые токены?

Токен попадает в каталог после проверки контракта: адрес, точность, наличие торговой пары, поведение при переводе и ограничения на продажу. Каталог обновляется на сервере, поэтому список меняется без выпуска новой версии приложения.

Где проходит проверка клиента?

Проверка вынесена за пределы обмена и запускается до операций с банковским счётом: приложение получает только вердикт, документы в кошельке не хранятся. На уже проверенном профиле обмен не требует повторного прохождения.

Обсудим задачу: с чего начнём и что понадобится

Чтобы мы вернулись с оценкой сроков и планом работ, а не с уточняющими вопросами через неделю, нужен минимальный набор входных данных. Встроенный своп — это не отдельный экран, а связка из расчёта маршрута, подписи транзакции и обработки отказов, поэтому важны и сценарии, и то, как сейчас устроен кошелёк.

Что помогает стартовать сразу:

• Описание сценариев: какие пары токенов нужны, откуда берётся курс, что показываем пользователю при резком движении цены и как объясняем ограничение проскальзывания.
• Доступы к репозиторию и сборке: как устроены хранение ключей, слой подписи и учёт балансов, какие сети уже поддержаны, где проходит граница между нативным кодом и общими модулями.
• Схема маршрутизации: считаем ли мы маршрут сами или опираемся на внешние источники ликвидности, кто и на каком шаге фиксирует минимально получаемую сумму.
• Перечень сетей и токенов, включая обёрнутые варианты и токены с нестандартным поведением при переводе.
• Материалы по безопасности: требуется ли подтверждение операции по биометрии, есть ли аппаратная защита ключей, какие проверки адресов получателя обязательны.
• Текущие метрики по кошельку: доля успешных операций, медианное время до подтверждения, распределение причин отказов.
• Ограничения по правилам магазинов приложений и по юрисдикциям, в которых работает продукт.

Опишите задачу в свободной форме — вернёмся с оценкой сроков, разбивкой по этапам и перечнем рисков, которые стоит закрыть до старта разработки.