Settlement & Smart Contracts

TetraFi’s on-chain architecture - your own immutable router, shared venue modules, and escrow settlement.

Every workspace on TetraFi gets its own on-chain router - an immutable contract deployed for you, owned by you. Trades enter through your router, flow through shared immutable venue modules, and settle delivery-versus-payment through a compliance-gated escrow: the counterparty delivers, or your funds are refunded. TetraFi holds no custody key and no upgrade key - anywhere in the stack.

The Contract Stack

	Role
Workspace router	Your institution’s entry point - one immutable contract per workspace, deployed automatically at provisioning. Pulls trade inputs transiently, meters them into modules, and forwards fills to the end recipient.
Venue modules	Shared immutable modules the router dispatches to - escrow opening, swaps, bridge legs, FX continuations. New capabilities are added to the allowlist; existing modules can never be swapped out from under you.
Compliance escrow	The settlement entry (ComplianceSettlerEscrow). Locks inputs under the signed order, enforces the compliance policy at deposit time, releases on proof of delivery, refunds on expiry. Its output-side twin gates fills on the destination chain.
Settlement oracle	Attests destination-chain delivery back to the origin escrow so funds release only against proof.

Never send funds directly to a settlement address. Value moves only through a signed order’s flow - the quote response and preflight nextActions tell you exactly what to sign and where funds travel.

Your Deployment, Your Addresses

Your workspace router’s address is deterministic and predicted before deployment - it is provisioned automatically when your workspace is created, and it belongs to your workspace permanently. Module and escrow addresses vary by chain and version. Never hardcode any of them: the addresses carried in quote responses and preflight plans are authoritative for every trade. See Supported Chains for network coverage.

Settlement Lifecycle

Every quote arrives carrying its own EIP-712 escrow-v0 payload - the trade’s complete terms (which assets, how much, who receives, until when) in signable form. Your signature authorizes it; your router locks the input into escrow on exactly those terms; and only a delivery proof can move the funds onward to the counterparty.

Should the expiry pass without a delivery proof, the escrow hands your input straight back - via a refund path that is permissionless and unpausable by anyone. There is never a half-settled state, never a stranded balance, never custody.

Funding Locks

How your input funds enter escrow depends on the lock type available for the corridor and token:

Lock type	Description	Requires
Permit2	The signature itself carries the pull authorization - no extra transaction	One-time Permit2 approval
EIP-3009	transferWithAuthorization for tokens that support it (e.g. USDC)	No prior approval
Resource lock	Pre-positioned balance drawn per order	Prior deposit

The preflight nextActions select the lock for you - see Token Approvals for the check-and-approve flow.

Signed Payloads

Each quote carries its complete typed payload - domain, types, and message - in the order field:

Order type	What you sign
escrow-v0	The StandardOrder typed data returned verbatim in quote.order

Sign exactly what the quote returns. The integrityChecksum binds your submission to the quote you were shown, so any mutation of the payload is rejected at submission.

See the RFQ Order Submission guide and the Router API quickstart for the full signing flows.