Intent Netting & Batch Auction#

Phase 2 - fully designed, not yet in production.

Netting Offsetting flows cancel out - zero solver capital needed
UCCP Uniform pricing - every order in a batch pays the same bps
Efficiency Up to 95% gas savings on netted settlements

Batch Pipeline#

8-Stage Batch Pipeline

Actor

Engine

Contract

Network

POST /v1/quotes → validates, assigns auction ID
Order Book accumulates → 2-5s batch window per corridor
Netting Pre-Processor → detects CoW, groups batches, finds rings
Solver Broadcast → batched bundle via WebSocket
CIP-67 Evaluator → reference outcome → fairness filter → surplus max
Execution → batchClaim() for netted orders

CIP-67 Fair Winner Selection#

Step	Name	Rule
1	Reference	Best standalone bid per order - the baseline
2	Fairness	Reject any batch bid where ANY corridor gets less surplus than reference
3	Maximize	From surviving bids, select combination maximizing total surplus

Surplus (per order, in bps of notional): (output_received − input_paid) / limit_price × 10000

Batch score (per corridor): Σ (surplus + fee) - aggregated across orders

UCCP (uniform clearing price, bps): (input − output) / input × 10000 - identical for all orders in the batch

All three values are expressed in bps of notional - positive surplus means price improvement vs. the taker's limit. A batch is only selected if every order's surplus ≥ its reference (standalone) surplus (Fairness rule).

Fairness Guarantee Batched bids can ONLY win if every order gets ≥ its standalone best price. No order subsidizes another.

Matching Engine: Four Ways to Match Orders#

The aggregator detects obvious matches (Simple & Batching) automatically. Solvers optimize complex routing and leverage private liquidity for Intermediate and Ring matches.

Matching Mode Comparison

Feature	Simple Match	Batching Match	Intermediate Match	Ring Match
Mechanics4 features
Tag	P2P	Batch	Route	Cycle
Handled by	Aggregator	Aggregator	Solvers	Solvers
How	Direct P2P match between two opposing orders	Multiple orders on same corridor combined for gas savings	3+ intents routed through a shared intermediate token	Circular A→B→C→A cycle where each sell is the next buy
Settlement	TEE atomic swap	Single batchClaim()	Solver fills, intermediate cancels	TEE-linked revelation
Properties4 features
Solver capital
Oracle needed
Gas savings	~95%	~80%	~60%	~95%
Complexity	Low	Low	Medium	High

Examples per Mode#

The comparison above summarizes ownership, capital, oracle, and gas tradeoffs. The tabs below walk through one concrete example for each mode:

P2P

Direct P2P match between two opposing orders. A sells USDC→ETH while B sells ETH→USDC. The aggregator detects this mirror match and settles both orders with zero external liquidity. No DEX routing, no slippage, no bridge fees.

Simple Match

A: USDC → ETH
B: ETH → USDC
──────────────
Direct P2P Match

4 linestext

Example: Alice: Base USDC→OP USDT, Bob: OP USDT→Base USDC.

Delivery Roadmap#

Phase	Milestone	Scope
2a	Simple & Batch Netting	CoW detection, UCCP, `batchClaim()`
2b	Intermediate & Ring	Multi-hop, cycle graphs, TEE revelation
3	Persistent Order Book	Cross-chain CLOB, full combinatorial matching