Skip to main content
Routes can fulfill an intent in two modes using the same contracts and the same API. Most intent systems only do settlement; Routes does both.
ModeWhat happensCapital requiredSpeed
SettlementA solver fronts inventory and delivers the requested outcomeSolver capitalFastest, depends on solver
OrchestrationThe user’s vaulted funds route through underlying rails inside one transactionGas onlyBounded by underlying messaging finality
For the conceptual frame, see Settlement vs Orchestration in Concepts.

​
What this means for your integration

You don’t choose the mode. The system picks automatically: 
Tier 1: Solver available, better pricing → Settlement
Tier 2: Solver available, no pricing edge  → Orchestration
Tier 3: No solver available                → Self-solve via Local prover
Your code is identical in all three cases. Same intent struct, same publishing call, same status polling. The user sees one outcome.

​
Why this matters for SLAs

If you’re building on Routes for a regulated counterparty, the dual-mode design gives you a bounded worst-case fulfillment time that doesn’t depend on solver liveness. The fallback is the chain itself. This is the design choice that makes “best execution guarantee” a runtime property rather than a marketing claim.

Local Prover

The contract that enables flashFulfill.

Crowd Liquidity

How solvers get just-in-time capital for tier 1.