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

# Routes architecture

> How the Routes contracts fit together, Portal, Vault, Executor, ERC-7683, and the modular Prover stack.

The Routes protocol is a small set of contracts deployed on every supported chain, plus a modular settlement layer the user picks at intent-creation time.

## The contracts

| Contract                                  | Role                                                                       | Per-intent?              |
| ----------------------------------------- | -------------------------------------------------------------------------- | ------------------------ |
| [Portal](/routes/architecture/portal)     | Single entry point: publish, fund, fulfill, prove, withdraw, refund        | One per chain            |
| [Vault](/routes/architecture/vault)       | Per-intent escrow: holds reward tokens until proven fulfillment            | One per intent (CREATE2) |
| [Executor](/routes/architecture/executor) | Stateless contract that runs user-specified destination calls              | One per Portal           |
| [ERC-7683](/routes/architecture/erc-7683) | Standardized cross-chain order interface (origin and destination settlers) | Built into Portal        |

## The modular settlement layer

The Portal accepts any contract that implements the `IProver` interface. Six provers ship today; the user picks one per intent.

| Prover                                              | Settlement method                     | Best for                           |
| --------------------------------------------------- | ------------------------------------- | ---------------------------------- |
| [CCTP](/routes/architecture/provers/cctp)           | Issuer attestations                   | USDC routes, regulated flows       |
| [Hyperlane](/routes/architecture/provers/hyperlane) | Hyperlane ISM                         | General-purpose, fast              |
| [LayerZero](/routes/architecture/provers/layerzero) | DVN consensus                         | Wide chain coverage                |
| Chainlink CCIP                                      | Cross-Chain Interoperability Protocol | General cross-chain, wide coverage |
| [Polymer](/routes/architecture/provers/polymer)     | IBC light clients                     | Trust-minimized                    |
| [Local](/routes/architecture/provers/local)         | Same-chain `flashFulfill`             | Same-chain, orchestration mode     |

## Information flow

```mermaid theme={null}
sequenceDiagram
    participant User
    participant SrcPortal as Source Portal
    participant Vault
    participant Solver
    participant DestPortal as Destination Portal
    participant Executor
    participant DestProver as Destination Prover
    participant SrcProver as Source Prover

    User->>SrcPortal: publishAndFund(intent)
    SrcPortal->>Vault: lock reward
    Solver->>DestPortal: fulfill(intent)
    DestPortal->>Executor: execute(route.calls)
    DestPortal->>DestProver: emit proof
    DestProver-->>SrcProver: dispatch proof
    Solver->>SrcPortal: withdraw(intent)
    SrcPortal->>SrcProver: verify proof
    SrcPortal->>Vault: release reward
    Vault->>Solver: transfer reward
```

## Design principles

**Non-upgradable.** The Portal has no proxy, no admin keys, no upgrade path. Audited once, valid forever.

**Stateless executor.** The Executor has no persistent storage. Each intent's calls run in isolation. A malicious call cannot corrupt Portal state.

**Per-intent vaults.** Funding is a vanilla ERC-20 transfer to a CREATE2 address. Cold wallets, hardware devices, multisigs, exchanges, PSPs all participate without changes.

**Modular settlement.** New messaging protocols plug in via `IProver` without changes to Portal, vaults, or solver tooling.

**Cross-VM.** EVM, SVM, and TVM are first-class. Address fields use `bytes32` to hold any chain's address format.