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

> A prover carries proof of fulfillment from the destination chain back to the source. The security model of an intent is the security model of its prover.

A **prover** is a contract on the source chain that verifies an intent was fulfilled on the destination chain. The user picks the prover at intent-creation time, which means the user picks their own settlement security model.

The Portal accepts any contract that implements the `IProver` interface. Eco ships six proving paths today.

## 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                                      | Cross-Chain Interoperability Protocol    | Chainlink DON and Risk Management Network | General cross-chain, wide coverage     |
| [Polymer](/routes/architecture/provers/polymer)     | IBC light clients                        | Light-client proofs                       | Trust-minimized cross-chain            |
| [Local](/routes/architecture/provers/local)         | Same-chain `flashFulfill`                | Transaction atomicity                     | Same-chain intents, orchestration mode |

## How proving works

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

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

Step 4 is what differentiates provers. Each prover uses a different cross-chain mechanism: CCTP attestations, Hyperlane ISM verification, LayerZero DVN consensus, Polymer IBC, and so on. The source Portal interface is identical.

## Why modularity matters

Different intents have different security needs. A retail USDC transfer can use CCTP. A regulated institutional rebalance might prefer Polymer's light-client proofs. A same-chain RFQ uses the Local prover for instant atomicity. The user picks per intent.

This also future-proofs the system: a new messaging protocol can plug in without changes to the Portal, the vault model, or solver tooling.