How TetraFi Works

What happens between your request and settlement - and which product to build on.

One Platform, Two Contracts to Buy

A single routing, settlement, and compliance engine underlies everything, built around regulated stablecoins and tokenized real-world assets at institutional size. On top of it, TetraFi sells you one of two distinct trading contracts, depending on what your execution needs:

RFQ - firm liquidity

Your request goes to every eligible solver and LP in the workspace, and each answers with a cryptographically firm, executable quote. Escrowed settlement enforces the terms exactly as quoted: deliver, or refund - a quote can disappoint you only by refunding, never by failing.

Router - aggregated execution

The router fans your request across every eligible execution source - direct DEX liquidity, the RFQ venue, bridges, issuers, and fiat rails - and returns ranked executable candidates with an explicit recommendation. Each candidate states its own firmness, atomicity, settlement guarantee, and fees. From the user’s side it’s one intent and one signature - routing, bridging, and settlement are the solver’s problem, even across chains.

The flow underneath is identical either way - quotes requested, sources compete, a winner gets your signature, the order goes in - and on-chain settlement completes it with custody never leaving your side.

The key difference is the contract you buy:

• RFQ: Only firm solver/LP escrow quotes - a closed source set with a delivery-or-refund guarantee
• Router: Best execution across heterogeneous sources - guarantees stated per candidate, never assumed

A Router trade may well be filled by RFQ liquidity - but the product you called is still Router. Product and execution source are independent: the product defines your guarantees, the source records how it executed.

Infrastructure You Own

Both products run on contracts your institution owns: your workspace gets its own immutable on-chain router - no custody key, no upgrade key, capability upgrades only ever add to an allowlist - while plugging into the shared liquidity and settlement network.

Ownership is also configurability. You decide which venues your router may touch, which LPs and jurisdictions your RFQ requests reach, and how your compliance pipeline is composed - checks added, removed, or layered to fit your regulatory perimeter, per workspace. Why that model is the whole point is the story of Why TetraFi.

More Than a Settlement Engine

Execution is one pillar of the platform; institutions adopt the pieces their flows need:

Pillar	What it electrifies
Settlement engine	Atomic cross-chain execution; spread compression through solver competition - with Multilateral Netting coming to compress it further; depth aggregated from OTC desks, CEXs, DEXs, and regulated LPs
Compliance engine	Automated on-chain and off-chain checks with one policy enforcement and audit trail shared across parties - instead of every party repeating the same manual reviews
Onboarding engine	Verify your entity once into a reusable onboarding pack that streamlines KYB across every counterparty on the network
Unified operations	Flow monitoring, statistics, and a full audit trail - one place to run and evidence your activity

Which Flow, Which Product

Stablecoins and tokenized assets generate more than one kind of flow, and the trade is only one of them. Where each lands:

Flow	Product	Why
Secondary trading in a tokenized asset, at size	RFQ	A firm quote from a desk that actually holds the instrument, settled delivery-versus-payment
Mint or subscription - cash into a tokenized asset	Router	The issuer’s mint capability composes as a leg inside the route
Redemption - tokenized asset back to cash or stables	Router; T+0 Vaults for instant	The primary redemption rail, with vault capital fronting the settlement wait
Stablecoin corridors at payment or treasury size	RFQ, or Router for wider coverage	Competing LP inventory outprices on-chain routing once the ticket grows
Long-tail token swaps	Router	DEX and bridge coverage - reach, not the depth claimed above

That last row is deliberate. The long tail belongs to the Router, served through external sources; depth at size is what the RFQ venue exists for. Which assets fall on which side is set out in Coverage.

Picking Your Product

	RFQ API - Firm Escrow Liquidity	Router API - Aggregated Multi-Source
What you buy	Only firm quotes, each escrow-enforced to deliver or refund	A ranked candidate list, each entry carrying its own stated guarantees
How it settles	Delivery-versus-payment through escrow, custody never with TetraFi	On-chain through the same contract stack, custody never with TetraFi
Reach	The corridors your workspace’s solvers and LPs actively quote	Everything eligible - DEX, bridges, issuers, fiat rails, cross-chain corridors
The catch	Coverage follows the LP roster, not the whole token universe	Guarantees differ candidate to candidate - always read the printed terms

RFQ is your product if:

• Escrow-enforced delivery-or-refund is the guarantee your users depend on
• Your flow concentrates in quoted corridors, at real size
• Settlement predictability outranks maximum coverage

Router is your product if:

• Coverage is king - DEX, bridge, issuer, and fiat sources all in play
• You’d rather compare ranked candidates than accept a single answer
• Speed, price, and trust are per-trade decisions in your pipeline

Run both if:

• Core corridors deserve firm escrow while the long tail rides the router
• No single source outage should ever block an executable trade

Still unsure? Get in touch with our team.