Skip to main content
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

ProverSettlement methodSecurity modelBest for
CCTPIssuer attestations via receiveMessageCircle’s attestation serviceUSDC routes, regulated flows
HyperlaneHyperlane ISM validatorsConfigurable security moduleGeneral cross-chain, fast
LayerZeroDVN consensusDecentralized verifier networkWide chain coverage
Chainlink CCIPCCIP messagingChainlink DON and Risk Management NetworkGeneral cross-chain, wide coverage
PolymerIBC light clientsLight-client proofsTrust-minimized
LocalSame-chain atomicityTransaction atomicitySame-chain, orchestration mode

​
How proving works

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.

Per-prover deep dives

Start with CCTP, then the rest of the prover stack.

Settlement vs Orchestration

When the Local prover takes over.