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

# Execution Modes

> Choose between API-submitted and self-broadcast settlement across TetraFi's APIs.

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

|                  | Wallet broadcast          | API submit                                       |
| ---------------- | ------------------------- | ------------------------------------------------ |
| `executionMode`  | `walletBroadcast`         | `apiSubmit`                                      |
| Transaction path | Your wallet, your RPC     | TetraFi lands it on-chain                        |
| Gas              | On the taker              | Invisible to the user                            |
| Funding          | Straight from your wallet | Escrow lock (Permit2 / EIP-3009 / resource lock) |
| What you sign    | An ordinary transaction   | The EIP-712 `escrow-v0` order                    |

## 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](/rfq-api/guides/gasless-execution) 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](/router-api/quickstart) walks both paths in runnable code.