Settlement vs Orchestration

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.

Mode	What happens	Capital required	Speed
Settlement	A solver fronts inventory and delivers the requested outcome	Solver capital	Fastest, depends on solver
Orchestration	The user’s vaulted funds route through underlying rails inside one transaction	Gas only	Bounded 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.

Overview Portal Contract

⌘I

Routes

Capabilities

Integrate

Architecture

Primitives

Settlement vs Orchestration

What this means for your integration

Why this matters for SLAs

​What this means for your integration

​Why this matters for SLAs

What this means for your integration

Why this matters for SLAs