Token swaps in a mobile wallet: where the path breaks
A token swap in a mobile wallet is not a single transaction but a chain: requesting a quote from an aggregator, signing, sending to the network, and waiting for confirmation.
A quote lives for a short window — during it the state of pools changes, and the figure the user saw on screen stops being current. While the app is in the foreground, the chain usually completes in full.
The failure starts at confirmation. The user goes to a banking app, to a messenger for a code, or to a browser, and the mobile system unloads the wallet from memory.
The signed request has already gone out, but the status screen is lost: the app does not know whether the operation was confirmed or the network rejected it.
This is how an incomplete swap appears — tokens are debited, the target asset is not credited, and there is no entry in the transaction history.
The second branch is a rate discrepancy. The user returns, sees a recalculated amount that does not match the confirmed one, and reads this as a loss of funds.
Then comes user churn: they will not leave a request, they will simply delete the wallet, and support will receive a complaint without the operation ID, hash, or signing time, by which it is impossible to reconstruct the sequence of events.
We design the swap as a distributed operation with a local state journal: we take the quote from liquidity aggregators, including 1inch, and record the result regardless of whether the screen was active.
Below we break down how this path is closed — from restoring the swap session after returning to the app to analyzing incidents from logs.
What a built-in swap provides: completion rate and speed
A swap inside the wallet is not just another button on the screen but a dedicated trade execution route. The user signs the transaction with the same key as other operations, without leaving the app and without moving the recovery phrase to a third-party site.
For the product, this removes the main source of losses — a broken flow when moving to an external service.
The share of completed swaps is the key integration metric. In a scenario with going to an external platform, 55–70% of started operations reach confirmation: part of the audience is wary of the unfamiliar domain, part loses the entered amount when reconnecting.
After moving the swap into the app, the metric stays at 92–97%, and the difference is visible in the first weeks.
The swap route is assembled by an aggregator: the amount is split across several pools and venues, so price slippage on large volumes is lower than with a direct trade on a single exchange.
In conjunction with 1inch, we forecast the final price before signing and show the allowed deviation — the user sees how much they will receive instead of finding out after execution.
Provider failures stop being the user's problem. If a quote source or network node is unavailable, the wallet rebuilds the route or returns a clear error before debiting funds, rather than leaving the transaction in limbo.
Time to confirmation is roughly halved: a separate connection to an external service and extra confirmations disappear.
Ways to integrate a swap: your own aggregator or an external service
The choice of swap method determines who is responsible for the trade route and where the price comes from.
Your own aggregator queries liquidity sources itself and assembles a route for a specific pair; an external swap service provides a ready quote through its own channel; a smart contract swap inside the wallet executes without an intermediary; a hybrid scheme keeps the primary route in-house and routes the backup to an external source during a liquidity drop.
Options should be compared not on a "better or worse" basis but on what the team is ready to own: the list of connected liquidity sources, the priority policy, responsibility for route failure, and the amount of work when adding a new network.
| Option | When it fits | Limitations |
|---|---|---|
| Your own aggregator | Multiple networks and a wide list of pairs, you need your own priority and fee policy | You need to maintain a pool index and track venue updates — otherwise the route quietly becomes outdated |
| External swap service | Fast launch, a narrow set of pairs, readiness to hand the route to a provider | Price and availability depend on a single channel; limits and the network list are set by the partner |
| Smart contract swap | One or two key pairs with predictable fees and minimal trust | Liquidity only from connected pools; expanding the pair list is done manually |
| Hybrid scheme | You need your own control and a backup route in case of liquidity drop | Two failure contours: monitoring and reconciling quote discrepancies are more complex |
We'll break down how this is closed in a specific app: we'll discuss your liquidity sources and come back with an estimate and a plan.
How implementation proceeds: from audit to handover
Implementing token swaps inside a wallet means working with the user's money on a device where a transaction cannot be rolled back. Therefore we start with a wallet audit, not with connecting the swap screen.
- Wallet audit. We review key storage, the signing module, supported networks, and the interface's readiness for the quote screen. We record what we will modify and what we will reuse as is.
- Route scheme. We decide where quotes come from, how many sources we query in parallel, and how we back up the route if the price changes between display and confirmation.
- Limit setup. We set the minimum and maximum swap amounts, allowed slippage, daily caps, and the number of retries — a failing route will not move more than planned.
- Swap build. A quote screen with a countdown, signing only on the device, and the final amount visible to the user before confirmation, not after.
- Swap testing. We run failure scenarios: unavailable quotes, changed price, rejected signature, network drop during sending — with expected wallet behavior and a clear message.
- Acceptance. We reconcile executed trades with calculated ones: debit, credit, network fee. A discrepancy is a reason to return to the route scheme, not to release the build.
- Handover to operations. We provide limit and route configurations, a monitoring scheme, support instructions, and the procedure for updating quote sources without a new app release.
After handover, we monitor the share of successful swaps, time from tap to network confirmation, and failures for each route — the bottleneck is visible before users notice it.
What remains in the project: schemes, limits, procedures
The project closes not with a demo but with a set of artifacts your team can use to run token swaps in the wallet on its own.
Everything configured in test and production environments is handed over in versioned documents and configurations — changes can be traced and rolled back.
- Integration scheme — the path from the swap interface to the signed transaction: wallet core, quote source, network nodes, failure points, and the app's behavior at each of them.
- Routing settings and limit policy — the procedure for selecting the swap route, allowed slippage, minimum and maximum amount, daily limit per wallet, and the price discrepancy threshold at which the swap stops.
- Access policies — roles for updating the token list, editing limits, and releasing builds, environment separation, signing key rotation.
- Token list update procedure — the source of the list, contract and metadata checks, who approves additions, and how quickly a token is hidden during an incident.
- Support instructions — handling typical requests: a swap stuck in pending, a quote expired, a transaction was not confirmed, a balance did not update; what to check and when to escalate.
- Operation log — swap requests, selected routes, failures and errors with a session ID: incidents are analyzed from data, without calls with us.
Before handover, we go through this list together with your team and assign an owner for each item — support does not depend on who led the development.
Case study: increasing the share of completed swaps in a wallet
The built-in swap in a retail wallet looked functional as long as they looked at screens rather than the funnel. According to logs, the share of abandoned swaps stayed around half: a person chose a pair, saw the price, and closed the screen without reaching signing.
The causes turned out to be technical — the quote became outdated during the transition to confirmation, and the single liquidity source returned an error during a drawdown, so the flow failed entirely.
What we changed
Price delivery was split into two steps: an indicative rate is shown immediately when a pair is selected, and an exact quote is requested before signing, with a countdown and auto-renewal.
Routing was moved to several liquidity sources with automatic switching: if a provider does not respond within the allotted time or returns an error, the request goes to the next one. We keep 1inch as one of the routers, not as a single point of failure.
We separately rewrote failure handling: instead of a generic error, it shows at which step the swap was interrupted, the operation can be retried along the same route, and the attempt history stays in the wallet. This eliminated blind support requests.
What we achieved
The share of completed operations grew, and abandoned swaps decreased by about three times. Time from confirming the intent to signing decreased from 40-50 to 10-15 seconds — almost the entire gap was caused by waiting for the quote.
A single provider failure no longer brings down the entire flow, and support requests on the topic of swaps dropped by half.
How is an in-app swap different from an external service?
A built-in swap is a transaction the user signs where they store their keys.
The app does not hand over control: the quote is provided by a liquidity aggregator (for example, 1inch) or a pool directly, the route is assembled on the client, and the signature goes to the network from the same process.
An external exchanger works differently — the user connects the wallet to someone else's domain, loses the session context, and returns to the app manually.
The difference is visible in the funnel. Every exit from the app is a loss point: some users do not return, some sign the wrong route, some abandon midway. Conversion to swap drops not because of the rate but because of the number of steps.
When the swap is built in, the path is reduced to pair, amount, and confirmation, and the trade state updates in real time.
Engineering-wise, this is a subsystem, not a button: routing between liquidity sources, calculating the minimum acceptable output amount, checking that the quote has not expired before signing, and handling a rejected or stuck transaction.
Responsibility for an unsuccessful trade remains with us rather than being diffused between two products.
Operations change for the team as well: metrics appear for the share of successful trades, time to confirmation, and failure reasons — insufficient funds for the fee, outdated route, node failure.
All of this is covered inside the app, user behavior data stays inside, with no blind spot after the transition.
FAQ: liquidity, limits, network failures
A swap in a wallet is an operation where three independent contours meet: the user's device, the liquidity router, and the network. A failure in any of them is seen by the client as "swap stuck", although the cause and cost of the error are different for each. Below are answers to the doubts that most often come up during the integration assessment stage.
Each item is about mechanics, not intent: exactly where a failure is intercepted and what the user sees at that moment.
What happens if the network is unavailable at the moment of the swap?
The swap does not start: before signing, the app checks node status and fee estimate, and if there is a drop, it shows a "waiting for network" state with the option to cancel. The retry request is tied to the quote ID — a second transaction will not appear.
Whose liquidity source is used?
We do not hold our own liquidity. The router collects offers from several external sources, compares the final amount taking into account the network fee and slippage, and takes the best route; if a source fails, the route is rebuilt.
How are user keys protected?
The key is created and remains in the device's secure area; only the signature goes out. Neither our code nor the server side sees or can request the key; operation confirmation is protected by biometrics.
How do you add new tokens?
A token enters the catalog after contract verification: address, decimals, presence of a trading pair, transfer behavior, and sell restrictions. The catalog is updated on the server, so the list changes without releasing a new app version.
Where does client verification take place?
Verification is moved outside the swap and starts before operations with a bank account: the app receives only the verdict, and documents are not stored in the wallet. On an already verified profile, the swap does not require re-verification.
Let's discuss the task: where we start and what is needed
So that we come back with a timeline estimate and work plan rather than with clarifying questions a week later, a minimum set of inputs is needed.
A built-in swap is not a separate screen but a combination of route calculation, transaction signing, and failure handling, so both the scenarios and how the wallet is currently structured matter.
What helps to start immediately:
- Description of scenarios: which token pairs are needed, where the rate comes from, what we show the user during a sharp price move, and how we explain the slippage limit.
- Access to the repository and build: how key storage, the signing layer, and balance accounting are structured, which networks are already supported, and where the boundary lies between native code and shared modules.
- Routing scheme: whether we calculate the route ourselves or rely on external liquidity sources, who fixes the minimum received amount and at which step.
- List of networks and tokens, including wrapped variants and tokens with non-standard transfer behavior.
- Security materials: whether biometric confirmation of operations is required, whether hardware key protection exists, which recipient address checks are mandatory.
- Current wallet metrics: share of successful operations, median time to confirmation, distribution of failure reasons.
- Restrictions under app store rules and the jurisdictions in which the product operates.
Describe the task in free form — we will come back with a timeline estimate, a breakdown by stages, and a list of risks that should be closed before development starts.