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

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 CCIPCross-Chain Interoperability ProtocolChainlink DON and Risk Management NetworkGeneral cross-chain, wide coverage
PolymerIBC light clientsLight-client proofsTrust-minimized cross-chain
LocalSame-chain flashFulfillTransaction atomicitySame-chain intents, orchestration mode

​
How proving works

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.