> ## 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.

# Inter-Blockchain Communication

> What Inter-Blockchain Communication is, why it is not a bridge, and how the Cosmos Tokenization Suite uses it for compliant interoperability between banks.

Inter-Blockchain Communication, or IBC, is a messaging protocol that connects two
chains. It is not a bridge.

The difference between messaging and bridging is why the Cosmos Tokenization
Suite uses IBC. A bridge takes custody of an asset on one chain and issues a claim
against it on another, introducing a third party that both chains have to trust.

IBC does not take custody or issue a claim. It lets two chains verify each other
directly and pass authenticated messages between them, so only the two chains
are trusted.

For a bank, direct verification makes interoperability compliant. A payment to a
counterparty bank is a message between two digital ledgers, with each ledger
governed by its institution's policy. No central settlement vendor sits between
them, and no intermediary holds the asset.

<Card title="IBC documentation" icon="external-link" href="https://docs.cosmos.network/ibc/latest/intro">
  Full protocol documentation, including light clients, connections, channels,
  and application development.
</Card>

## Track record and governance

IBC has run in production for over five years with no protocol-level loss of
funds. It has processed over 100 billion dollars in cross-ledger transfers, has
been independently audited more than nine times by leading firms, and is
supported in production across more than 100 networks spanning Hyperledger Besu,
Ethereum, Solana, and Cosmos.

The protocol is free and open source: no vendor, no license fee, and no token is
required to use it. IBC is governed under the
[Linux Foundation Decentralized Trust](https://www.lfdecentralizedtrust.org/),
the Linux Foundation body that is also home to Hyperledger Besu. This means the
protocol's governance matches its design: open, neutral, and owned by no single
vendor, including Cosmos.

## Why not a bridge

|                       | Bridge                                                  | IBC                                       |
| --------------------- | ------------------------------------------------------- | ----------------------------------------- |
| Trust model           | A third party or external validator set holds the asset | The two chains verify each other directly |
| What moves            | A claim against custodied collateral                    | An authenticated message                  |
| Failure surface       | The bridge operator and its key holders                 | The two chains' own consensus             |
| Counterparty exposure | To the bridge, in addition to the other chain           | To the other chain only                   |

Most large losses in digital assets have come from bridges rather than from the
chains they connect. Removing the intermediary removes that exposure: this is
the difference between an arrangement a bank's risk function can approve and one
it cannot.

## How CTS uses it

IBC is how a bank's digital ledger reaches anything outside itself:

* Coordinating a payment with a counterparty bank's tokenization infrastructure,
  including the clearing and compliance checks both sides require
* Moving tokenized assets between networks
* Reaching public networks, consortia networks, and other banks' private networks

See [Networks connectors](/what-is-cts/components) for where this sits in the
architecture.

## Next

* [How IBC Works](/ibc/how-it-works) for the mechanics at a high level
* [Token Transfers](/ibc/token-transfers) for moving assets
* [Connecting Networks](/ibc/connecting-networks) for establishing a path