> ## Documentation Index
> Fetch the complete documentation index at: https://cts-docs.cosmos.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Verification Models

> The two ways an IBC connection verifies messages: consensus light clients, or a first-party attestor oracle signed by the bank's own HSMs.

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.

<Note>
  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.
</Note>

## Choosing between them

|                          | Consensus light client                  | First-party attestor oracle       |
| ------------------------ | --------------------------------------- | --------------------------------- |
| Trust anchor             | The counterparty chain's consensus      | Signers the institution controls  |
| Key infrastructure       | None beyond the chains' own             | The institution's own HSMs        |
| Counterparty requirement | Verifiable consensus, headers available | Signatures and messages only      |
| Third parties trusted    | None                                    | None: the signers are first party |

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.

## Related

* [Overview](/cts-interop/overview)
* [How IBC Works](/ibc/how-it-works)
* [Key Security and Governance](/digital-asset-custody/key-management) for the HSM arrangements this model reuses