Interoperability and the many-chains problem

A connection is not a common market

The promise of tokenisation becomes less straightforward when an asset must travel. A digital representation of a property interest may be intelligible within one network, yet difficult to recognise elsewhere. Different custody arrangements, transfer rules and investor permissions can turn a seemingly simple movement into a fresh onboarding exercise. The many-chains problem is therefore not just an engineering inconvenience. It is the question of whether separate financial systems can recognise the same claim without quietly changing what that claim means.

For institutional investors, the relevant unit is not the token but the enforceable entitlement behind it. A ledger entry might represent a contractual claim, an interest in a vehicle or evidence associated with a separate register. Moving that entry does not necessarily move legal title. Before considering network connectivity, an allocator needs to understand which record is authoritative, which institution maintains it and what happens when records disagree. An elegant interface cannot settle an unresolved hierarchy of rights.

This distinction matters especially for real assets, where the underlying property remains outside the network. Buildings, leases and security interests do not become universally portable because their financial representation acquires a common technical format. Interoperability must preserve the connection between a digital instruction and the legal machinery that gives it effect.

Four layers that must agree

Technical interoperability concerns the exchange of messages and instructions. It asks whether systems can communicate securely and interpret the same transaction. Semantic interoperability asks whether they mean the same thing: a balance, a restriction or a corporate action must retain its meaning between systems. Both are necessary, but neither establishes that a receiving institution is entitled to accept the asset or recognise its holder.

Legal and operational interoperability complete the picture. Legal compatibility concerns the rights transferred, applicable law and enforceability of the resulting position. Operational compatibility concerns the people and processes expected to act when automation stops. An institution may understand a message perfectly while being unable to process it because its custody agreement, client mandate or compliance procedures do not permit the proposed movement. These are substantive constraints, not temporary obstacles to be wished away.

Identity illustrates the overlap. A receiving platform may need evidence that an investor meets eligibility requirements without receiving every document collected elsewhere. Reusable credentials could reduce duplication, but acceptance still depends on responsibility for verification, expiry, revocation and errors. Data protection obligations also remain relevant. The practical objective is not unlimited sharing; it is sufficient, reliable information reaching the party that must make a defensible decision.

The risks hidden inside a bridge

A bridge can connect networks while introducing a new dependency between them. Some designs lock an asset in one place and issue a corresponding representation elsewhere. Others rely on messaging, intermediaries or coordinated transfers. Each architecture raises questions about control, reconciliation and failure. The investor needs to know whether the destination asset is the original claim, a substitute claim or an additional promise made by another entity.

The strongest connection is not the one that moves a token fastest, but the one that preserves the investor’s rights when something fails.

Finality deserves particular attention. Technical confirmation, contractual completion and legal settlement need not occur together. If one leg becomes irreversible before another, a supposedly integrated transaction may leave a party exposed. Payment arrangements complicate this further: the asset and the money may sit on different systems, under different terms, with different procedures for disruption. A transaction diagram should show these mismatches rather than hide them behind a single arrow.

Recovery arrangements are equally revealing. Who can suspend transfers after a compromise? Who resolves duplicate representations? Can an incorrect movement be corrected without undermining legitimate ownership? Institutions should also distinguish between a system that remains secure and one that remains usable. A bridge may protect locked assets by stopping operations, yet still leave investors unable to exercise rights or obtain timely settlement. Resilience includes an orderly route through that interruption.

Design for selective portability

The answer is not necessarily a universal network. Different environments may serve different instruments, governance preferences and confidentiality requirements. A lender financing contracted infrastructure may value controlled access and predictable administration more than broad distribution. Another investor may prefer connectivity to an established custody environment. The sensible aim is selective portability: allowing an asset to move where there is a credible reason, subject to rules that remain visible throughout its journey.

That approach favours common data definitions, documented interfaces and explicit responsibility over ambitious claims of seamlessness. Transfer restrictions should be understandable before an instruction is sent. Corporate actions should remain traceable after migration. Reconciliation should identify who investigates discrepancies and how investors receive information during an incident. Institutions also need an exit plan if a service provider withdraws support or a network becomes commercially unattractive. Portability that works only while every supplier cooperates is a limited form of freedom.

Commercial incentives deserve scrutiny too. A platform may describe itself as open while making extraction expensive or operationally difficult. Proprietary identity records, inaccessible transaction histories and restrictive custody arrangements can recreate familiar forms of dependence. Interoperability should therefore be assessed through an actual migration scenario, including documentation, permissions and continuing asset servicing, rather than through a list of supported networks.

For a pre-launch UK arranger such as Democratize, the editorial lesson is to begin with the asset structure and intended institutional audience. Connectivity should follow a clear account of ownership, governance and settlement. The most useful progress may look unremarkable: fewer ambiguous handovers, more consistent records and a credible procedure for exceptions. A many-chain future becomes investable through disciplined coordination, not through the assumption that connection itself creates trust.

Information, not advice.