Routing
Routing
The bridge integrations whose mechanisms routing selects among.
Bridges are the mechanisms that move value between networks, and Arc Route treats them as inputs to routing rather than as destinations in themselves. Each supported bridge is identified by a BridgeId in @arc-route/types. The current set includes Hyperlane, LayerZero, deBridge, Wormhole, and Circle CCTP — the last being the canonical burn-and-mint path for USDC.
Each bridge contributes its lanes to the routing graph through the GraphBuilder: a lane is a one-way connection between a (fromChain, fromToken) pair and a (toChain, toToken) pair. An edge is only traversable once liquidity is assigned to it, and the router does not privilege any bridge by default — each is evaluated on the same cost, latency, depth, and reliability dimensions as every other candidate edge.
A route may use a single bridge for a straightforward corridor, or compose multiple bridges where that yields a better-scored path. The decision is made by the RouteScorer against live conditions, not by static preference. This is what allows the system to improve as new bridges are integrated or as existing bridges' depth changes — the router simply has more, or better, edges to choose among.
At execution time each hop is handed to a BridgeAdapter in @arc-route/execution that wraps the bridge's own SDK and translates an Arc Route hop into bridge-specific calls. Adding a bridge means adding lanes to the graph and an adapter for execution; the routing and scoring layers are unchanged.