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

<Frame>
  <img src="https://mintcdn.com/ecoinc/Uuxc9hcexOY41g7k/images/routes/diagrams/prover-confirms-fulfillment.jpg?fit=max&auto=format&n=Uuxc9hcexOY41g7k&q=85&s=a142e3c95791fdb83cdb1588ccd7adda" alt="Sequence of how the prover confirms fulfillment and unlocks the solver reward: fulfill, emit fulfillment, dispatch proof, withdraw, verify proof, release reward." width="3200" height="1800" data-path="images/routes/diagrams/prover-confirms-fulfillment.jpg" />
</Frame>

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.