Skip to main content
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 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 includes the following implementations. This is a source inventory, not a list of active deployments or API-selectable options. CCTP can appear as a token-transport leg in an API route. That does not make CCTP a Routes prover; see Intent types.

​
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 to locate route-specific deployments, or Become a solver for the operating workflow.