Why Interoperability Will Decide the Future of Tokenized Deposits

Cosmos and Zeeve background image

Nowadays tokenized deposits let banks issue programmable, regulated bank money directly on a digital ledger. Issuing the deposit token, however, is only the first step toward making it useful beyond the bank's own ledger. The harder problem is settling that liability across networks the bank doesn't control.

That’s important because the value of any network grows with the number of participants who can transact on it, which is the network effect described by Metcalfe's Law. Without interoperability, tokenization risks replacing today’s existing messaging silos with isolated cryptographic silos instead.


A Tokenized Deposit Is Only Useful If Other Institutions Can Trust and Settle Against It

A tokenized deposit is a high-quality settlement asset only inside the set of institutions that have agreed to honor it. That set can be a single bank, a consortium, or a broader network. Outside that scope, it has no accepted value and cannot be exchanged for standard currency unless another bank, custodian, or settlement system can verify, accept, and redeem it under enforceable rules.

Economic fungibility for deposit tokens relies on multiple factors. Technical interoperability is only one of them. The hardest cases for achieving that fungibility are exchanges across different issuers or redemptions by a bank that is not the original issuer.

Deutsche Bank's May 2026 report reaches the same conclusion.

For now, transferability typically remains limited to the issuing bank’s own client base. Broader circulation across institutions raises as yet unresolved legal and supervisory questions around the transferability of deposit liabilities beyond the original depositor relationship. If these issues are addressed, so-called deposit tokens could eventually move between clients of different regulated institutions – other than the issuing bank – provided robust KYC requirements are met.

This matters because tokenized deposits are also claims on regulated banks. They cannot move the way regular crypto assets do, where a wrapped version is often accepted as fungible enough. Moving tokenized deposits across networks instead requires purpose-built interoperability infrastructure, and that comes with its own trade-offs. An interoperability protocol may help move the tokenized deposit from one network to another, but it can also introduce new problems, like smart-contract risks or reconciliation issues.

Stablecoins already show the operational risk that fragmented liquidity, wrappers, and third-party bridges bring, such as: the same stablecoin existing as incompatible, non-fungible versions across chains, reliance on bridges that have lost over $2.5 billion since 2021, and the delays those bridges add to cross-chain transfers. Deposit tokens inherit the same connectivity problem but carry a higher compliance burden because the asset is bank money and a broken transfer risks distorting an insured deposit balance rather than just losing funds.

What actually determines success is whether a bank's deposit tokens can be used outside that bank, meaning other banks accept them, they move through a consortium network, and they still reconcile properly with the issuer's core ledger. A private ledger can make things faster within a single bank, but fixing correspondent banking or capital markets settlement requires connecting safely with other ledgers.


Why Is Technical Interoperability Hard? The Architectural Barriers

Technical interoperability is hard because financial ledgers do not share the same execution model, state model, identity model, privacy model, or finality model.

Heterogeneity Is the First Barrier

Hyperledger Besu, Fabric, Avalanche L1s, Solana, Ethereum L2s, and Cosmos-based ledgers do not represent assets in the same way. Their execution model and finality models differ just as much. The challenge is moving value across them without altering the nature of the bank claim or spawning a second version of the asset that the issuing bank cannot reconcile, not merely connecting two networks together.

The Second Is State Consistency

In DvP or PvP, both sides of the transaction must occur simultaneously. Either the cash and asset legs both settle, or neither does. That is simple inside one deterministic ledger. It becomes difficult across ledgers with different consensus mechanisms, block times, or proof systems. When the cash leg finalizes before the asset leg, the bank carries settlement exposure. An asset leg that locks while the cash leg fails leaves the venue with an exception queue. If both systems finalize differently, operations teams face the exact reconciliation problem the technology was supposed to remove.

The Third Problem Is Semantic Disconnection

A token transfer is not the same as a full banking instruction. Banks need sender and receiver details, entity identifiers, purpose codes, remittance data, sanctions checks, transfer limits, among other data points. This data also has to map to ISO 20022-style messages and internal core-banking schemas. If that mapping fails, the transfer may be cryptographically valid but operationally unusable.

The Fourth Barrier Is Third Parties

The fourth barrier is the one that gets the least attention. Most connectivity options on the market today route trust through a third party. General-purpose bridges concentrate risk in third-party smart contracts, and the results are on record. The four largest crypto exploits between 2021 and 2022 all targeted cross-chain bridges, draining more than $2 billion. The April 2026 exploit of a LayerZero-powered bridge shows the pattern has not aged out. Here the bank bets on one vendor's survival, governance, and pricing instead. In both cases, the layer that decides whether money moves belongs to someone else.

There are Conflicts of Law as Well

If a tokenized deposit moves from a ledger governed by New York law to one governed by EU law, no settled rule determines which jurisdiction controls ownership, priority, and recourse in case something goes wrong. This is the lex situs dilemma in digital form.

The same problem extends to regulation. A transaction involving an EU-regulated venue will need to comply with regulatory requirements such as MiCA, while the issuing bank may operate under US banking rules. Interoperability engines will need to enforce these differences in real time. That includes counterparty eligibility, transfer limits, sanctions checks, reporting obligations, and jurisdiction-specific restrictions.

Then there is the Travel Rule, a requirement that applies in traditional banking as well as crypto. It requires originator and beneficiary information to move with certain transactions, without exposing that data across every connected ledger. Banks need a way to pass KYC and transaction metadata along with the token movement, while respecting privacy laws such as GDPR. The bank must prove that the right compliance data moved to the right party, under the right policy, without leaking information to everyone else; a higher bar than simply proving a token moved.


The right architecture for “Good Interoperability” and Cosmos IBC

Because the market will stay fragmented across many ledgers, most institutions will need cross-ledger interoperability, an architecture built to address every barrier covered above. The Inter-Blockchain Communication protocol (IBC) maps to each one.

To address that heterogeneity, ledgers transacting over IBC verify each other’s state directly using light clients, with no intermediary holding the assets in between. IBC can connect to any EVM L2, Consortia, or other non-Cosmos environments including Hyperledger Besu, Solana, Canton, and any system capable of signing data, such as a bank's own core ledger.

The IMF's July 2026 note on tokenization makes a related point:

Compatible-ledger architectures, in which assets remain on separate ledgers, but transactions are coordinated across them, appear more practical in the near term, as they impose fewer governance constraints.

This is because it avoids the risks of putting everyone on a single shared platform.

To address state consistency, a data packet has a full lifecycle in IBC, from acknowledgment to timeout to callback, so a cross-ledger payment either completes on both sides or unwinds cleanly. There is no half-finished state.

Semantic disconnection works the same way. The Cosmos Tokenization Suite pairs IBC with direct core banking integration, so every account gets a digital twin that stays in sync with the core ledger. Reconciliation runs against the general ledger, ISO 20022 messages travel over the bank's existing RSA setup, and the payment instruction never travels without its compliance data.

To address lock-in, IBC is a set of open standards, more like ISO than a proprietary platform. It is neutrally governed, requires no token and no third-party dependency, and has run in production for five years across more than 115 connected ledgers and $50 billion in transfer value. Japan's Progmat platform, backed by the country's three megabanks, uses this connectivity model to move regulated tokenized assets between networks while preserving issuance compliance.

To address the legal problem, policy-based packet filtering lets an institution encode corridor-specific rules at the relay layer, so jurisdictional requirements are enforced at the edge instead of negotiated afterward.


Interoperability carries compliance data alongside the payment, and that data cannot leak. Being permissioned doesn't make a network private; validators, RPC endpoints, and explorers can all see more than client confidentiality rules allow. That's why privacy has to be built into every layer of the stack, not assumed to hold at the network level alone. Cosmos handles this across multiple layers, and its infrastructure partner, Zeeve, extends this with a system-wide privacy layer covering transactions, contract logic, and selective disclosure for regulators.


Where to Start

Banks should start with one strong use case rather than a broad tokenization program. The best candidates are high-value payments, collateral, or DvP use cases where current challenges have a measurable cost.

​The next step is to build the issuance layer around the core ledger. Cosmos is a strong architectural fit whenever the requirement is independent bank issuance and controlled cross-ledger connectivity. Cosmos Tokenization Suite provides banks with an issuance and transfer layer that integrates with existing systems, supports native core banking integration, GL reconciliation, and compliance gateways, and connects via IBC to external payment rails, consortia, and banking networks.

​The third step is to test interoperability under production constraints. Testing this requires infrastructure that is both privacy-enabled and production-proven, where financial institutions can launch tokenized deposits. Zeeve, as a Cosmos partner, helps with this. Zeeve brings deployment and operation expertise, including fully managed networks, node and validator operations, monitoring and observability, migration support, and system-wide privacy capability through Zeeve Privacy Layer.


A decade from now, the tokenized deposit platforms that matter will be the ones built by institutions that stayed connected through every change in the market, on infrastructure they controlled the entire time.

​If your bank or consortium is building a tokenized deposit network, Cosmos can provide the ledger and interoperability architecture, and Zeeve can help institutions run it with the operational discipline expected from financial infrastructure.

About the Author

Dr. Ravi Chamria is the Co-Founder and CEO of Zeeve, a leading blockchain infrastructure platform that helps enterprises launch and scale Rollups, AppChains, and custom blockchain networks with ease. With over two decades of experience across digital transformation, automation, and emerging technologies, he focuses on simplifying blockchain adoption through scalable, production-grade infrastructure. His work spans advising enterprises, partnering with global protocol ecosystems, and advancing modular blockchain architectures. He is passionate about the convergence of blockchain and AI and actively contributes insights through industry forums, podcasts, and global tech events.


Ravi Chamria

Ravi Chamria

Co-Founder and CEO of Zeeve

LinkedIn profile