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

# Provers

> Provers are the modular settlement layer. They verify on the source chain that an intent was fulfilled on the destination. Six provers ship today; users pick per intent.

A **prover** is a contract on the source chain that verifies fulfillment proofs from the destination chain. The Portal accepts any contract that implements the `IProver` interface. The user picks a prover per intent, meaning the user picks the security model.

## Available provers

| Prover                                              | Settlement method                        | Security model                            | Best for                           |
| --------------------------------------------------- | ---------------------------------------- | ----------------------------------------- | ---------------------------------- |
| [CCTP](/routes/architecture/provers/cctp)           | Issuer attestations via `receiveMessage` | Circle's attestation service              | USDC routes, regulated flows       |
| [Hyperlane](/routes/architecture/provers/hyperlane) | Hyperlane ISM validators                 | Configurable security module              | General cross-chain, fast          |
| [LayerZero](/routes/architecture/provers/layerzero) | DVN consensus                            | Decentralized verifier network            | Wide chain coverage                |
| Chainlink CCIP                                      | CCIP messaging                           | Chainlink DON and Risk Management Network | General cross-chain, wide coverage |
| [Polymer](/routes/architecture/provers/polymer)     | IBC light clients                        | Light-client proofs                       | Trust-minimized                    |
| [Local](/routes/architecture/provers/local)         | Same-chain atomicity                     | Transaction atomicity                     | Same-chain, orchestration mode     |

## How proving works

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

    Solver->>DestPortal: fulfill(intent)
    DestPortal->>DestProver: emit fulfillment
    DestProver-->>SrcProver: dispatch proof (via underlying messaging)
    Solver->>SrcPortal: withdraw(intent)
    SrcPortal->>SrcProver: verify proof
    SrcProver-->>SrcPortal: ok
    SrcPortal->>Vault: release reward
```

The dispatch step (proof crossing chains) is what differentiates each prover. The Portal interface is identical regardless of which prover the user chose.

## Picking a prover

A few rules of thumb:

* **USDC routes.** Use CCTP, same security as a native CCTP transfer, no AMB.
* **Same-chain intents.** Use Local, instant, atomic, no cross-chain message.
* **Wide coverage.** Use Hyperlane or LayerZero, many chains, many integrations.
* **Trust-minimized.** Use Polymer, IBC light clients, no validator set to trust.
* **Chainlink-secured.** Use Chainlink CCIP, settlement carried by Chainlink's decentralized oracle and Risk Management networks.

Provers can also be added by anyone implementing `IProver`, no protocol-level approval required.