A prover is a contract on the source chain that verifies fulfillment proofs from the destination chain. The Portal accepts any contract that implements theDocumentation Index
Fetch the complete documentation index at: https://eco.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
iProver interface. The user picks a prover per intent — meaning the user picks the security model.
Available provers
| Prover | Settlement method | Security model | Best for |
|---|---|---|---|
| CCTP | Issuer attestations via receiveMessage | Circle’s attestation service | USDC routes, regulated flows |
| Hyperlane | Hyperlane ISM validators | Configurable security module | General cross-chain, fast |
| LayerZero | DVN consensus | Decentralized verifier network | Wide chain coverage |
| Metalayer | Caldera Metalayer | Cross-rollup messaging | Caldera ecosystem |
| Polymer | IBC light clients | Light-client proofs | Trust-minimized |
| Local | Same-chain atomicity | Transaction atomicity | Same-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.
- Caldera-stack. Use Metalayer.
iProver — no protocol-level approval required.
Read next
- Per-prover deep dives — start with CCTP
- Settlement vs Orchestration — when the Local prover takes over