> ## Documentation Index
> Fetch the complete documentation index at: https://docs.route.fun/llms.txt
> Use this file to discover all available pages before exploring further.

# complete the wallet flow

> Take a prepared swap through approval, signing and confirmation.

The [prepare recipe](/cookbook/prepare-swap) gives you an unsigned transaction. Here's how to take it through the wallet. The user must approve signing before any swap is submitted.

## 1. Review the intended swap

Check that the wallet is on chain `4663`. Show the input, output token, expected amount received, minimum, Route fee, gas estimate and recipient. Save the account, chain, provider, executor and minimum the user reviewed. If any of those change, ask them to review the swap again.

Read executors from `/api/v2/config`; never let an arbitrary request field choose one. The compatibility `executors` map is not sufficient when an output-specific `tokenOutputExecutors` entry applies.

## 2. Handle ERC-20 allowance when required

Native ETH requires no token approval. For ERC-20 input:

1. Read `allowance(owner, reviewedExecutor)` on the selected chain.
2. If it covers exact input, proceed without another approval.
3. Otherwise validate that `prepared.approval.token` is the input token, `spender` is the reviewed executor and `amount` equals exact input. Decode its `approve` calldata and check the same values, zero native value and the token target.
4. Request the wallet's approval and wait for a successful receipt. If the token requires clearing an existing nonzero allowance first, present that separate zero-approval transaction explicitly.
5. Re-read allowance. An approval transaction's existence does not prove sufficient allowance.

Do not approve an upstream router or 0x Settler instead of Route's reviewed executor. If the user rejects the subsequent swap, an already confirmed allowance remains until used or revoked.

## 3. Refresh after approval or delay

Get a new quote and rebuild with the user's original minimum, provider, variant and approved executor. If the price no longer meets that minimum, stop and show the new quote. Ask for another review before changing the provider, spender, recipient or fee.

`expiresAt` is a freshness hint checked by the API, not a signature reserving a price. `deadline` is independently encoded onchain. Preserve both; do not manufacture a later quote expiry to make a stale quote build.

## 4. Simulate from the actual account

The swap builder returns `simulationRequired: true`. It does not check the caller's balance or allowance and does not simulate the complete wallet transaction. Use your wallet's chain client to:

* Check actual input balance, native value and ETH available for gas.
* Call the exact transaction from the signing account with a positive admissible gas price.
* Estimate its gas and prepare fee fields for the current block. For EIP-1559, keep the fee cap sufficient for the observed base fee and priority fee.
* Simulate again if calldata, account, chain, value or fee fields change.

For example, a viem public client accepts `call({ account, to, data, value, ...feeFields })` and `estimateGas` with the same transaction context. Convert API integer strings to `bigint`. Configure the client for chain `4663`; do not take an RPC endpoint from untrusted swap input.

If using EIP-5792, first check the wallet's atomic capability on this chain and simulate the ordered approval-plus-swap calls. Unsupported wallets use separate transactions. A successful ordinary transaction simulation is not proof that a wallet batch envelope will execute.

## 5. Sign once and reconcile the receipt

Immediately before requesting the wallet signature, verify account, chain, executor, recipient, exact input, minimum, deadline and fee against the review. Request the transaction only after user confirmation. Persist the returned transaction hash and show a pending state.

Wait for a successful receipt. Decode the expected executor's `Swapped` event and verify the recipient, assets, exact input and received output against the reviewed minimum. Do not accept another contract's event with the same signature as proof. The active fee-free executor does not emit `FeePaid`.

If submission or confirmation times out, check the existing transaction hash and wallet state before retrying. Sending again could execute a second swap. Show wallet rejection, an onchain revert and a pending transaction as separate states.

## Handle API failures

| Result                                                           | Integration behavior                                                                           |
| ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| `409 QUOTE_EXPIRED` or `PRICE_CHANGED`                           | Request a new quote and preserve the accepted minimum or request a new review                  |
| `429 BUSY`                                                       | Honor `Retry-After`; cancel superseded requests instead of retrying every edit                 |
| `422 NO_EXECUTABLE_ROUTE`                                        | Show that no checked route is available; do not turn a failed candidate into a signable swap   |
| `503 RPC_UNAVAILABLE`, `UPSTREAM_RATE_LIMITED` or `NOT_DEPLOYED` | Show temporary unavailability or disabled-provider state; no blind signing or rapid retry loop |
| Unknown submission result                                        | Reconcile the existing transaction before another submission                                   |

The [API reference](/api-reference/overview) contains the complete current error contract. Keep request IDs in diagnostics without collecting wallet secrets or raw credential-bearing provider errors.