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 |
| Chainlink CCIP | CCIP messaging | Chainlink DON and Risk Management Network | General cross-chain, wide coverage |
| 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.
- Chainlink-secured. Use Chainlink CCIP, settlement carried by Chainlink’s decentralized oracle and Risk Management networks.
IProver, no protocol-level approval required.