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

# Real World Assets

> Why the architecture applies to off-chain assets, and what is not built today.

<Note>
  Tokenized real world assets are not a shipped product today. The Cosmos
  Tokenization Suite targets tokenized deposits. The asset classes described on
  this page are directional and are not available. Contact our team at
  [sales@cosmoslabs.io](mailto:sales@cosmoslabs.io) to discuss a specific asset class.
</Note>

A real world asset is an asset that exists off ledger, is recorded on an
authoritative system, and is represented on a digital ledger for transfer and
settlement. Loans, receivables, funds, commodities, and property interests are
the usual candidates.

The representation itself is not the appeal. Once an asset and cash both sit on
a ledger, one operation can exchange them. Without that arrangement, two
separate settlements require reconciliation afterwards.

## Why this architecture suits the problem

The same architecture supports other asset classes because it never assumes the
asset is a deposit.

* The authoritative system stays authoritative. CTS mirrors a position
  instead of taking custody, so the asset's register of record neither moves nor
  requires replacement. See
  [Banking Core Integrations](/banking-core-integrations/overview).
* Backing is structural: a balance on the authoritative system creates the token,
  and ledger sync keeps the two continuously aligned. See
  [Reconciliation](/banking-core-integrations/reconciliation).
* The digital ledger does not change. It holds tokenized balances without needing
  to know what they represent, so a new asset class does not require a new chain.
  See [Digital Ledger Support](/digital-ledger-support/overview).
* IBC is the mechanism that carries authenticated messages between ledgers,
  regardless of the asset in the message. No bridge holds the asset between
  ledgers. See [Inter-Blockchain Communication](/ibc/overview).
* Custody does not change. Keys for anything on a shared or public network remain
  with the bank's custody provider, under the bank's signing policy. See
  [Digital Asset Custody](/digital-asset-custody/overview).
* Governance does not change. Identity management, compliance and risk, and the
  bank's policy engine govern activity through the policy and logs interface.
  Those controls do not require reimplementation. See
  [Components](/what-is-cts/components).

## What is actually missing

An architecture that supports other asset classes is not a completed product.
Each asset class needs three things that tokenized deposits already have:

* A connector to the system that is authoritative for the asset, which is not
  the core banking platform for many asset classes
* A representation of the asset's transfer restrictions and eligibility rules,
  enforced at transfer time
* Handling for the asset's lifecycle events, which are close to trivial for
  deposits but are not for most other assets

These asset-specific requirements are why this capability is not yet a product.
The missing work is not architectural.

## The one exception today

Securities held on the general ledger can be tokenized through the Jack Henry
integration. This capability uses the same ledger sync mechanism as deposits. It
is a confirmed, specific capability, not a general real world asset offering.
See [Securities](/use-cases/securities) and
[Jack Henry](/banking-core-integrations/jack-henry).

## Next

* [Securities](/use-cases/securities) for the asset class closest to being served
* [Tokenized Deposits](/use-cases/tokenized-deposits) for what is available today
* [Delivery vs Payment](/settlement/delivery-vs-payment) for settling an asset leg
  against a cash leg