Skip to main content
Every IBC message is verified on chain before the receiving ledger acts on it. What varies is what the verification checks against. IBC’s verification layer is pluggable, and two models are available. The relayer is the same in both models, and it is untrusted in both: it shuttles packets and proofs between the ledgers, and it cannot forge, alter, or censor a message that verification would reject.

​
Consensus light clients

A consensus light client verifies messages from the counterparty ledger directly, by validating its block headers and validator signatures. Each ledger runs a light client of the other. Verification checks a message against the counterparty’s own consensus: headers signed by its validator set, and Merkle proofs extracted from those headers. This means no party outside the two ledgers is trusted, because the proof is the counterparty chain’s own consensus. The infrastructure requirement is a relayer, and the counterparty data required is headers and IBC messages.

​
First-party attestor oracle

An attestor oracle verifies messages via signatures from signers the institution trusts, with the keys held in the institution’s own hardware security modules. Attestors observe the source ledger and sign messages. The receiving ledger runs an attestor light client that verifies those signatures. The institution reuses the private key infrastructure it already trusts: the same HSMs, the same key ceremony, the same controls. This is the model for a counterparty whose consensus cannot be verified directly, and for institutions that want verification anchored to their own key infrastructure rather than to a counterparty’s validator set. The infrastructure requirement is signers and a relayer, and the counterparty data required is signatures and IBC messages.
The attestor set is the trust anchor of this model, so its size is a security decision. A single attestor is a single point of trust. Production deployments should use a multiple-signer or threshold attestation scheme, sized with us during deployment scoping.

​
Choosing between them

Neither model introduces a third-party oracle network. The choice is between trusting the counterparty’s consensus and trusting keys the institution itself holds.

​
Who runs the infrastructure

Two deployment models are offered for the attestors and relayers. Cosmos can run them as a managed service, or the bank runs them on premises alongside its own infrastructure. The choice is made at deployment and does not change the verification model.