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

> The proof interface, source implementations, and configuration required for Routes settlement.

The source-chain Portal reads `reward.prover` to determine whether an intent has a proven claimant on the intended destination. That makes the prover part of the intent's trust model.

## Interface

The [IProver interface](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/interfaces/IProver.sol) includes proof lookup, proving, and challenge operations. `provenIntents` returns a claimant and destination chain ID. The Portal uses those fields when processing withdrawal and refunds.

Implementing the interface alone does not establish that a prover is trustworthy or correctly configured. Check the implementation, trusted remote counterparts, and supported chains.

## Implementations

The [Routes 2.12.0 source](https://github.com/eco/eco-routes/tree/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/prover) includes the following implementations. This is a source inventory, not a list of active deployments or API-selectable options.

| Implementation | Role |
| - | - |
| `HyperProver` | Hyperlane message adapter |
| `LayerZeroProver` | LayerZero message adapter |
| `CCIPProver` | Chainlink CCIP message adapter |
| `MetaProver` | Metalayer message adapter |
| `PolymerProver` | Polymer proof verification |
| `LocalProver` | Same-chain fulfillment lookup and flash fulfillment |
| `AggregatorProver` | Read proof results from an immutable set of member provers |

CCTP can appear as a token-transport leg in an API route. That does not make CCTP a Routes prover; see [Intent types](/resources/intent-types#cctp-fulfillment).

## Proving sequence

For a messaging prover:

1. Fulfill the intent on the destination Portal.
2. Dispatch the claimant and intent hash through the destination-side prover.
3. Deliver and validate the message on the source-side prover.
4. Withdraw the reward through the source Portal.

The Local prover reads the same-chain Portal directly. Polymer and aggregator integrations have different submission and lookup behavior, so do not assume every implementation follows the message sequence.

## Configuration

Use the selected prover's source-chain domain mapping and fee requirements. A messaging domain may differ from the chain ID.

When `reward.prover` is an aggregator, submit proof through a concrete member. The aggregator reads member proofs and is not a message recipient. Its acceptance of any member's proof makes member selection part of the security model.

## Next steps

Read [Contract addresses](/resources/contract-addresses) to locate route-specific deployments, or [Become a solver](/cookbook/become-a-solver) for the operating workflow.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.