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

# Tokenized Deposit Networks

> Consortium networks that the Cosmos Tokenization Suite connects to for settlement, and their membership requirements.

A tokenized deposit network is shared infrastructure operated for a group of
member institutions. Each member issues its customers' deposits as tokens on a
common ledger. Membership is the defining feature.

The network admits institutions under its own rules, and settlement happens
between members inside that perimeter. This distinguishes the rail from the
other two in [Settlement Options](/settlement/settlement-options).

Most stablecoin rail integrations use separate wallets on a settlement chain.
A settlement asset moves between the two counterparties. Each side custodies
its own position, and the chain takes no view on their identities.

On a tokenized deposit network, both counterparties are already members of the
same network. Settlement is a transfer recorded inside that shared perimeter,
and the network's rulebook governs when the transfer is final.

The Cosmos Tokenization Suite (CTS) reaches these networks through network connectors
over IBC. See [Connecting Networks](/ibc/connecting-networks).

## Supported networks

### Canton Network

[Canton Network](https://www.canton.network/) is a privacy-enabled blockchain
built for institutional finance. Digital Asset originally developed the network,
which is now open source. Governance of its interoperability layer sits with the
Canton Foundation rather than any single operator.

Participants include capital markets institutions, exchanges, custodians, and
application providers. The network carries tokenized assets alongside cash.
Settlement is recorded directly between the participants involved, with
transaction data visible only to them.

Canton is also a common starting point for
[Interop](/cts-interop/overview). An institution already running on Canton
connects to other networks without replacing what it has.

### Cari

[Cari](https://cari.com/) is a permissioned network for tokenized deposits
issued by chartered US banks. It was built with a group of US regional and
mid-size banks as design partners. Its member banks govern the network.

Every participating institution uses the same token form. Therefore, a transfer
between two member banks settles on the shared network, not through a
correspondent relationship.

### Partior

[Partior](https://partior.com/) is a multi-currency clearing and settlement
network operated by Partior Pte Ltd in Singapore. DBS, J.P. Morgan, and Temasek
founded the network, and Standard Chartered joined as a shareholder.

Member banks settle cross-border payments in commercial bank money on a 24/7
basis. The network supports atomic payment versus payment settlement for foreign
exchange. This removes the leg risk that arises when both sides of an FX trade
settle separately. See [Atomic Settlement](/settlement/atomic-settlement).

### Progmat

[Progmat](https://progmat.co.jp/en/) is a digital asset issuance and management
platform operated by Progmat, Inc. in Japan. MUFG and other major Japanese
financial institutions back the platform.

Progmat serves as shared national infrastructure for security tokens,
stablecoins, and other tokenized instruments. A consortium of participating
firms operates around it. Progmat supports multiple underlying chains, so the
connection point depends on the chain where an instrument is issued.

## Planned

### The Clearing House

[The Clearing House](https://www.theclearinghouse.org/) operates the RTP and
CHIPS networks in the United States. It is building a bank-led tokenized deposit
network with a consortium of large US banks. The network is designed to clear
and settle tokenized deposits between member banks and connect that activity to
the existing RTP and CHIPS rails.

Compatibility with this network is planned. It is not available today, and the
Suite cannot settle over it. If this rail matters to your deployment, contact
[sales@cosmoslabs.io](mailto:sales@cosmoslabs.io).

## What this rail requires

Both counterparties must be members of the same network. This constraint rules
the rail in or out, and neither bank can resolve it alone. Membership in one
network cannot support settlement with a counterparty belonging to another.

Settlement finality is governed by the network's rules, not by CTS. Each
network defines when a transfer is irrevocable and what recourse exists before
that point. These definitions differ.

Establish the network's finality position alongside the bank's own position.
That comparison determines the exposure carried between clearing and
settlement. See [Finality](/settlement/finality).

The network operator sets admission, membership obligations, and any required
collateral or liquidity. These requirements sit outside CTS.

<Note>
  Documentation is still required for which networks are enabled during setup,
  the operational procedure for settling over each network, and the
  reconciliation treatment for network-side settlement.
</Note>

## Related

* [Settlement Options](/settlement/settlement-options) for the full set of rails
* [Finality](/settlement/finality) for when settlement becomes irreversible
* [Connecting Networks](/ibc/connecting-networks) for how a connection is established