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

Wallet Broadcast (executionMode: walletBroadcast)

Preflight hands you the prepared payload (nextActions, actor: userWallet) and your RPC does the rest, with no further API interaction. Send the payload untouched. The loop: quote → preflight → sign and broadcast the prepared payload Fits: solvers, aggregators, liquidators, and any candidate settling through an external venue or bridge.

API Submit (executionMode: apiSubmit, native settlement)

TetraFi puts settlement on-chain. You sign the quote’s EIP-712 escrow-v0 payload and POST it with an Idempotency-Key header; no transaction leaves the user’s wallet, and funds move only on the signed order’s terms along the escrow’s delivery-or-refund path. The loop: quote → preflight → sign the EIP-712 order → POST /orders → follow via GET /orders/{id} or WebSocket Fits: wallets and super-apps, where gas and RPC endpoints have no place in the user experience.

Delegated Signing (rolling out)

With an embedded wallet, a session-signer grant, or an organisation wallet, call preflight with a delegated execution mode naming the wallet; it returns the exact authorization to approve, with typed data to inspect, and TetraFi coordinates signing and submission. A blocked or stale preflight never authorizes execution, and the API key alone never signs (Wallets & Signing). The loop: quote → preflight → approve the prepared authorization → POST /orders

Side by Side

How Each Product Applies Them

RFQ API: quotes are firm with no last look, settled through the escrow’s delivery-or-refund guarantee. Handle the typed rejection classes on submission (expiry, integrity, eligibility) rather than mid-settlement failures. Flow: RFQ Order Submission guide. Router API: the mode varies per candidate - native settlement uses apiSubmit, external venues and bridges use walletBroadcast. Flow: Router API Quickstart.