An intent is a signed declaration of a desired outcome on a destination chain. Instead of specifying a route (“call this contract, then this one”), the user specifies the result (“I want 1000 USDT on Base in exchange for 1000 USDC on Optimism”). Solvers compete to deliver the result; provers verify it happened.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.
Anatomy of an intent
An intent has two parts:| Part | Holds | Lives where |
|---|---|---|
| Route | What to execute on the destination chain (token transfer, contract call, deadline) | Read by the solver on the destination |
| Reward | What the solver gets paid on the source chain when execution is proven | Locked in a Vault on the source |
keccak256(destination, routeHash, rewardHash) — a deterministic identifier that both chains agree on without ever transmitting the full intent.
The intent lifecycle
- Publish + fund. The user (or a relayer) publishes the intent and transfers the reward tokens to a deterministic vault address. Funding can happen before publishing — the vault address is CREATE2-derived from the intent hash.
- Fulfill. A solver executes the route on the destination chain, recording the fulfillment in the destination Portal.
- Prove. A prover (chosen by the user) carries proof of fulfillment back to the source chain.
- Settle. The source-chain Portal verifies the proof and releases the reward from the vault to the solver.
- Refund (if no fulfillment by deadline). A permissionless refund service returns the reward to the user.
Why intents (vs. transactions)
Transactions specify a path. Intents specify an outcome. The difference matters when the optimal path is unknown at signing time, or when the path crosses chains that don’t share execution.| Property | Transaction | Intent |
|---|---|---|
| Specifies | Exact contract calls | Desired outcome |
| Best path chosen | At signing time | At fulfillment time, by competing solvers |
| Cross-chain | Manual coordination required | Atomic with cryptographic proof |
| Failure mode | Partial state, manual recovery | Atomic refund, no partial states |
Read next
- Solvers — who fulfills intents and how they get paid
- Provers — how settlement proof crosses chains
- Vaults & resource locks — how funds stay non-custodial
- Settlement vs Orchestration — the dual-mode execution model