Liquidity Aggregation

For any transfer of meaningful size, the binding constraint is rarely the existence of a route — it is the depth available along it. A path that is topologically possible but cannot absorb the transfer amount without severe slippage is not a useful path. Liquidity aggregation exists to make available depth, not just connectivity, the unit the router reasons about.

Depth is represented by the LiquidityInfo type in @arc-route/types, attached to every GraphEdge. An edge only becomes traversable once it reports available liquidity greater than zero; the default graph builder omits zero-liquidity edges entirely so the search never explores lanes that cannot move value.

Aggregation is more than selecting the single deepest venue. The GraphBuilder records liquidity snapshots keyed by (bridge, chain, token), and the latest snapshot wins when the same key is set twice — so an edge always reflects the most recent depth reported by its bridge. Because the graph is a multigraph, multiple bridges serving the same corridor appear as parallel edges, and findPaths explores each as a distinct candidate. The scorer then sees the full set and can prefer the lane with the best combined cost and depth rather than whichever single venue happens to be largest.

Reliability interacts with depth directly. The default estimator degrades a hop's reliability score as the transfer consumes a larger share of the edge's available liquidity — so a route that would exhaust a thin pool scores worse than its raw cost would suggest. This is why a path can exist topologically and still be ranked behind, or pruned from, the candidate set.