Skip to main content
Both the RFQ API and Router API expose two execution modes. The mode arrives on each quote candidate as executionMode, and preflight returns the exact nextActions for the candidate you selected.

​
Wallet Broadcast (executionMode: walletBroadcast)

The settlement transaction leaves from your own wallet: preflight hands you the prepared payload (nextActions, actor: userWallet) and your RPC does the rest. The loop: quote → preflight → sign and broadcast the prepared payload Fits: teams already running their own submission pipelines - solvers, aggregators, liquidators - plus any candidate settling through an external venue or bridge. What defines it:
  • Gas comes out of your wallet
  • Once broadcast, the trade lands with no further API interaction
  • The payload encodes the quoted terms exactly - send it untouched

​
API Submit (executionMode: apiSubmit, native settlement)

Here TetraFi is the one putting settlement on-chain. Your side signs the quote’s EIP-712 escrow-v0 payload, POSTs it to the orders endpoint, and is done - no transaction ever leaves the user’s wallet. The loop: quote → preflight → sign the EIP-712 order → POST /orders → follow via GET /orders/{id} or WebSocket Fits: consumer surfaces - wallets and super-apps - where gas and RPC endpoints have no place in the user experience. What defines it:
  • On-chain submission is TetraFi’s job
  • Funds can only ever move on the signed order’s terms, along the escrow’s delivery-or-refund path
  • Your side owes one EIP-712 signature plus the order POST (send an Idempotency-Key header)

​
Side by Side

​
How Each Product Applies Them

The two modes exist on both products, but each product puts them to work differently:

​
RFQ API

RFQ quotes are firm with no last look - every returned quote is a cryptographically signed, executable commitment, and settlement runs through the escrow’s delivery-or-refund guarantee. A quote that cannot deliver refunds your escrowed funds instead of leaving you stuck. Handle the typed rejection classes on submission (expiry, integrity, eligibility) rather than mid-settlement failures. See the RFQ Order Submission guide for the full RFQ signing and submission flow.

​
Router API

Execution mode varies per candidate: native TetraFi settlement candidates use apiSubmit, while candidates settling through external venues or bridges use walletBroadcast. Always read executionMode and the preflight nextActions from the candidate you selected rather than assuming a mode. The Router API Quickstart walks both paths in runnable code.