Skip to main content
A tokenized deposit is only trustworthy while it agrees with the core ledger balance it represents. Reconciliation is the process that maintains that agreement, and it is built on one record: a persistent mapping between each bank-side transaction reference ID and the corresponding digital ledger transaction hash. The Cosmos Tokenization Suite (CTS) adapter maintains that mapping and is its single source of truth. Both ledgers are reconciled against the mapping, not against each other. Tokenization is per transaction. Two runs maintain the mapping, in opposite directions, and a bank operator triggers each.

​
Core to ledger: tokenization

Token sync carries core activity onto the digital ledger. Every core transaction up to the cutoff is checked against the mapping. Anything unmapped has not been tokenized yet, so a matching digital ledger transaction is created and the new pair is recorded. Transactions reach token sync as camt.054 messages. See ISO 20022 Messaging.

​
Ledger to core: writeback

Writeback carries digital ledger activity back to the core. Digital ledger transactions are compared against the mapping, and any new ones are written back to the core ledger and recorded. Transactions roll up to balances on each side: accumulated digital ledger transactions produce digital ledger balances, and core transactions produce core balances. This means agreement between the ledgers is checked transaction by transaction against the mapping, not inferred from balance totals.

​
Preventing double spends

Tokenized deposit accounts, as a custom deposit product, are locked on the core, and the digital ledger always holds the authoritative spendable balance. Debits from tokenized accounts must clear the digital ledger first. This ensures a balance cannot be spent twice at the moment of a transaction, because there is exactly one place a spend can clear. The core ledger remains the system of record for the bank’s books. Every on-chain movement is written back to it, and it is the system the bank reports and audits from. A core-ledger debit that bypassed the digital ledger violates this split. It surfaces as an error at the next token sync, for the bank to resolve rather than for the mapping to absorb. The blocked deposit product exists to make this case rare: balances under it cannot move through the core’s normal channels.

​
Recovery after an outage

Either side can be unavailable without corrupting the model. The mapping persists through an outage on either side. When the failed side recovers, the adapter compares both ledgers against the mapping and reconciles whatever is missing, in the same way as an ordinary run.
The operator surface for triggering runs and resolving errors, the reporting available to a controller, and the handling of a settled external movement that cannot be reversed still need to be documented.