Skip to main content

Documentation Index

Fetch the complete documentation index at: https://eco.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

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
MetalayerCaldera MetalayerCross-rollup messagingCaldera ecosystem
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, etc. — but 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.