Skip to main content

Documentation Index

Fetch the complete documentation index at: https://eco.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Eco fulfills intents in two fundamentally different ways using the same contracts:
ModeWhat happensCapital requiredSpeed
SettlementA solver fronts inventory and delivers the user’s outcomeSolver capitalFastest, depends on solver
OrchestrationThe user’s vaulted funds move through underlying infrastructure within a single transactionGas onlyBounded 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 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 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 off-chain market.
  • Local Prover — the contract that enables flashFulfill
  • Solvers — how the solver market works
  • Why Eco — the full design philosophy