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