> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Settlement vs Orchestration

> Eco fulfills intents in two modes, solver settlement (capital fronted) or orchestration (user funds routed through underlying infrastructure at gas cost). Same Portal, same vaults, same API.

Eco fulfills intents in two fundamentally different ways using the same contracts:

| Mode              | What happens                                                                                | Capital required | Speed                                    |
| ----------------- | ------------------------------------------------------------------------------------------- | ---------------- | ---------------------------------------- |
| **Settlement**    | A solver fronts inventory and delivers the user's outcome                                   | Solver capital   | Fastest, depends on solver               |
| **Orchestration** | The user's vaulted funds move through underlying infrastructure within a single transaction | Gas only         | Bounded by underlying messaging finality |

Most intent systems only do settlement. Eco does both, and the choice is automatic.

## Settlement (the default)

A solver acts as counterparty. They observe the intent, decide it's profitable, and front their own capital on the destination chain to deliver the user's requested asset. Once they deliver, a [prover](/concepts/provers) carries proof back to the source, and the solver withdraws the reward.

This is how most intent systems work, and it's what produces the best execution under normal conditions because solvers compete on price.

## Orchestration

When no solver is willing to settle (e.g. no pricing advantage, or no solver online for that pair), Eco can fulfill the intent **without a solver** by routing the user's own vaulted funds through the underlying infrastructure inside a single atomic transaction.

This is enabled by the [Local Prover](/routes/architecture/provers/local) and its `flashFulfill` operation, a flash-loan-style operation that uses the vault's contents as the source of liquidity for fulfillment, with no cross-chain message required.

**The vault model is what makes this possible.** Because funds sit in self-custodied, deterministic vaults, the system can route them through underlying infrastructure without ever taking custody.

## The fallback chain

```
┌─────────────────────────────────────────────────────────────┐
│ Tier 1: Solver available, better pricing → Settlement       │
│ Tier 2: Solver available, no pricing edge  → Orchestration  │
│ Tier 3: No solver available                → Self-solve     │
└─────────────────────────────────────────────────────────────┘
```

Transitions between tiers are transparent to the caller. The integration code is identical.

## Why this matters

**System availability equals chain availability**, not solver availability. If solvers go offline, intents still execute. If a solver outbids you, you still get the better price. The dual-mode design eliminates a common failure case in single-mode intent systems: stuck intents with no solver to fulfill them.

It also gives institutions a predictable bound: the worst-case fulfillment time is bounded by underlying chain finality, not by an opaque offchain market.