Collaborative solving

Collaborative solving means one order can be filled from many sources of liquidity at once, so no single counterparty has to supply all of it. Solvers compose a fill from whatever they can reach: inventory, other venues and, where the hub supports it, other orders in the book. The hub settles the result atomically.

Three mechanisms make it work.

1. Solutions are graphs

A solver submits a solution, a graph that says where each input intent’s escrow goes and which output satisfies each intent. The hub checks the graph before applying it:

• every input intent is open and within its deadline,
• escrow is conserved: for every input, what is spent plus what remains equals what was escrowed,
• every intent receives at least its rate, on whatever fraction is filled.

If any check fails, the whole solution reverts. Settlement is every leg or none, so a solver can combine many legs without the risk of executing half of them.

2. Orders can fill each other

The simplest graph has two orders that want each other’s tokens: one gives USDT for USDC, the other gives USDC for USDT. Each order’s escrow pays the other’s output, and no solver inventory is needed. A cycle of three or more orders can settle the same way.

When the legs don’t balance, the solver adds a just-in-time intent of its own to cover the difference, published and consumed in the same transaction. A solver’s standing liquidity is just another node in the graph.

3. Orders fill in parts

An order can be filled by several solutions. A solver that fills part of it leaves a child intent with the same rate and deadline for the next fill, from the same solver or another one. See Intents and orders.

flowchart LR
    O["Order: 10,000 USDC on Arbitrum<br/>for USDT on Ethereum, at rate r"]
    O -- "fill 6,000 at r" --> F1["Solution 1<br/>solver inventory, just-in-time"]
    O -- "remainder 4,000" --> C["child intent<br/>same rate r, same deadline"]
    C -- "fill 4,000 at r" --> F2["Solution 2<br/>sourced on another venue"]
    F1 --> S["Settlement<br/>10,000 filled at r, paid out once"]
    F2 --> S

What it means for your users

No single solver needs inventory for the whole order, so more orders fill completely: each part can come from wherever liquidity is available at that moment. However the order is split, every filled unit settles at the quoted rate, and the user never sees a worse price on the second half. The user receives one payout, and one refund for anything unfilled, however many fills it took.

Live and planned

The API’s orders are filled with just-in-time intents and partial fills, so an order can be completed across several solutions. The hub also supports netting them against each other, but that is not how they are filled today.