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

# Token Transfers

> How tokenized deposits move between banks: burn on send, mint on destination, and automatic re-mint on failure.

A cross-bank transfer moves value between two banks' digital ledgers over an
established IBC channel, with no custodian and no escrow in the middle.

The implementation follows the Interchain Fungible Token model. Each bank issues
its own deposit token, and that token never leaves its issuer's perimeter.

## Burn on send, mint on destination

The sending bank's chain burns the sender's deposit tokens at the moment of
send. An IBC message travels to the destination chain, which verifies it,
applies its compliance checks, mints its own deposit token, and credits the
recipient. An IBC acknowledgment confirms receipt, verification, and credit.

The acknowledgment completes the transfer: the source tokens were already burned
on send, so there is nothing left to release.

```mermaid theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sequenceDiagram
  participant A as Bank A digital ledger
  participant B as Bank B digital ledger
  A->>A: Burn the sender's deposit tokens on send
  A->>B: IBC message
  B->>B: Verify, compliance check, mint Bank B's token, credit recipient
  B->>A: IBC acknowledgment
  Note over A,B: On reject or timeout, Bank A re-mints the tokens to the sender
```

No escrow is involved at any point. Bank A's token is burned rather than locked,
and Bank B credits the recipient in Bank B's own token rather than in a claim on
Bank A. This means each bank's deposit token remains a liability of its issuer
alone, and neither bank ends up holding a wrapped representation of the other's.

## Failure and refund

Every failure path re-mints the original deposit tokens to the original sender
on the source chain. This covers destination rejection, for example an unknown
recipient account, and timeout, where the message is not delivered in time and
the source chain proves it.

Refunds are automatic rather than operational. There is no state in which value
was burned on one side and never minted on the other without the sender being
made whole.

## Assets in, deposits out

Two directions matter for a bank beyond bank-to-bank transfers.

Assets in: the bank offers clients access to assets selected during setup, for
example USDC and EURC, reached over IBC.

Tokenized deposits out: where the bank enables it, clients can move the bank's
tokenized deposit onto other networks. The bank decides which networks and which
assets are in scope. See [Getting Started](/what-is-cts/getting-started).

<Note>
  The controls a bank has over which transfers are permitted, how transfer limits
  and allowlists are configured, and the compliance checks applied in each
  direction still need to be documented.
</Note>

## Related

* [How IBC Works](/ibc/how-it-works)
* [Connecting Networks](/ibc/connecting-networks)
* [Verification Models](/cts-interop/verification-models)