ISO/DTS 23516
(Main)Blockchain and distributed ledger technology — Interoperability framework
Blockchain and distributed ledger technology — Interoperability framework
This document specifies a framework, recommendations and requirements for interoperability between DLT systems, between DLT and entities outside the DLT system, the relationship and interactions between these and cross-cutting aspects.
Technologies des chaînes de blocs et technologies de registre distribué — Cadre d'interopérabilité
General Information
Standards Content (Sample)
FINAL DRAFT
Technical
Specification
ISO/TC 307
Blockchain and distributed ledger
Secretariat: SA
technology — Interoperability
Voting begins on:
framework
2025-10-28
Voting terminates on:
2025-12-23
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
Technical
Specification
ISO/TC 307
Blockchain and distributed ledger
Secretariat: SA
technology — Interoperability
Voting begins on:
framework
Voting terminates on:
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Benefits of distributed ledger technology (DLT) interoperability . 3
5 Overview of distributed ledger technology (DLT) interoperability . 3
5.1 General .3
5.2 Distributed ledger technology (DLT) interoperability scenarios .3
5.3 Distributed ledger technology (DLT) interoperability modes .4
5.4 Distributed ledger technology (DLT) interoperability solutions .5
5.4.1 General .5
5.4.2 Distributed ledger technology (DLT) oracles .5
5.4.3 Distributed ledger technology (DLT) oracle use cases .6
5.4.4 Cross authenticated distributed ledger technology (DLT) synchronization .7
5.4.5 Cross authenticated distributed ledger technology (DLT) synchronization use
cases .7
5.5 Distributed ledger technology (DLT) interoperability infrastructure .7
5.5.1 General .7
5.5.2 Distributed ledger technology (DLT) nodes .7
5.5.3 Distributed ledger technology (DLT) node proxies .8
5.5.4 Distributed ledger technology (DLT) gateways .10
6 Distributed ledger technology (DLT) interoperability facets .11
6.1 General .11
6.2 Transport facet . 12
6.3 Syntactic facet . 12
6.4 Semantic data facet. 12
6.5 Behavioural facet . 13
6.6 Policy facet . 13
6.7 Facets summary .14
7 Specific considerations for distributed ledger technology (DLT) interoperability
solutions . 14
7.1 General .14
7.2 Decentralisation . 15
7.3 Consensus . 15
7.4 Smart contracts .16
7.4.1 General .16
7.4.2 Smart contract standards for interoperability .16
8 Distributed ledger technology (DLT) interoperability architecture .16
8.1 General .16
8.2 Inter distributed ledger technology system interoperability architecture .18
8.2.1 General .18
8.2.2 Inter distributed ledger technology (DLT) system governance .18
8.2.3 Inter distributed ledger technology (DLT) system legal, technical, and
implementation considerations .19
8.3 External non-distributed ledger technology (DLT) system interoperability architecture . 20
8.3.1 General . 20
8.3.2 Distributed ledger technology (DLT) system to non-DLT system governance . 20
Annex A (normative) Security .22
Bibliography .24
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 307, Blockchain and distributed ledger
technologies.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
This document is intended to establish a common understanding of interoperability among distributed
ledger technology (DLT) systems and between DLT systems and non-DLT systems. Standardization is a key
enabler of interoperability, which is important for the efficient use and wider adoption of DLT.
To ensure interoperability of DLT systems, multiple interoperability facets and interoperability layers must
be considered. Establishing a common DLT interoperability framework can increase trust and adoption.
Examples of key DLT interoperability requirements include transferring assets between systems, preventing
invalid transactions and preventing loss of ownership.
v
FINAL DRAFT Technical Specification ISO/DTS 23516:2025(en)
Blockchain and distributed ledger technology —
Interoperability framework
1 Scope
This document specifies a framework for interoperability between DLT systems, between DLT and entities
outside the DLT system, the relationships and interactions between these and cross-cutting aspects.
2 Normative references
The following documents are referred to in the text in such a way that their content constitutes requirements
of this document. For dated references, only the edition cited applies. For undated references, the latest
edition of the referenced document (including any amendments) applies.
ISO 22739, Blockchain and distributed ledger technologies — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22739 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
cross authenticated DLT synchronization
cross authenticated distributed ledger technology synchronisation
method to synchronize two or more DLT systems (3.14) via adding transactions onto each system
3.2
distributed ledger
ledger that is shared across a set of distributed ledger technology (DLT) nodes (3.10) and synchronized
between the DLT nodes using a consensus mechanism
[SOURCE: ISO 22739:2024, 3.23, modified – Note 1 to entry has been removed]
3.3
DLT
distributed ledger technology
technology that enables the operation and use of distributed ledgers (3.2)
[SOURCE: ISO 22739:2024, 3.25]
3.4
DLT gateway
distributed ledger technology gateway
software component connected to one or more DLT nodes (3.10), providing functionality that is not present
in the DLT node software
3.5
DLT interoperability
distributed ledger technology interoperability
ability of two or more systems or applications to exchange information and to mutually use the information
that has been exchanged, where at least one of these systems is a DLT system (3.14)
3.6
DLT interoperability mode
distributed ledger technology interoperability mode
purpose of the information exchanged in the DLT interoperability scenario (3.7)
3.7
DLT interoperability scenario
distributed ledger technology interoperability scenario
systems or applications that are exchanging information to achieve DLT interoperability (3.5)
3.8
DLT interoperability solution
distributed ledger technology interoperability solution
DLT solution (3.14) built for DLTinteroperability (3.5)
3.9
DLT network
distributed ledger technology network
network of DLT nodes (3.10) which make up a DLT system (3.14)
[SOURCE: ISO 22739:2024, 3.30]
3.10
DLT node
distributed ledger technology node
device or process that participates in a network and stores a complete or partial replica of the ledger records
[SOURCE: ISO 22739:2024, 3.31]
3.11
DLT node proxy
distributed ledger technology node proxy
software component connected to one or more DLT nodes (3.10), providing functionality only present in the
DLT node software
3.12
DLT oracle
distributed ledger technology oracle
service that updates a distributed ledger (3.2) using data from outside of a DLT system (3.14)
[SOURCE: ISO 22739:2024, 3.32, modified – Note 1 to entry has been removed.]
3.13
DLT solution
distributed ledger technology solution
solution built using a DLT system (3.14) to accomplish some business objectives common to a group of DLT
users (3.15)
[SOURCE: ISO 22739:2024, 3.34, modified – Note 1 to entry has been removed.]
3.14
DLT system
distributed ledger technology system
system that implements a distributed ledger (3.2)
[SOURCE: ISO 22739:2024, 3.35]
3.15
DLT user
distributed ledger technology user
entity that uses services provided by a DLT system (3.14)
[SOURCE: ISO 22739:2024, 3.36]
3.16
interoperability
ability of two or more systems or applications to exchange information and to mutually use the information
that has been exchanged
[SOURCE: ISO/IEC 22123-1:2023, 3.6.1]
4 Benefits of distributed ledger technology (DLT) interoperability
Benefits from DLT interoperability can include:
— interaction between permissioned and permissionless DLT networks;
— exchange of data between systems;
— availability of consistent data;
— synchronization of state between systems;
— ensuring authenticity, integrity and confidentiality of data exchanged at the same time;
— transferability of digital assets;
— non-duplication of digital assets;
— minimising the potential for technology lock-in;
— cross-jurisdictional data flows and compliance.
5 Overview of distributed ledger technology (DLT) interoperability
5.1 General
When addressing DLT interoperability, the following should be considered:
— What are the systems or applications that are exchanging information? (See 5.2.)
— Why are they exchanging information? (See 5.3.)
— How is this information exchanged? (See 5.4 and 5.5.)
The additional sections describe the different DLT interoperability facets (see Clause 6), highlight specific
considerations for DLT interoperability solutions (see Clause 7) and detail DLT interoperability architecture
concerns (see Clause 8).
5.2 Distributed ledger technology (DLT) interoperability scenarios
DLT interoperability is required to involve at least one DLT system. There are various DLT interoperability
scenarios:
— Connecting a DLT system to non-DLT system: This scenario has the widest scope. DLTs are a modern
invention, but there are many other types of system. Connecting a DLT system to a non-DLT system can
therefore be a complex and widely varying task.
— Connecting two DLT systems of different DLT types: DLTs come in many forms (types). Connecting two
DLT systems of different DLT types can also be a complex and widely varying task. How big the task
is depends on a variety of factors, including: the DLT data structures, such as the unspent transaction
output (UTXO) model or the accounts model; the type of smart contracts allowed, e.g. Turing complete
language, non-Turing complete language or no smart contracts at all; and how identity is managed, such
as via public and private key pairs only or via a public key infrastructure utilising certificates.
— Connecting two DLT systems of the same DLT type but with incompatible versions: DLTs release multiple
versions, and not all versions are backwards compatible. For example, a DLT node running a particular
version cannot interact with a DLT node running a different version. This incompatibility creates
integration issues. But integration is more complicated when the two DLT systems use different DLT
types. This is because even though the versions are incompatible, both DLT systems will inevitability
have many commonalities.
— Connecting two DLT systems of the same DLT type and compatible versions: If two different DLT systems
use the same DLT type with compatible versions, integrating them becomes significantly easier. This is
because both systems use the same syntactic model; any semantic integration challenges between the
systems should be similar to integrating two applications that use the same DLT system.
5.3 Distributed ledger technology (DLT) interoperability modes
DLT interoperability involves different modes of interoperation for transferring or exchanging assets and
data. The three main interoperability modes are:
— Data transfer: Data is copied, with an optional intermediate processing step, from an external source
system into a destination system. Such data can include state information or data representing logic
or code. For example, the token price information from a decentralised exchange on one DLT system
can be copied into another DLT system. Data transfer usually requires at least one transaction on the
distributed ledger of the destination DLT system.
— Asset transfer: An asset record can be created on a destination system as an exclusive replacement or
exclusive alternate form of control for an asset record that is locked or burned (destroyed) on a source
system. For convenience, this is called “asset transfer” in this document, although whether the legal
transfer of an asset is effected by this mechanism can depend both on the nature of the asset records
in these systems and on legal or regulatory situations in relevant jurisdictions. This asset transfer
interoperability can be used to change of ownership of assets. It also can be used to manage control over
an asset or process. In a DLT system, tokens are often used to represent assets. Tokens that are minted
(created) can be called wrapped tokens, if these tokens take their value from the locked source asset.
For example, a token can be locked to a multi-signature address on one DLT and a representative asset
(e.g. a wrapped token) can be minted on a different DLT system. Asset transfer requires at least one
transaction on the distributed ledger of the destination DLT system and usually at least one transaction
on the distributed ledger of the source DLT system.
— Asset exchange: Assets are exchanged between accounts in their respective systems, i.e. no transfers
across systems occurs. Participants are required to have an account in both systems for this exchange
to occur. For example, swapping tokens on a DLT system for different tokens on a different DLT system
between two parties who both have accounts on both systems. Asset exchanges typically require two
transactions on the distributed ledger of each DLT system involved in the exchange: one transaction to
escrow (lock) the asset and another transaction to (unlock and) send the asset to its final destination.
Both asset transfers and asset exchanges can be permanent or temporary:
— Permanent asset transfer: The asset record is burned (destroyed) on the source system when the
replacement asset record is minted (created) on the destination system.
— Temporary asset transfer: The asset record is locked on the source system before a corresponding asset
record is minted (created) on the destination system. If a reversing asset transfer is performed at a later
time, that minted asset record can be destroyed and the original asset record can be unlocked.
— Permanent asset exchange: Assets are exchanged between parties with no obligation to reverse the
exchange later. For example, the purchase of an asset on one system using money on another system.
— Temporary asset exchange: Assets are exchanged between parties where the conditions to reverse the
swap are in place. For example, a cross-ledger loan where one party escrows or locks an asset on one
system as collateral while using an asset on another DLT system for a limited time.
5.4 Distributed ledger technology (DLT) interoperability solutions
5.4.1 General
DLT interoperability solutions are categorized according to the approach used for achieving interoperability.
Two common technically non-overlapping approaches to DLT interoperability are DLT oracles (see 5.4.2)
and cross authenticated DLT synchronization (see 5.4.4).
5.4.2 Distributed ledger technology (DLT) oracles
DLT oracle solutions are used for both the data transfer and asset transfer DLT interoperability modes.
A DLT oracle is a service that updates a distributed ledger using external data. DLT oracles therefore allow
data (including assets) to move from a source external system into a destination DLT system, where the
source system can be a DLT system. Oracles fetch data according to certain triggers (e.g. a transaction being
added onto a DLT system or certain local configuration parameters). Before this fetched data is added onto
the destination DLT system, it can be processed for syntactic, semantic, behavioural or policy reasons.
A DLT oracle has one or more operators who are responsible for running the service. Each DLT oracle can
be thought of as a connection between two systems, one of which is a DLT system. All DLT oracles move
data from one system to another. DLT oracle operators can run the entirety of the service (gather the data
from the source system, optionally process the data and add it to the destination system). Alternatively, a
DLT oracle can contain two or more groups of operators: one group for gathering the data from the source
system, another group to add the data onto the destination DLT system and other possible intermediate
groups for additional processing.
There are two general types of DLT oracles:
a) Data transfer oracles: These services move data from a source system to a destination system. The
semantic meaning of this data on the destination DLT system depends on the use case.
b) Asset transfer oracles: These services are concerned with transferring representations of value. They move
data from a source system to a destination system, where the semantic meaning of this data is an asset
originally represented on the source system but now to be represented on the destination DLT system.
DLT oracles are required because code deployed into a distributed ledger cannot access external resources
without the help of an intermediary. These intermediaries (DLT oracles) gather external data, usually
placing it into transactions that are subsequently added to the distributed ledger, therefore allowing this
retrieved data to be read by deployed smart contracts. Fetched data can also be placed in non-transaction
locations, such as in block headers.
DLT oracles can operate in either a push or pull model to transfer data and assets between systems. DLT
oracles have different workflows based on push and pull models and the type of destination DLT system.
These architectural differences enable various cross-system data and asset transfer patterns.
— Push-based data transfer oracles: These services add data from an external system onto a destination
DLT system without an explicit request from a transaction on the destination DLT system. Instead,
these oracles fetch data according to requests external from the destination DLT system, such as local
configuration parameters or API calls.
— Pull-based data transfer oracles: These services fetch data from a source system and add the data to a
destination DLT system. They operate upon receiving a request from a transaction on the destination
DLT system. Pull-based data transfer oracles operate differently depending on the transaction execution
model of the DLT:
— Order-validate-execute model: Pull-based data transfer oracles on these DLT systems require
multiple transactions to complete the data transfer process. The first transaction is placed on the
destination DLT system to request the external data. A second transaction, including the requested
data, is added onto the destination DLT system. A third transaction can be required to use the
requested data.
— Execute-order-validate model: Pull-based data transfer oracles on these DLT systems only require
one transaction to complete the data request process as the data is fetched from the source system
by the DLT nodes, before the transaction requesting this data is signed and finalised in the ledger.
— Push-based asset transfer oracles: These services add data (representing assets) onto a destination DLT
system without an explicit request from a transaction on the destination DLT system. Instead, these
oracles fetch data (representing assets) according to requests external from the destination DLT system,
such as local configuration parameters, API calls or a transaction on the source DLT system.
— Pull-based asset transfer oracles: These services fetch data (representing assets) from a source system
and add the data to a destination DLT system. They operate upon request from a transaction on the
destination DLT system. Pull-based asset transfer DLT oracles can only operate from a source system
whose current state is dependent on the destination DLT system (such as layer 2 networks or sidechains).
This is because changes on the destination DLT system can indirectly affect state changes on the source
system allowing tokens on the source system to be locked or burned according to transactions on the
destination system.
An individual user can run their own DLT oracle (i.e. be a DLT oracle operator) as long as that user has access
to both the source and destination systems. But the operators of each DLT oracle must convince other users
of the validity of data (or assets) moved via this oracle in order for the transferred data to have any value.
5.4.3 Distributed ledger technology (DLT) oracle use cases
While most actions that occur in a DLT system are deterministic, oracles encompass and isolate non-
deterministic data feeds and real-world information that the DLT system cannot detect on its own. A DLT
oracle can therefore be used to feed information into a DLT system, such as price feeds of real-world assets,
which can then be consumed by other smart contracts and services running on the DLT system. DLT oracles
can also be used to connect DLT systems to real-world actions that occur. DLT oracle use cases can include:
— prediction markets on real-world events;
— price feeds for real-world assets;
— location tracking for real-world items;
— payment confirmation events;
— sensor data verification for supply chains;
— shared registries.
Another common use case for connecting an external system to a DLT system is for “proof of existence”.
Embedding the cryptographic hash of a digital document into a DLT system can allow parties to later verify
that the document existed at that earlier time.
When a DLT oracle is used to connect a DLT system to another DLT system, the use cases can be similar to
when a non-DLT system is being connected to a DLT system. For example, price data from one DLT system
can be placed on another DLT system, or blocks of one DLT system can be timestamped on the other DLT
system if certain block data (e.g. a block’s hash) is placed on the second DLT system.
Additionally, as stated previously, DLT oracles can be used for transferring assets from one system to
another, so a common use case is DLT system to DLT system asset transfers.
5.4.4 Cross authenticated distributed ledger technology (DLT) synchronization
Cross authenticated DLT synchronization solutions are used for the asset exchange interoperability
mode. They allow parties to exchange assets across systems, where each party adds a transaction on each
DLT system. To this end, parties must authenticate on each system to perform the transfers, and these
authenticated transactions on the different systems are used to synchronize the relevant data so that the
exchange can complete atomically. This process can happen in a peer-to-peer manner or via additional
mediators.
Peer-to-peer asset exchanges correspond to one asset exchange with non-mediated communication. The
typical method for implementing this scheme is via hash lock time contracts (HTLCs), where both parties
deploy (or utilize) a smart contract in each chain that transfers the right number of coins to the other party.
But other non-HTLC solutions exist, such as universal atomic swaps.
On the other hand, mediated asset exchanges are cross authenticated DLT synchronization solutions with
additional mediator(s). In these types of exchanges, users add a transaction onto the distributed ledgers to
escrow their assets with the mediator(s) who are subsequently responsible for adding more transactions
onto the distributed ledgers to complete the swap correctly.
5.4.5 Cross authenticated distributed ledger technology (DLT) synchronization use cases
Cross authenticated DLT synchronization interoperability solutions can be used between a DLT system and
a non-DLT system, e.g. when a DLT based asset is to be exchanged with a non-DLT based asset. As a non-
DLT system is involved, this cross-authentication solution must be at least partially mediated via a third
party. Centralized exchanges are an example of this type of mediator-based DLT interoperability solution for
swaps of DLT assets for money, while peer-to-peer asset exchanges aim to achieve DLT asset swaps without
a mediator, often for privacy or trust reasons.
5.5 Distributed ledger technology (DLT) interoperability infrastructure
5.5.1 General
Every DLT interoperability solution shall be built against an infrastructure that can allow DLT
interoperability functionality to occur between different DLT systems. DLT interoperability infrastructure
consists of DLT nodes, DLT proxies and DLT gateway components with different roles.
5.5.2 Distributed ledger technology (DLT) nodes
A DLT node is a device or process that participates in a network and stores a complete or partial replica
of the ledger records. Connecting directly to a DLT node allows an application to make use of any DLT
interoperability functionality present in the DLT node software (e.g. interfacing with DLT oracle or escrow
smart contracts deployed on the distributed ledger).
Figure 1 shows how an application can use a single DLT node A in order for DLT interoperability between
different DLT systems. In this example, the application is sending transactions to DLT node A and these
transactions are eventually being confirmed on the distributed ledger. Once they are confirmed, it can
trigger an action from a listening DLT interoperability solution.
Figure 1 — An application connecting directly to one DLT node of one DLT system to interact with
multiple DLT systems
An application can also connect to a single DLT node of multiple DLT systems (see Figure 2). In this case, an
additional DLT interoperability solution m+1 can be contained within the application. This solution shall
contain the functionality to implement the desired DLT interoperability mode(s) between DLT system 1 and
DLT system 2. If the DLT systems connected to the application are of different DLT types or incompatible
versions, then the DLT interoperability solution m+1 must handle and resolve the different data models and
interaction methods of each DLT system.
Figure 2 — An application interacting with multiple DLT systems via connecting directly to one DLT
node of multiple DLT systems
From an infrastructure perspective, a single DLT node is not crash resilient and not scalable from a load
balancing perspective. In this case, a DLT node proxy can be considered (see subclause 5.5.3).
5.5.3 Distributed ledger technology (DLT) node proxies
A DLT node proxy is a software component connected to one or more DLT nodes, providing functionality
only present in the DLT node software. A DLT node proxy manages the routing and load balancing issues
between an application and its connected DLT nodes, thus creating logical separation.
To an application, interacting with a DLT node proxy can be identical (or nearly identical) to interacting with
a DLT node as the message requests and responses can be the same. The only possible difference can be
identifying metadata in the messages to track the DLT node proxy users (e.g. for rate limiting reasons). If an
application interacts with a DLT node proxy directly connected to only one DLT system (see Figure 3), then
the application shall use the same DLT interoperability solutions as it would if connecting directly to a single
DLT node (as shown in Figure 1).
Figure 3 — An application connecting directly to a DLT node proxy of one DLT system to interact
with multiple DLT systems
Furthermore, a single DLT node proxy can be directly connected to multiple DLT systems, as long as each DLT
system is of the same type with compatible versions (see Figure 4). This is because compatible DLT systems
have for each function call non-conflicting request and response objects, and so one single pass through
(proxy) can be used for both systems. In this case, an application that interacts with a DLT node proxy directly
connected to multiple DLT systems, should contain an additional interoperability solution m+1. Because the
interaction method and request and response for each system are non-conflicting, interoperability solution
m+1 does not need to handle and resolve the different data models and interaction methods of each DLT
system. Instead, it can instead focus on the implementation of the DLT interoperability mode.
Figure 4 — An application interacting with multiple DLT systems via connecting directly to a DLT
node proxy of multiple DLT systems
Finally, an application can use multiple DLT node proxies, each connected to at least one DLT system (see
Figure 5). Redundancy of DLT proxy components should be considered as part of the DLT interoperability
infrastructure. Having multiple proxies removes a potential central point of failure and does not compromise
the underlying benefit of decentralisation of the blockchain nodes. If each DLT node proxy is connected to
a DLT system of a different DLT type or an incompatible version, then interoperability solution m+1, as well
as implementing the required DLT interoperability mode must handle and resolve the different data models
and interaction methods of each DLT system.
Figure 5 — An application interacting with multiple DLT systems via connecting directly to multiple
DLT node proxies of different DLT systems
5.5.4 Distributed ledger technology (DLT) gateways
A DLT gateway is a software component connected to one or more DLT nodes, providing functionality that is
not present in the DLT node software (see Figure 6). Like a DLT node proxy, a DLT gateway also manages the
routing and load balancing issues between an application and one or more DLT nodes, thus creating logical
separation.
A DLT gateway differs from a DLT node proxy because a gateway provides additional functionality not offered
by the DLT node itself. Such additional functionality can include its own DLT interoperability solution m+2.
As a DLT gateway is not just a pass-through service, interoperability solution m+2 can connect to multiple
DLT systems of different DLT types.
Figure 6 — An application interacting with multiple DLT systems via connecting directly to a DLT
gateway of multiple DLT systems
As described in subclauses 5.5.2 and 5.5.3, an application can also contain a DLT interoperability solution
m+1. If the DLT systems connected to the DLT gateway are of different DLT types, then DLT interoperability
solution m+2 within the application is required to handle and resolve the different data models and
interaction methods of each DLT system if the DLT gateway has not already provided this functionality, via
for example a standardized data model.
Finally, an application can use multiple DLT gateways, each connected to at least one DLT system (see
Figure 7). Redundancy of DLT gateway components should be considered as part of a DLT interoperability
infrastructure. Having multiple gateways removes a potential central point of failure and does not
compromise the underlying benefit of decentralisation of the blockchain nodes. Each DLT gateway can be
connected to a DLT system of a different DLT type or an incompatible version. But as a DLT gateway can
provide additional functionality compared to what is implemented in a node, if DLT gateways i and ii follow
the same interoperability communication standard, the functionality and request and response objects can
be the same no matter what DLT systems the different DLT gateways are connected to. In this case, DLT
interoperability solution m+1 must only implement the required DLT interoperability mode and will not
have to handle or resolve data models and interaction methods.
In Figure 7, only one DLT gateway (i) has an interoperability solution highlighted (m+2) because only this
DLT gateway is connected to multiple DLT systems.
Figure 7 — An application interacting with multiple DLT systems via connecting directly to multiple
DLT gateways of different DLT systems
6 Distributed ledger technology (DLT) interoperability facets
6.1 General
Blockchain and DLT interoperability can be conceptualized using a five-facet model, as detailed in
ISO/IEC 19941. Each facet addresses a specific aspect of the information exchange and use process:
— Transport: Communication protocols and infrastructure. The commonality of the communication
infrastructure established to exchange data between systems.
— Syntactic: Data formats and encodings. The ability of two or more systems or services to understand
the structure of exchanged information, which is an encoding of the domain concepts as defined by the
semantic data facet.
— Semantic data: Common meaning of exchanged data. The ability for the systems exchanging information
to understand the meaning of the data model within the context of a subject area.
— Behavioural: Expected system outputs from data exchange. The ability to ensure that the results from
the use of exchanged information align with expected outcomes.
...
ISO/TC 307
Secretariat: SA
Date: 2025-10-13
Blockchain and distributed ledger technology — Interoperability
framework
ISO #####-#:####(X)
2 © ISO #### – All rights reserved
ISO TS #####-#:####(X/DTS 23516:(en)
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
iii
ISO TS #####-#:####(X/DTS 23516:(en)
Contents
Foreword . v
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Benefits of distributed ledger technology (DLT) interoperability . 4
5 Overview of distributed ledger technology (DLT) interoperability . 5
5.1 General . 5
5.2 Distributed ledger technology (DLT) interoperability scenarios . 5
5.3 Distributed ledger technology (DLT) interoperability modes . 6
5.4 Distributed ledger technology (DLT) interoperability solutions . 7
5.5 Distributed ledger technology (DLT) interoperability infrastructure . 10
6 Distributed ledger technology (DLT) interoperability facets . 17
6.1 General . 17
6.2 Transport facet . 18
6.3 Syntactic facet . 18
6.4 Semantic data facet . 19
6.5 Behavioural facet . 20
6.6 Policy facet . 20
6.7 Facets summary . 21
7 Specific considerations for distributed ledger technology (DLT) interoperability
solutions . 21
7.1 General . 21
7.2 Decentralisation . 22
7.3 Consensus . 23
7.4 Smart contracts . 23
8 Distributed ledger technology (DLT) interoperability architecture . 24
8.1 General . 24
8.2 Inter distributed ledger technology system interoperability architecture . 27
8.3 External non-distributed ledger technology (DLT) system interoperability architecture 30
Annex A (normative) Security . 32
Bibliography . 34
iv
ISO TS #####-#:####(X/DTS 23516:(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 307, Blockchain and distributed ledger
technologies.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
ISO TS #####-#:####(X/DTS 23516:(en)
vi
ISO TS #####-#:####(X/DTS 23516:(en)
Introduction
This document is intended to establish a common understanding of interoperability among distributed ledger
technology (DLT) systems and between DLT systems and non-DLT systems. StandardisationStandardization is
a key enabler of interoperability, which is important for the efficient use and wider adoption of the DLT.
To ensure interoperability of DLT systems, multiple interoperability facets and interoperability layers need
tomust be considered. Establishing a common DLT interoperability framework can increase trust and
adoption. Examples of key DLT interoperability requirements include transferring assets between systems,
preventing invalid transactions and preventing loss of ownership.
vii
Blockchain and distributed ledger technology — Interoperability
Frameworkframework
1 Scope
This document specifies a framework for interoperability between DLT systems, between DLT and entities
outside the DLT system, the relationships and interactions between these and cross-cutting aspects.
32 Normative references
The following documents are referred to in the text in such a way that their content constitutes requirements
of this document. For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO 22739, Blockchain and distributed ledger technologies — Vocabulary
43 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22739 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at http://www.electropedia.org/
4.13.1
3.1
cross authenticated DLT synchronisationsynchronization
cross authenticated distributed ledger technology synchronisation
method to synchronisesynchronize two or more DLT systems (3.14(3.15)) via adding transactions onto each
system
4.33.2 3.2
distributed ledger
ledger that is shared across a set of distributed ledger technology (DLT) nodes (3.10(3.11)) and synchronized
between the DLT nodes using a consensus mechanism
[SOURCE: ISO/IEC 22739:2024, 3.23, modified – Note 1 to entry has been removed]
4.43.3
3.3
DLT
distributed ledger technology
technology that enables the operation and use of distributed ledgers (3.2(3.2))
[SOURCE: ISO/IEC 22739:2024, 3.25]
4.83.4 3.4
DLT gateway
distributed ledger technology gateway
software component connected to one or more DLT nodes (3.10(3.11),), providing functionality that is not
present in the DLT node software
4.103.5 3.5
DLT interoperability
distributed ledger technology interoperability
ability of two or more systems or applications to exchange information and to mutually use the information
that has been exchanged, where at least one of these systems is a DLT system (3.14(3.15))
4.123.6 3.6
DLT interoperability mode
distributed ledger technology interoperability mode
purpose of the information exchanged in the DLT interoperability scenario (3.7(3.8))
4.143.7 3.7
DLT interoperability scenario
distributed ledger technology interoperability scenario
systems or applications that are exchanging information to achieve DLT interoperability (3.5(3.6))
4.163.8 3.8
DLT interoperability solution
distributed ledger technology interoperability solution
DLT solution (3.14(3.14)) built for DLTinteroperability (3.5DLT interoperability (3.6))
4.173.9
3.9
DLT network
distributed ledger technology network
network of DLT nodes (3.10(3.11)) which make up a DLT system (3.14(3.15))
[SOURCE: ISO/IEC 22739:2024, 3.30]
4.193.10 3.10
DLT node
distributed ledger technology node
device or process that participates in a network and stores a complete or partial replica of the ledger records
[SOURCE: ISO/IEC 22739:2024, 3.31]
4.213.11 3.11
DLT node proxy
distributed ledger technology node proxy
software component connected to one or more DLT nodes (3.10(3.11),), providing functionality only present
in the DLT node software
4.223.12
3.12
DLT oracle
distributed ledger technology oracle
service that updates a distributed ledger (3.2(3.2)) using data from outside of a DLT system (3.14(3.15))
[SOURCE: ISO/IEC 22739:2024, 3.32, modified – Note 1 to entry has been removed].]
4.233.13
3.13
DLT solution
distributed ledger technology solution
solution built using a DLT system (3.14(3.15)) to accomplish some business objectives common to a group of
DLT users (3.15(3.16))
[SOURCE: ISO/IEC 22739:2024, 3.34, modified – Note 1 to entry has been removed].]
4.243.14
3.14
DLT system
distributed ledger technology system
system that implements a distributed ledger (3.2(3.2))
[SOURCE: ISO/IEC 22739:2024, 3.35]
4.253.15
3.15
DLT user
distributed ledger technology user
entity that uses services provided by a DLT system (3.14(3.15) )
[SOURCE: ISO/IEC 22739:2024, 3.36]
4.273.16 3.16
interoperability
ability of two or more systems or applications to exchange information and to mutually use the information
that has been exchanged
[SOURCE: ISO/IEC 22123-1:2023, 3.6.1]
114 Benefits of distributed ledger technology (DLT) interoperability
Benefits from DLT interoperability can include:
— interaction between permissioned and permissionless DLT networks;
— exchange of data between systems;
— availability of consistent data;
— synchronization of state between systems;
— ensuring authenticity, integrity and confidentiality of data exchanged at the same time;
— transferability of digital assets;
— non-duplication of digital assets;
— minimising the potential for technology lock-in;
— cross-jurisdictional data flows and compliance.
125 Overview of DLTdistributed ledger technology (DLT) interoperability
12.15.1 General
When addressing DLT interoperability, the following should be considered:
— What are the systems or applications that are exchanging information? (See 5.25.2.).)
— Why are they exchanging information? (See 5.35.3.) .)
— How is this information exchanged? (See 5.45.4 and 5.55.5.).)
The additional sections describe the different DLT interoperability facets (see Clause 6Clause 6),), highlight
specific considerations for DLT interoperability solutions (see Clause 7Clause 7)) and detail DLT
interoperability architecture concerns (see Clause 8Clause 8).).
12.35.2 DLTDistributed ledger technology (DLT) interoperability scenarios
DLT interoperability is required to involve at least one DLT system. There are various DLT interoperability
scenarios:
— Connecting a DLT system to non -DLT system: This scenario has the widest scope. DLTs are a modern
invention, but there are many other types of system. Connecting a DLT system to a non -DLT system can
therefore be a complex and widely varying task.
— Connecting two DLT systems of different DLT types: DLTs come in many forms (types). Connecting two
DLT systems of different DLT types can also be a complex and widely varying task. How big the task is
depends on a variety of factors, including: the DLT data structures, such as the Unspent Transaction
Outputunspent transaction output (UTXO) model or the accounts model; the type of smart contracts
allowed, e.g. Turing complete language, non-Turing complete language or no smart contracts at all; and
how identity is managed, such as via public/ and private key pairs only or via a public key infrastructure
utilising certificates.
— Connecting two DLT systems of the same DLT type but with incompatible versions: DLTs release multiple
versions, and not all versions are backwards compatible. For example, a DLT node running a particular
version cannot interact with a DLT node running a different version. This incompatibility creates
integration issues. But integration is more complicated when the two DLT systems use different DLT types.
This is because even though the versions are incompatible, both DLT systems will inevitability have many
commonalities.
— Connecting two DLT systems of the same DLT type and compatible versions: If two different DLT systems
use the same DLT type with compatible versions, integrating them becomes significantly easier. This is
because both systems use the same syntactic model; any semantic integration challenges between the
systems should be similar to integrating two applications that use the same DLT system.
12.55.3 DLTDistributed ledger technology (DLT) interoperability modes
DLT interoperability involves different modes of interoperation for transferring or exchanging assets and
data. The three main interoperability modes are:
— Data transfer: Data is copied, with an optional intermediate processing step, from an external source
system into a destination system. Such data can include state information or data representing logic or
code. For example, the token price information from a decentralised exchange on one DLT system can be
copied into another DLT system. Data transfer usually requires at least one transaction on the distributed
ledger of the destination DLT system.
— Asset transfer: An asset record can be created on a destination system as an exclusive replacement or
exclusive alternate form of control for an asset record that is locked or burned (destroyed) on a source
system. For convenience, this is called “asset transfer” in this document, although whether the legal
transfer of an asset is effected by this mechanism can depend both on the nature of the asset records in
these systems and on legal or regulatory situations in relevant jurisdictions. This asset transfer
interoperability can be used to change of ownership of assets. It also can be used to manage control over
an asset or process. In a DLT system, tokens are often used to represent assets. Tokens that are minted
(created) can be called wrapped tokens, if these tokens take their value from the locked source asset. For
example, a token can be locked to a multi-signature address on one DLT and a representative asset (e.g. a
wrapped token) can be minted on a different DLT system. Asset transfer requires at least one transaction
on the distributed ledger of the destination DLT system and usually at least one transaction on the
distributed ledger of the source DLT system.
— Asset exchange: Assets are exchanged between accounts in their respective systems, i.e. no transfers
across systems occurs. Participants are required to have an account in both systems for this exchange to
occur. For example, swapping tokens on a DLT system for different tokens on a different DLT system
between two parties who both have accounts on both systems. Asset exchanges typically require two
transactions on the distributed ledger of each DLT system involved in the exchange: one transaction to
escrow (lock) the asset and another transaction to (unlock and) send the asset to its final destination.
Both asset transfers and asset exchanges can be permanent or temporary:
— Permanent asset transfer: The asset record is burned (destroyed) on the source system when the
replacement asset record is minted (created) on the destination system.
— Temporary asset transfer: The asset record is locked on the source system before a corresponding asset
record is minted (created) on the destination system. If a reversing asset transfer is performed at a later
time, that minted asset record can be destroyed and the original asset record can be unlocked.
— Permanent asset exchange: Assets are exchanged between parties with no obligation to reverse the
exchange later. For example, the purchase of an asset on one system using money on another system.
— Temporary asset exchange: Assets are exchanged between parties where the conditions to reverse the
swap are in place. For example, a cross-ledger loan where one party escrows or locks an asset on one
system as collateral while using an asset on another DLT system for a limited time.
12.75.4 DLTDistributed ledger technology (DLT) interoperability solutions
12.7.15.4.1 General
DLT interoperability solutions are categorized according to the approach used for achieving interoperability.
Two common technically non-overlapping approaches to DLT interoperability are DLT oracles (see
5.4.25.4.2)) and cross authenticated DLT synchronization (see 5.4.4synchronisation (5.4.4).).
12.7.35.4.2 Distributed ledger technology (DLT) oracles
DLT oracle solutions are used for both the data transfer and asset transfer DLT interoperability modes.
A DLT oracle is a service that updates a distributed ledger using external data. DLT oracles therefore allow
data (including assets) to move from a source external system into a destination DLT system, where the source
system can be a DLT system. Oracles fetch data according to certain triggers (e.g. a transaction being added
onto a DLT system or certain local configuration parameters). Before this fetched data is added onto the
destination DLT system, it can be processed for syntactic, semantic, behavioural or policy reasons.
A DLT oracle has one or more operators who are responsible for running the service. Each DLT oracle can be
thought of as a connection between two systems, one of which is a DLT system. All DLT oracles move data
from one system to another. DLT oracle operators can run the entirety of the service (gather the data from the
source system, optionally process the data and add it to the destination system). Alternatively, a DLT oracle
can contain two or more groups of operators: one group for gathering the data from the source system,
another group to add the data onto the destination DLT system and other possible intermediate groups for
additional processing.
There are two general types of DLT oracles:
b)a) Data transfer oracles: These services move data from a source system to a destination system. The
semantic meaning of this data on the destination DLT system depends on the use case.
c)b) Asset transfer oracles: These services are concerned with transferring representations of value. They
move data from a source system to a destination system, where the semantic meaning of this data is an
asset originally represented on the source system but now to be represented on the destination DLT
system.
DLT oracles are required because code deployed into a distributed ledger cannot access external resources
without the help of an intermediary. These intermediaries (DLT oracles) gather external data, usually placing
it into transactions that are subsequently added to the distributed ledger, therefore allowing this retrieved
data to be read by deployed smart contracts. Fetched data can also be placed in non-transaction locations,
such as in block headers.
DLT oracles can operate in either a push or pull model to transfer data and assets between systems. DLT
oracles have different workflows based on push/ and pull models and the type of destination DLT system.
These architectural differences enable various cross-system data and asset transfer patterns.
— Push-based data transfer oracles: These services add data from an external system onto a destination DLT
system without an explicit request from a transaction on the destination DLT system. Instead, these
oracles fetch data according to requests external from the destination DLT system, such as local
configuration parameters or API calls.
— Pull-based data transfer oracles: These services fetch data from a source system and add the data to a
destination DLT system. They operate upon receiving a request from a transaction on the destination DLT
system. Pull-based data transfer oracles operate differently depending on the transaction execution model
of the DLT:
— Order-validate-execute model: Pull-based data transfer oracles on these DLT systems require multiple
transactions to complete the data transfer process. The first transaction is placed on the destination
DLT system to request the external data. A second transaction, including the requested data, is added
onto the destination DLT system. A third transaction can be required to use the requested data.
— Execute-order-validate model: Pull-based data transfer oracles on these DLT systems only require one
transaction to complete the data request process as the data is fetched from the source system by the
DLT nodes, before the transaction requesting this data is signed and finalised in the ledger.
— Push-based asset transfer oracles: These services add data (representing assets) onto a destination DLT
system without an explicit request from a transaction on the destination DLT system. Instead, these
oracles fetch data (representing assets) according to requests external from the destination DLT system,
such as local configuration parameters, API calls or a transaction on the source DLT system.
— Pull-based asset transfer oracles: These services fetch data (representing assets) from a source system
and add the data to a destination DLT system. They operate upon request from a transaction on the
destination DLT system. Pull-based asset transfer DLT oracles can only operate from a source system
whose current state is dependent on the destination DLT system (such as layer 2 networks or sidechains).
This is because changes on the destination DLT system can indirectly affect state changes on the source
system allowing tokens on the source system to be locked or burned according to transactions on the
destination system.
An individual user can run their own DLT oracle (i.e. be a DLT oracle operator) as long as that user has access
to both the source and destination systems. But the operators of each DLT oracle need tomust convince other
users of the validity of data (or assets) moved via this oracle in order for the transferred data to have any
value.
12.7.55.4.3 Distributed ledger technology (DLT) oracle use cases
While most actions that occur in a DLT system are deterministic, oracles encompass and isolate non-
deterministic data feeds and real-world information that the DLT system cannot detect on its own. A DLT
oracle can therefore be used to feed information into a DLT system, such as price feeds of real-world assets,
which can then be consumed by other smart contracts and services running on the DLT system. DLT oracles
can also be used to connect DLT systems to real-world actions that occur. DLT oracle use cases can include:
— prediction markets on real-world events;
— price feeds for real-world assets;
— location tracking for real-world items;
— payment confirmation events;
— sensor data verification for supply chains;
— shared registries.
Another common use case for connecting an external system to a DLT system is for “proof of existence”.
Embedding the cryptographic hash of a digital document into a DLT system can allow parties to later verify
that the document existed at that earlier time.
When a DLT oracle is used to connect a DLT system to another DLT system, the use cases can be similar to
when a non -DLT system is being connected to a DLT system. For example, price data from one DLT system
can be placed on another DLT system, or blocks of one DLT system can be timestamped on the other DLT
system if certain block data (e.g. a block’s hash) is placed on the second DLT system.
Additionally, as stated previously, DLT oracles can be used for transferring assets from one system to another,
so a common use case is DLT system to DLT system asset transfers.
12.7.75.4.4 Cross authenticated distributed ledger technology (DLT synchronisation)
synchronization
Cross authenticated DLT synchronisationsynchronization solutions are used for the asset exchange
interoperability mode. They allow parties to exchange assets across systems, where each party adds a
transaction on each DLT system. To this end, parties need tomust authenticate on each system to perform the
transfers, and these authenticated transactions on the different systems are used to synchronisesynchronize
the relevant data so that the exchange can complete atomically. This process can happen in a peer-to-peer
manner or via additional mediators.
Peer-to-peer asset exchanges correspondscorrespond to one asset exchange with non-mediated
communication. The typical method for implementing this scheme is via hash lock time contracts (HTLCs),
where both parties deploy (or utiliseutilize) a smart contract in each chain that transfers the right number of
coins to the other party. But other non -HTLC solutions exist, such as universal atomic swaps.
On the other hand, mediated asset exchanges are cross authenticated DLT synchronisationsynchronization
solutions with additional mediator(s). In these types of exchanges, users add a transaction onto the distributed
ledgers to escrow their assets with the mediator(s) who are subsequently responsible for adding more
transactions onto the distributed ledgers to complete the swap correctly.
12.7.95.4.5 Cross authenticated distributed ledger technology (DLT synchronisation)
synchronization use cases
Cross authenticated DLT synchronisationsynchronization interoperability solutions can be used between a
DLT system and a non -DLT system, e.g. when a DLT based asset is to be exchanged with a non -DLT based
asset. As a non -DLT system is involved, this cross-authentication solution has tomust be at least partially
mediated via a third party. CentralisedCentralized exchanges are an example of this type of mediator-based
DLT interoperability solution for swaps of DLT assets for money, while peer-to-peer asset exchanges aim to
achieve DLT asset swaps without a mediator, often for privacy or trust reasons.
12.95.5 DLTDistributed ledger technology (DLT) interoperability infrastructure
12.9.15.5.1 General
Every DLT interoperability solution shall be built against an infrastructure that can allow DLT interoperability
functionality to occur between different DLT systems. DLT interoperability infrastructure consists of DLT
nodes, DLT proxies and DLT gateway components with different roles.
12.9.35.5.2 Distributed ledger technology (DLT) nodes
A DLT node is a device or process that participates in a network and stores a complete or partial replica of the
ledger records. Connecting directly to a DLT node allows an application to make use of any DLT
interoperability functionality present in the DLT node software (e.g. interfacing with DLT oracle or escrow
smart contracts deployed on the distributed ledger).
Figure 1
Figure 1 shows how an application can use a single DLT node A in order for DLT interoperability between
different DLT systems. In this example, the application is sending transactions to DLT node A and these
transactions are eventually being confirmed on the distributed ledger. Once they are confirmed, it can trigger
an action from a listening DLT interoperability solution.
Figure 1: an — An application connecting directly to one DLT node of one DLT system to interact with
multiple DLT systems
An application can also connect to a single DLT node of multiple DLT systems (see Figure 2Figure 2).). In this
case, an additional DLT interoperability solution m+1 can be contained within the application. This solution
shall contain the functionality to implement the desired DLT interoperability mode(s) between DLT system 1
and DLT system 2. If the DLT systems connected to the application are of different DLT types or incompatible
versions, then the DLT interoperability solution m+1 will need tomust handle and resolve the different data
models and interaction methods of each DLT system.
Figure 2: an — An application interacting with multiple DLT systems via connecting directly to one
DLT node of multiple DLT systems
From an infrastructure perspective, a single DLT node is not crash resilient and not scalable from a load
balancing perspective. In this case, a DLT node proxy can be considered (see subclause 5.5.3section 5.5.3).).
12.9.55.5.3 Distributed ledger technology (DLT) node proxies
A DLT node proxy is a software component connected to one or more DLT nodes, providing functionality only
present in the DLT node software. A DLT node proxy manages the routing and load balancing issues between
an application and its connected DLT nodes, thus creating logical separation.
To an application, interacting with a DLT node proxy can be identical (or nearly identical) to interacting with
a DLT node as the message requests and responses can be the same. The only possible difference couldcan be
identifying metadata in the messages to track the DLT node proxy users (e.g. for rate limiting reasons). If an
application interacts with a DLT node proxy directly connected to only one DLT system (see Figure 3Figure
3),), then the application shall use the same DLT interoperability solutions as it would if connecting directly to
a single DLT node (as shown in Figure 1Figure 1). ).
Figure 3: an — An application connecting directly to a DLT node proxy of one DLT system to interact
with multiple DLT systems
Furthermore, a single DLT node proxy can be directly connected to multiple DLT systems, as long as each DLT
system is of the same type with compatible versions (see Figure 4Figure 4).). This is because compatible DLT
systems have for each function call non-conflicting request and response objects, and so one single pass
through (proxy) can be used for both systems. In this case, an application that interacts with a DLT node proxy
directly connected to multiple DLT systems, should contain an additional interoperability solution m+1.
Because the interaction method and request and response for each system are non-conflicting,
interoperability solution m+1 does not need to handle and resolve the different data models and interaction
methods of each DLT system. Instead, it can instead focus on the implementation of the DLT interoperability
mode.
Figure 4: an — An application interacting with multiple DLT systems via connecting directly to a DLT
node proxy of multiple DLT systems
Finally, an application can use multiple DLT node proxies, each connected to at least one DLT system (see
Figure 5Figure 5).). Redundancy of DLT proxy components should be considered as part of the DLT
interoperability infrastructure. Having multiple proxies removes a potential central point of failure and does
not compromise the underlying benefit of decentralisation of the blockchain nodes. If each DLT node proxy is
connected to a DLT system of a different DLT type or an incompatible version, then interoperability solution
m+1, as well as implementing the required DLT interoperability mode will need tomust handle and resolve the
different data models and interaction methods of each DLT system.
Figure 5: an — An application interacting with multiple DLT systems via connecting directly to
multiple DLT node proxies of different DLT systems
12.9.75.5.4 Distributed ledger technology (DLT) gateways
A DLT gateway is a software component connected to one or more DLT nodes, providing functionality that is
Figure 6).). Like a DLT node proxy, a DLT gateway also
not present in the DLT node software (see Figure 6
manages the routing and load balancing issues between an application and one or more DLT nodes, thus
creating logical separation.
A DLT gateway differs from a DLT node proxy because a gateway provides additional functionality not offered
by the DLT node itself. Such additional functionality can include its own DLT interoperability solution m+2. As
a DLT gateway is not just a pass-through service, interoperability solution m+2 can connect to multiple DLT
systems of different DLT types.
Figure 6: an — An application interacting with multiple DLT systems via connecting directly to a DLT
gateway of multiple DLT systems
As described in subclauses 5.5.2sections 5.5.2 and 5.5.35.5.3,, an application can also contain a DLT
interoperability solution m+1. If the DLT systems connected to the DLT gateway are of different DLT types,
then DLT interoperability solution m+2 within the application is required to handle and resolve the different
data models and interaction methods of each DLT system if the DLT gateway has not already provided this
functionality, via for example a standardisedstandardized data model.
Finally, an application can use multiple DLT gateways, each connected to at least one DLT system (see
Figure 7Figure 7).). Redundancy of DLT gateway components should be considered as part of a DLT
interoperability infrastructure. Having multiple gateways removes a potential central point of failure and does
not compromise the underlying benefit of decentralisation of the blockchain nodes. Each DLT gateway can be
connected to a DLT system of a different DLT type or an incompatible version. But as a DLT gateway can
provide additional functionality compared to what is implemented in a node, if DLT gateways i and ii follow
the same interoperability communication standard, the functionality and request/ and response objects can
be the same no matter what DLT systems the different DLT gateways are connected to. In this case, DLT
interoperability solution m+1 willmust only need to implement the required DLT interoperability mode and
will not have to handle or resolve data models and interaction methods.
In Figure 7Figure 7,, only one DLT gateway (i) has an interoperability solution highlighted (m+2) because only
this DLT gateway is connected to multiple DLT systems.
Figure 7: an — An application interacting with multiple DLT systems via connecting directly to
multiple DLT gateways of different DLT systems
146 DLTDistributed ledger technology (DLT) interoperability facets
14.16.1 General
Blockchain and DLT interoperability can be conceptualized using a five-facet model, as detailed in ISO/IEC
19941. Each facet addresses a specific aspect of the information exchange and use process:
— Transport: Communication protocols and infrastructure. The commonality of the communication
infrastructure established to exchange data between systems.
— Syntactic: Data formats and encodings. The ability of two or more systems or services to understand the
structure of exchanged information, which is an encoding of the domain concepts as defined by the
semantic data facet.
— Semantic data: Common meaning of exchanged data. The ability for the systems exchanging information
to understand the meaning of the data model within the context of a subject area.
— Behavioural: Expected system outputs from data exchange. The ability to ensure that the results from the
use of exchanged information align with expected outcomes.
— Policy: Governing rules and regulations. The ability of two or more systems to interoperate while
complying with the legal, organizational and policy frameworks applicable to the participating systems.
The five facets of interoperability are independent of each other and can be considered separately.
This five-facet model is intended to cover all the aspects of interoperability.
In 6.26.2 to 6.76.7,, each facet is discussed regarding how it affects the interoperation for each DLT
interoperability scenario, summarised in Table 1Table 1.
14.36.2 Transport facet
DLT is often thought of operating in an internet-based environment. However, DLT can operate in other
networking environments as well. The transport facet deals with the communications infrastructure, i.e. how
to get bytes of data from one system to another. This includes the networking hardware, such as ethernet, Wi-
Fi, broadband (xDSL), satellite, etc. It also includes the transport protocol used, such as HTTP(S), AMQP, MQTT,
Kafka, etc. If the transport facets do not align between two systems, then some form of protocol conversion is
likely to be required.
All DLT interoperability scenarios need tomust consider this facet as it is a basic component of system
integration. A transport layer between the first and second system shall be established along with rules for
when and how this transport occurs, as well as what is contained in this data transport. For example, what is
the event in system A that triggers data added to system B, and what exact data is transported.
14.56.3 Syntactic facet
Syntactic interoperability means that the formats of the exchanged information can be understood by the
participating systems. The focus is on the “syntax of the data". The syntax of the data is ideally the same for
the source system and the destination system. However, if the syntax does not match (e.g. the source uses
JSON syntax but the target uses XML), it can be possible to map the data using commonly available tools.
When considering the syntactic facet:
— DLT systems of the same DLT type and compatible versions: typically face no issues related to syntactic
data interoperability.
— DLT systems of the same DLT type but with incompatible versions: can encounter minor syntactic data
interoperability challenges.
— Interoperability between DLT systems of different types: can present significant syntactic data
interoperability hurdles. The magnitude of these challenges depends on various factors, including the
DLT's data structure (e.g. UTXO or Accounts), the nature of smart contracts supported (whether they use
a Turing-complete language, a non-Turing-complete language or no smart contracts at all) and the
approach to identity management (e.g. solely via public/private key pairs or through a public key
infrastructure utilizing certificates).
— Interopera
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...