Section 02 / 03

Platform layers and the settlement hot path

Every settlement runs through a fixed twelve-step pipeline with a sub-500ms budget, bounded by security invariants that hold whether the trade is profitable or not.

Top-level architecture

Six layers, four business domains. Presentation and edge surfaces degrade independently of the core so a central outage never blinds active loads.

┌───────────────────────────────────────────────────────────────────────┐
│                  ESCROW FACTORY — PLATFORM LAYERS                     │
├───────────────────────────────────────────────────────────────────────┤
│ PRESENTATION     │ Web UI (Sponsor/Investor/Admin) · Mobile Driver    │
│                  │ Edge Dispatch Agent · Command Center Dashboard     │
├───────────────────────────────────────────────────────────────────────┤
│ API GATEWAY      │ REST + WebSocket · HMAC/Ed25519 · Rate limit · WAF │
├───────────────────────────────────────────────────────────────────────┤
│ CORE SERVICES    │ Identity & Authority · Policy Engine · Audit Ledger│
│                  │ Evidence Service · Workflow & Escalation           │
├───────────────────────────────────────────────────────────────────────┤
│ BUSINESS DOMAINS │ Core Escrow Engine   │ DIBS Freight OS             │
│                  │ SPV Factory          │ RubyVox Voice Gateway       │
├───────────────────────────────────────────────────────────────────────┤
│ DATA & INFRA     │ PostgreSQL (RLS) · Redis · Object Storage          │
│                  │ pgvector (RAG) · Durable Queue · Key Vault         │
├───────────────────────────────────────────────────────────────────────┤
│ INTEGRATIONS     │ EVM (Arbitrum/zkSync/Base) · Chainlink/Pyth        │
│                  │ Axelar/LayerZero · Telnyx · RubyVox · Telematics   │
└───────────────────────────────────────────────────────────────────────┘

Hot path — end to end in ≤ 500ms

The pipeline is deterministic and instrumented per stage. Relay acceptance is not treated as success; only inclusion plus two confirmations closes a cycle.

Step	Component	Implementation
1	Decode chain event	Binary decoders for EscrowCreated, Funded, Released, Disputed
2	Normalise state	Immutable versioned snapshot (monotonic block version)
3	Update graph	Lock-free adjacency list; nodes = wallets/contracts, edges = obligations
4	Generate cycles	Bounded DFS (≤ 4 hops, ≤ 500 candidates) to net obligations
5	Quote routes	Fixed-point arithmetic, no floats; on-chain oracles for FX
6	Risk / profit filter	Reject if profit < gas × 1.2 or slippage > 0.5%
7	Concurrent simulate	10–20 parallel simulations on local forked nodes (Geth/Arbitrum)
8	Calldata construction	Multicall batching of escrow releases
9	Reserve nonce	Atomic counter (Redis), global per signer
10	Build bundle	MEV-relay bundle: settlement tx plus optional backrun
11	Submit	Private relay (Flashbots/EDEN) with target block, max fee, bundle ID
12	Track & reconcile	Async inclusion plus 2 confirmations; relay acceptance ≠ success

Security invariants

Execution

All external targets allowlisted.
Minimum output and minimum realised profit enforced on-chain.
Flash liquidity fully repaid within the same transaction.
No arbitrary token approvals derived from route data.
Emergency pause prevents new execution.

Keys and telemetry

Nonce allocation atomically reserved per signer.
Secrets never enter logs, traces, or crash dumps.
Isolated signer (HSM/KMS); the hot-path process never holds an unrestricted private key.
Every decision writes a hash-chained audit entry.

Settlement targets

Chains, oracles and bridges the engine settles across.

Arbitrum
zkSync
Base
5-second finality

Chainlink
Pyth
Axelar
LayerZero