Skip to main contentSkip to FAQSkip to contact

TetraFi is a non-custodial settlement protocol for institutional stablecoin OTC trading. This page explains the complete system architecture - from RFQ broadcast to WORM audit trail.

What TetraFi is:

  • A non-custodial settlement protocol for institutional stablecoin OTC
  • A compliance-first platform with on-chain attestation
  • A best-price-wins marketplace using sealed RFQ auctions
  • An atomic settlement layer with DvP guarantees

What TetraFi is not:

  • Not an exchange (no order book, no custody)
  • Not a custodian (funds never touch TetraFi's wallets)
  • Not a DEX (not permissionless, compliance-required)
  • Not a lending platform (no yield, no borrowing)

TetraFi is solver-agnostic - the platform supports multiple competing solvers simultaneously. Takers always receive the best available price across all solvers.

The TetraFi protocol executes trades through a 6-stage lifecycle. Each stage is designed for atomicity, compliance, and auditability.

  1. RFQ Broadcast - Taker submits a trade request (pair, size, direction) to all registered solvers. Solvers receive the RFQ simultaneously via WebSocket.
  2. Sealed Auction - Solvers respond with EIP-712 signed sealed bids. Competing solvers cannot see each other's quotes. The auction window is typically 2-5 seconds.
  3. Escrow Lock - Taker accepts the best quote. The smart contract locks funds from both parties in a non-custodial escrow on the origin chain.
  4. Cross-Chain Relay - Fill proof is transmitted to the destination chain via ERC-7683 compact relay. The relay confirms funds are locked before the solver fills.
  5. DvP Settlement - Both legs execute atomically: the solver delivers stablecoins on the destination chain, and the taker's escrow is released. Neither leg can settle without the other.
  6. WORM Audit - An immutable Write-Once Read-Many evidence record is appended to the ledger. This provides a complete, tamper-proof audit trail for regulators.

Every trade is expressed as a typed settlement intent conforming to ERC-7683:

TypeScript
1// ERC-7683 Settlement Intent
2interface SettlementIntent {
3  originChainId: number;       // Chain where taker's funds are locked
4  destinationChainId: number;  // Chain where solver delivers funds
5  originSettler: string;       // InputSettler contract address
6  user: string;                // Taker wallet address
7  nonce: number;               // Replay protection
8  originDeadline: number;      // Escrow lock deadline (UNIX timestamp)
9  fillDeadline: number;        // Fill deadline on destination chain
10  orderId: string;             // Unique order identifier
11  originData: {                // Origin chain asset
12    token: string;             // e.g., "USDC"
13    amount: string;            // In token's native decimals
14  };
15  destinationData: {           // Destination chain asset
16    token: string;             // e.g., "USDT"
17    amount: string;            // Solver's fill amount
18  };
19}
19 linestypescript

All settlement intents conform to ERC-7683, enabling cross-chain DvP across Ethereum, Optimism, Base, and Arbitrum with a single standard.

The ComplianceRegistry is an on-chain smart contract that stores compliance attestations for all participants. Both solvers and takers must have valid entries before trading.

Solidity
1interface IComplianceRegistry {
2    // Check if a participant is approved to trade
3    function isCompliant(address participant) external view returns (bool);
4
5    // Get the full attestation record for a participant
6    function getAttestation(address participant) external view returns (Attestation memory);
7
8    // Record trade evidence to the WORM ledger
9    function recordTradeEvidence(bytes32 tradeId, bytes calldata evidence) external;
10}
10 linessolidity

Every trade generates an immutable audit record using the Write-Once Read-Many (WORM) pattern. Records are appended but never modified or deleted, providing a complete audit trail for regulators.

JSON
1{
2  "tradeId": "0xabc123...",
3  "type": "settlement_complete",
4  "timestamp": 1710000000,
5  "originTxHash": "0x7f3a...",
6  "destinationTxHash": "0x9b2d...",
7  "taker": "0xTakerAddress",
8  "solver": "0xSolverAddress",
9  "amount": "1000000",
10  "ivms101": { "originator": {...}, "beneficiary": {...} }
11}
11 linesjson

TetraFi implements FATF Recommendation 16 (Travel Rule) via the IVMS101 standard. Originator and beneficiary identity data is transmitted between VASPs for all trades above the threshold.

TetraFi is positioned as a Crypto-Asset Service Provider (CASP) under MiCA regulation. All compliance checks are enforced at the smart contract level - non-compliant addresses cannot execute trades.

Both solvers and takers must complete KYB/KYC onboarding and receive a compliance attestation before their first trade. The ComplianceRegistry checks are enforced at smart contract level and cannot be bypassed.

TetraFi supports cross-chain settlement via ERC-7683 settlement intents:

ComponentChainRole
InputSettlerOriginLocks taker's funds in escrow
OutputSettlerDestinationDelivers solver's funds to taker
Compact RelayCross-chainTransmits fill proofs between chains
ComplianceRegistryBothValidates participant compliance
  • Ethereum (mainnet + Sepolia testnet)
  • Optimism (mainnet + Sepolia testnet)
  • Base (mainnet + Goerli testnet)
  • Arbitrum (One mainnet + Sepolia testnet)

Cross-chain pairs are identified by corridor (e.g., ethereum-optimism) and must have solver coverage on both sides.

TetraFi is non-custodial. The protocol operator never holds, controls, or has access to user funds. All fund movements are governed by smart contract logic.

Security PropertyMechanism
DvP AtomicityBoth legs settle or neither does (HTLC)
Non-custodialFunds move directly between counterparties via escrow
Escrow TimeoutAutomatic refund if settlement window expires
Sealed BidsEIP-712 typed signing prevents solver information leakage
On-Chain ComplianceComplianceRegistry checks enforced at contract level

The escrow uses a Hash Time-Locked Contract (HTLC) mechanism:

TypeScript
1// Resource lock lifecycle
2interface ResourceLock {
3  lockId: string;
4  token: string;
5  amount: string;
6  recipient: string;     // Solver's address
7  hashlock: string;      // SHA-256(preimage) - solver must reveal preimage to claim
8  timelock: number;      // Unix timestamp - after which taker can reclaim
9  settled: boolean;      // True after DvP completion
10}
11
12// Settlement: solver reveals preimage to claim funds
13// Timeout: taker reclaims if solver fails to fill within window
13 linestypescript

TetraFi is non-custodial: neither the operator nor any third party can access locked funds. Only the cryptographic conditions (hashlock reveal or timelock expiry) can release funds.