IProver interface. Eco ships six proving paths today.
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 |
| Chainlink CCIP | Cross-Chain Interoperability Protocol | Chainlink DON and Risk Management Network | General cross-chain, wide coverage |
| Polymer | IBC light clients | Light-client proofs | Trust-minimized cross-chain |
| Local | Same-chain flashFulfill | Transaction atomicity | Same-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.Read next
Per-prover deep dives
Start with CCTP, then the rest of the prover stack.
Settlement vs Orchestration
The dual-mode execution model.