Skip to main content
The prepare recipe 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

The API reference contains the complete current error contract. Keep request IDs in diagnostics without collecting wallet secrets or raw credential-bearing provider errors.