> ## 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.

# Intents

> An intent is a signed declaration of a desired outcome on a destination chain. Solvers compete to fulfill it; provers verify execution.

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](/concepts/solvers) compete to deliver the result; [provers](/concepts/provers) verify it happened.

## 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](/routes/architecture/vault) on the source |

The intent hash is `keccak256(destination, routeHash, rewardHash)`, a deterministic identifier that both chains agree on without ever transmitting the full intent.

## The intent lifecycle

```mermaid theme={null}
sequenceDiagram
    participant User
    participant Portal as Portal (source)
    participant Vault as Vault (source)
    participant Solver
    participant Dest as Destination chain
    participant Prover

    User->>Portal: Publish intent
    User->>Vault: Fund vault (ERC-20 transfer)
    Note over User,Vault: Intent now active
    Solver->>Dest: Fulfill intent
    Dest->>Prover: Generate settlement proof
    Prover->>Portal: Verify fulfillment
    Portal->>Vault: Release reward
    Vault->>Solver: Transfer reward
```

1. **Publish and 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.
2. **Fulfill.** A solver executes the route on the destination chain, recording the fulfillment in the destination Portal.
3. **Prove.** A prover (chosen by the user) carries proof of fulfillment back to the source chain.
4. **Settle.** The source-chain Portal verifies the proof and releases the reward from the vault to the solver.
5. **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          |