Blockchain interoperability and how Quant approaches it

The interoperability problem, explained for a finance reader

Think of each blockchain as a separate bank with its own ledger, its own rules for what counts as a valid entry and its own staff who sign off on changes. Bitcoin's ledger knows nothing about Ethereum's. An asset on the XRP Ledger cannot simply "move" to Polygon, because Polygon's validators have no way to verify what happened on XRPL. In the traditional system this gap is filled by correspondent banks, clearing houses and messaging standards such as ISO 20022. In crypto, for most of its history, it was filled by nothing at all.

The result is silos. By late 2026 there are dozens of general-purpose chains and hundreds of application-specific ones, each with its own liquidity, its own tokens and its own developer tooling. For a retail user that is a nuisance. For a bank that wants to issue a tokenised deposit on a permissioned ledger and settle a bond on a public one, it is a blocker: core-banking systems were built to talk to one database, not twelve mutually suspicious networks.

Three things make the problem harder than it looks. First, finality differs: a Bitcoin transaction is "done" after several blocks, a Corda transaction is done when the notary signs it, and an optimistic rollup can take a week to be final on its parent chain. Second, there is no shared identity layer; an address on one chain means nothing on another. Third, any component that connects two chains becomes the most attractive target on either of them, because it typically holds or controls the assets in transit. The history of bridge hacks is the history of that third point being learned the hard way.

Four approaches, compared

1. Bridges (lock-and-mint)

The oldest design. You deposit an asset into a smart contract on chain A, and a corresponding "wrapped" token is minted on chain B. To go back, you burn the wrapped token and the contract on A releases the original. The question is who watches the lock contract and authorises the mint. If it is a small multisig, the bridge is only as secure as those keys. If it is a validator set with its own token, the bridge is a mini-blockchain with its own attack surface. Wrapped assets also carry issuer risk: if the bridge is compromised, every wrapped token on chain B becomes unbacked at once.

2. Cross-chain messaging protocols

Instead of a single bridge per asset, a general messaging layer carries arbitrary instructions between chains, and token transfers become one application of it. Chainlink's CCIP is secured by decentralised oracle node sets; LayerZero lets each application configure which verifier networks it trusts; Axelar runs a proof-of-stake validator network that relays messages. All three are public, permissionless protocols with native tokens (LINK, ZRO, AXL) that pay or secure the operators. Our Quant vs Chainlink page goes deep on CCIP, which is the one banks encounter most.

3. App-chains with shared standards

Cosmos is an "internet of blockchains": sovereign app-chains connected by IBC, a protocol in which each chain runs a light client of the other and verifies its headers directly, so no third party sits in the middle. Polkadot takes the opposite route: parachains share security from a Relay Chain and exchange messages through XCM. Both are elegant for chains built inside the ecosystem and much weaker for connecting to chains outside it, such as Bitcoin or a bank's Corda network.

4. API gateways

The enterprise answer. A gateway exposes one standard API and runs connectors to each ledger behind it. The application never touches a chain directly; the gateway builds, signs, submits and tracks the native transaction. This is what Quant's Overledger does. It is not a protocol anyone can join; it is a product that a company operates, with contracts, SLAs and customer support. Trust shifts from code and validators to a vendor and its security controls.

Why banks care about any of this

Banks are not interested in moving meme coins between chains. They care because the money they actually hold, commercial-bank deposits, is being tokenised, and tokenised deposits are only useful if they can reach the places where assets are issued and settled. Three programmes show the pattern.

The UK Regulated Liability Network experimentation phase in 2024 brought Barclays, Citi, HSBC, Lloyds, NatWest, Nationwide, Santander, Standard Chartered, Virgin Money, Mastercard and Visa together to test a shared ledger for regulated money. R3 supplied the Corda-based ledger and Quant supplied orchestration and the API layer connecting participants' existing systems. The Great British Tokenised Deposit pilot that followed went live with customer transactions in September 2026, including two remortgage completions where funds were locked and automatically released. In the US, The Clearing House selected Quant on 24 September 2026 for the interoperability and orchestration layer of its On-Chain Money Initiative, which connects tokenised deposits to the RTP and CHIPS payment systems.

Notice what every one of these has in common: the ledger of record is permissioned, the participants are regulated, and the hard part is connecting that ledger to legacy rails and to other ledgers. That is a gateway problem, not a bridge problem. A public messaging protocol can connect two public chains beautifully, but it cannot plug into a bank's payment engine or satisfy a regulator that wants a named operator. The CBDC and tokenised deposits page covers these programmes in full.

Quant's gateway approach and its trade-offs

Quant's bet, made in 2017 and unchanged since, is that institutions will pay for interoperability delivered as software rather than as a protocol. Overledger sits above the chains as an API; Fusion, live since June 2026, adds an execution layer that Quant calls "Layer 2.5": an optimistic rollup extended from the OP Stack whose state roots are posted to several Layer 1s, with execution data on a permissioned Hyperledger Besu network. Its "unified tokens" (uTokens) are meant to represent an asset across chains without the lock-and-mint contract that makes classic bridges fragile.

The strengths follow directly. One API means no chain-specific code inside the bank. Key management runs through Overledger Authorise, with HSM-backed and MPC signing described in the Blockworks transparency filing. Operators on Fusion are KYC'd "Trusted Nodes" that can choose which jurisdictions they serve, which is precisely what a compliance officer wants to hear. And because Quant's founder initiated ISO/TC 307 and, by his own account, convenes its interoperability working group, the design maps onto the standards banks are told to follow.

The weaknesses follow just as directly. Every transaction passes through Quant-operated infrastructure, and Quant is also the Fusion sequencer, so there is a single operational and commercial dependency. The gateway is closed source; most SDK repositories on GitHub are archived. No public security audit of Overledger or Fusion could be located. And the token sits awkwardly beside all this: Quant's FAQ says platform fees can be paid in USD, and none of the bank announcements mentions QNT, so the link between adoption and QNT demand is indirect. For an institution these are acceptable trade-offs; for a token holder they are the central question.

Real deployments: what interoperability looks like in production

Examples beat theory, so here are the interoperability deployments with evidence from the counterparty rather than only from the vendor.

• SIA (now Nexi), 2019–2020. Italy's payments infrastructure company agreed to integrate Overledger with SIAchain and announced a successful interoperability test across SIAchain, Corda and a private Ethereum network in June 2020. An early proof that a gateway can span permissioned platforms that have nothing in common.
• LACChain, 2021. The IDB Lab-led alliance used Overledger as the interoperability gateway for its Hyperledger Besu network, with a cross-border payments use case reported by Ledger Insights.
• Project Rosalind, 2022–2023. The BIS Innovation Hub London and the Bank of England built an API layer for a retail CBDC with 33 API functionalities and more than 30 use cases. Quant supplied infrastructure to the vendor team alongside UST; the BIS itself names no vendors, and the project was explicitly experimental.
• UK RLN and GBTD, 2024–2026. Described above: orchestration across a Corda ledger and bank systems, then a live tokenised-deposit platform with seven banks.
• Murex MX.3, 2026. Overledger and Quant Flow embedded in a capital-markets platform for tokenised deposits and digital-bond settlement, announced by Murex on 25 March 2026.
• The Clearing House, 2026–2027. Orchestration for tokenised deposits connected to RTP and CHIPS; expected available to participating banks in the first half of 2027.

On the public-protocol side, the comparable reference is Chainlink's work with Swift and more than a dozen banks on moving tokenised assets using existing Swift messaging, which in June 2026 became Project Pangea: more than 50 banks in 16 countries targeting T+0 FX settlement with a live target of mid-2027. Two very different models, both landing in bank back offices at the same time. More context is on the partnerships page.

Security considerations

Whatever the architecture, the connecting layer is where value concentrates and where attackers look. A few principles help when evaluating any interoperability project, Quant included.

Where do assets sit in transit? Lock-and-mint bridges hold assets in a contract; that contract's keys or validator set is the whole security model. Message-passing systems do not custody assets, but the application that receives the message must still verify it, which pushes risk to the verifier set. Gateways like Overledger do not custody customer assets by design; signing happens in HSMs or MPC under the customer's control via Authorise. Quant's record here is clean: the Blockworks filing reports no incidents on Quant-operated funds. The QNT losses that do exist were exchange hot-wallet hacks (LCX in January 2022, Bitrue in April 2023) and a July 2026 EIP-7702 delegation exploit on one user's Ethereum account, none of which involved Overledger.

Who can censor or halt? A permissionless protocol cannot easily stop a transaction; a gateway operator can. For banks that is a compliance feature. For anyone who wants censorship resistance it is a deal-breaker, and it is one reason Quant's model and the public protocols are not really competing for the same customers.

Is the code reviewed? Public protocols publish code and audits because their users can read them. Quant publishes neither the gateway source nor an audit of it; the only audit on record covers the QNT token contract, which has no owner functions. Buyers of enterprise software accept this routinely, but it means outsiders cannot verify the claims. The is Quant legit page sets out what can and cannot be verified from public records.

Comparison table: trust models side by side

Market context for the public protocols, from CoinGecko on 2 November 2026: LINK ranked 17th by market cap, DOT 55th, ATOM 82nd, ZRO 87th and AXL 412th, with QNT at 35th or 36th depending on the tracker. Rank says nothing about technical merit, but it does show that the market treats "interoperability" as several distinct bets rather than one.

Key terms you will meet on this topic

A few words recur in every discussion of interoperability and are worth pinning down. A multi-ledger token is an asset that exists coherently across several ledgers; Quant's QRC tokens and Fusion's uTokens are its versions. An mDApp is Quant's term for an application that is not bound to a single blockchain. Finality is the point at which a transaction can no longer be reversed, and it differs by chain. A light client is a minimal verifier of another chain's headers, the basis of IBC. A sequencer orders transactions on a rollup; on Fusion that role belongs to Quant. Our glossary defines these and about fifty more in plain English, with a search box.