ISO/TR 6277:2025

Technical
Report
ISO/TR 6277
Second edition
Blockchain and distributed ledger
2025-05
technologies (DLT) — Data flow
models for blockchain and DLT
use cases
Technologies des chaînes de blocs et technologies de registre
distribué — Modèles de flux de données pour les chaînes de blocs
et les cas d'utilisation de DLT
Reference number
© ISO 2025
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Overview of data flow for DLT . 3
5.1 General .3
5.2 Categories of data flows .4
5.3 Data categories .4
5.3.1 General .4
5.3.2 Data categories from data storage perspective .4
5.3.3 Data categories from data sources perspective .5
5.3.4 Identifier data categories .6
5.3.5 Other data categories .6
5.4 Roles from the perspective of data flow .7
5.4.1 DLT stakeholder roles and stakeholder data .7
5.4.2 Roles/sub-roles and their activities related to data flow .7
5.5 Considerations related to data flow .8
5.5.1 Data security .8
5.5.2 Privacy protection .8
5.5.3 Governance of data .9
5.5.4 Interoperability .9
6 Intra-system data flow . 9
6.1 Overview .9
6.2 Data flow during DLT transaction procedure .10
6.2.1 Preliminary stage .10
6.2.2 Full life cycle data flow in one transaction .11
6.2.3 Overview of data process within DLT system . 12
7 Inter-system data flow .13
7.1 Data flows between DLT system and DLT system . 13
7.1.1 Outline . 13
7.1.2 Transaction submission .14
7.1.3 Transaction execution with eventual consistency .14
7.1.4 Result feedback . .14
7.1.5 Overview of data process between DLT system and DLT system .14
7.2 Data flows between DLT system and non-DLT system . 15
7.3 Data flow of DID . 15
8 Data flow analysis in DLT use cases .16
8.1 Overview .16
8.2 Template development . .16
8.2.1 DLT data flow categories between components and interfaces.16
8.2.2 DLT use case categories .17
8.2.3 Data flow description in DLT use cases .21
8.3 Use case: Insurance service for fish farming . 23
8.3.1 Abstract . 23
8.3.2 Use case categories . . . 23
8.3.3 Use case summary .24
8.3.4 Data flow considerations .24
8.3.5 Visualizations . 25
8.4 Use case: International trade platform . 30
8.4.1 Abstract . 30

iii
8.4.2 Use case categories . . . 30
8.4.3 Use case summary .31
8.4.4 Data flow considerations .32
8.4.5 Visualizations .32
8.5 Use case: Peer-to-peer metaverse traveller network .37
8.5.1 Abstract .37
8.5.2 Use case categories . . . 38
8.5.3 Use case summary . 39
8.5.4 Data flow considerations . 39
8.5.5 Visualizations . 40
Annex A (informative) Use case for data flow analysis — Example .46
Bibliography .49

iv
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
Introduction
This document consolidates a set of system-level models from ISO 23257 and ISO/TR 3242 to give a data-
flow-centric description framework for blockchain and distributed ledger technology (DLT) use cases. The
framework enables a data flow analysis approach for blockchain and DLT use cases which has been defined
in ISO 23257, successfully applied across all use cases in ISO/TR 3242 and extended in this document to
display more detailed information on data flows.
The robust descriptive capabilities provided by this framework can help to improve blockchain and DLT
application design and enhance interoperability. This can be beneficial for:
— clear understanding of data types and data flows in distributed ledger systems that allows for better-
designed, fit-for-purpose systems;
— better governance and risk management;
— a sound basis for interoperability modelling for the use cases that require data exchange in hybrid or
orchestrated systems environment.
Understanding data flows can be a necessary foundation for DLT users to ensure data privacy and data
confidentiality in DLT use cases, or a decision-making basis when implementing technology selection or
scheme assessment. From this perspective, data flow analysis is especially essential to scenarios which
frequently involve data flows among stakeholders or devices. To illustrate the features of data flows in
DLT use cases with the above characteristics, this document provides three uses cases which apply the
description framework to unfold data flows among devices, data flows along with business process, as well
as data flows between physical and virtual spaces. These use cases can also provide an insight into the role
of data flow analysis in balancing business value maximization and risk controls.
This document is organized as follows:
— Clause 5 presents an overview of DLT data flows, including data flow categories, data categories, roles/
subroles and considerations related to data flow.
— Clause 6 and Clause 7 provide analysis of typical intra-system and inter-system data flows for DLT
systems.
— Clause 8 provides three DLT use cases based on a descriptive and visualization template focusing on
data flows.
vi
Technical Report ISO/TR 6277:2025(en)
Blockchain and distributed ledger technologies (DLT) — Data
flow models for blockchain and DLT use cases
1 Scope
This document uses a set of models that describe the flows of different types of data between distributed
ledger technologies (DLT) and related systems, as well as between different DLT nodes.
It provides a descriptive analysis of data flows in the development of use cases, as well as the basis for
understanding the characteristics of DLT data flows, to support DLT application design and system analysis.
The models referenced are in accordance with ISO 23257 and the use case analysis approach provided in
ISO/TR 3242.
2 Normative references
The following documents are referred to in the text in such a way that some or all of 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
ISO 23257, Blockchain and distributed ledger technologies — Reference architecture
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22739, ISO 23257 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 https:// www .electropedia .org/
3.1
cloud computing
paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources
with self-service provisioning and administration on-demand
Note 1 to entry: Examples of resources include servers, operating systems, networks, software, applications, and
storage equipment.
Note 2 to entry: Self-service provisioning refers to the provisioning of resources provided to cloud services performed
by cloud service customers through automated means.
[SOURCE: ISO/IEC 22123-1:2023, 3.1.1]
3.2
data category
class of data items that are closely related from a formal or semantic point of view
[SOURCE: ISO 30042:2019, 3.8, modified — Example and Notes 1 and 2 to entry deleted.]

3.3
data flow
sequence in which data transfer, use and transformation are performed during the execution of a
computer program
[SOURCE: ISO 23257:2022, 3.5]
3.4
decentralized identifier
DID
identifier that is issued and managed in a decentralized system and designed to be unique within a context
Note 1 to entry: Decentralized identifiers are used in systems that do not rely on central registration authorities.
[SOURCE: ISO 22739:2024, 3.18]
3.5
derived data
data created as a result of processing that involves steps other than or in addition to direct retrieval and
validation of information from data functions
[SOURCE: ISO/IEC 20926:2009, 3.17]
3.6
edge
boundary between pertinent digital and physical entities delineated by networked sensors and actuators
Note 1 to entry: Pertinent digital entities means that the digital entities which need to be considered can vary
depending on the system under consideration and the context in which those entities are used.
[SOURCE: ISO/IEC TR 23188:2020, 3.1.2]
3.7
end user identifiable information
EUII
derived data associated with a user that is captured or generated from the use of the service by that user
Note 1 to entry: Data that is linked to the user but is not distributed ledger technology user data.
Note 2 to entry: End user identifiable information includes connectivity data, usage data.
[SOURCE: ISO/IEC 19944-1:2020, 3.1.2, modified — Notes 1 and 2 to entry added.]
3.8
role
set of activities that serves a common purpose
[SOURCE: ISO/IEC 22123-1:2023, 3.3.10]
3.9
smart contract
computer program stored in a distributed ledger technology system wherein the outcome of any execution
of the program is recorded on the distributed ledger
Note 1 to entry: A smart contract can represent terms in a contract in law and create a legally enforceable obligation
under the legislation of an applicable jurisdiction.
[SOURCE: ISO 22739:2024, 3.88]
3.10
sub-role
subset of the activities of a given role
[SOURCE: ISO/IEC 22123-1:2023, 3.3.11]

3.11
transaction record
record documenting a transaction of any type
Note 1 to entry: Transaction records can be included in, or referred to, in a ledger record.
Note 2 to entry: Transaction records can include the result of a transaction.
[SOURCE: ISO 22739:2024, 3.95]
4 Abbreviated terms
API application programming interface
DID decentralized identifier
DLT distributed ledger technology
ICT information and communications technology
IoT internet of things
NEC not elsewhere classified
NFT non-fungible token
PIA privacy impact assessment
PII personal identifiable information
PoC proof of concept
SDG sustainable development goal
SME small and medium-sized enterprise
UML unified modelling language
VC verifiable credential
5 Overview of data flow for DLT
5.1 General
The impetus for introducing DLT-specific data flow models is to support technical and business process
analysis. The models mentioned in this document are in accordance with ISO 23257 and applied across all
use cases in ISO/TR 3242 combined with the behavioural UML models (see Reference [6] and Reference [15]).
The focus on the approach in this document is exploring diverse ways of applying it to data flow analysis
on DLT use cases. The approach taken in this document derives from architectural approaches in cloud
computing (see Reference [9]) and service-oriented design. If a service model is a collection of components
that represents a business service, a data flow model that is described across component-based view of a
system can help bring clarity to both technical and business objectives in system design.
It can be seen in ISO/TR 3242 and elsewhere that applications and systems deploy blockchain and DLT to
provide robust and purposeful system transparency in highly distributed, multi-party systems, on cloud-
based execution environments. The data flow models reviewed here can be used in tandem with service-
modelling approaches to gain greater insight into system functionality and business process performance.

5.2 Categories of data flows
ISO 23257 and ISO/TR 3242 identify five fundamental data flows relative to DLT systems:
— Data flow N: Data flowing within and between the nodes of the DLT system;
— Data flow A: Data flowing between separate DLT systems when they interoperate;
— Data flow B: Data flowing between a DLT system and non-DLT systems connected to it;
— Data flow C: Data flowing between administration applications and a DLT system;
— Data flow D: Data flowing between user applications and a DLT system.
NOTE ISO 23257 defines Data flow Z as data flowing among the nodes of the DLT system. ISO/TR 3242 includes
data flow within the nodes of the DLT system and defines Data flow Z as data flowing within and between the nodes
of the DLT system. This document adopts the definition in ISO/TR 3242 and uses the code N instead of Z to avoid
confusion.
5.3 Data categories
5.3.1 General
This document identifies data categories in the DLT ecosystems to help users understand DLT data flows
and to support transparency about DLT data. A data taxonomy is also useful for the conversation about data
between different roles/sub-roles. This document provides the following four sets of data categories:
— data categories from data storage perspective;
— data categories from data sources;
— identifier data categories;
— other data categories.
5.3.2 Data categories from data storage perspective
5.3.2.1 General
In order to balance the advantages and performance of DLT systems, off-ledger data storage has increasingly
become a common auxiliary way of data storage in DLT system, especially in the DLT applications involving
large amount of DLT user data.
The main concern for on-ledger data and off-ledger data is the difference of scope of data processing and use.
In most cases, processing and use of off-ledger data have not much difference with data in other types of IT
systems. However, it is usually impossible to delete on-ledger data, which makes it more crucial to provide
specific ways of ensuring transparency and privacy protection.
5.3.2.2 On-ledger data
On-ledger data are data stored inside a DLT system, which includes small amounts of data from DLT users. Due
to the size-limit of DLT ledger, on-ledger data can also include hashes related to off-ledger data from DLT users.
5.3.2.3 Off-ledger data
For large amounts of data from DLT users, or PII which can later be deleted or updated by the PII principal, it
is common practice to store the data on a cloud on the user’s infrastructure or a public storage provided by
a third party or network. Off-ledger data also includes data from the DLT provider and data derived when a
DLT application is used (see Figure 1).

Figure 1 — Data categories from storage perspective
5.3.3 Data categories from data sources perspective
5.3.3.1 General
ISO 23257 defines six DLT roles, including DLT developers, DLT administrators, DLT users, DLT providers,
DLT governors and DLT auditors. Among these DLT roles, DLT administrators, DLT users and DLT providers
are most closely related to DLT data. In order to support different stakeholders to carry out data-related
activities, or to formulate data-related policies, this document identifies seven data categories which are
associated to different DLT roles (see Figure 2).
Figure 2 — DLT stakeholder roles and related DLT data categories (reproduced from ISO 23257 and
ISO/TR 3242)
5.3.3.2 Transaction record
A transaction record can be financial transaction data or generalized transaction data, such as genome data,
voter record, transport data and product production data. Transaction records can be on-ledger data or off-
ledger data with related hashes stored on ledger. A transaction record is generated when a DLT user uses a
DLT system to record a transaction.
5.3.3.3 DLT account data
A smart contract or digital asset, for example, can be associated with a DLT account. Corresponding DLT
account data are data representing an entity whose data are recorded on a DLT system. DLT account data
are generated or updated when a DLT user creates a DLT account or uses the account.
5.3.3.4 End user identifiable information
End user identifiable information is linkage to the user but is not directly created by DLT users. End user
identifiable information includes connectivity data, usage data.

5.3.3.5 Operations data
Operations data are data used for supporting the operation of DLT system, which include service logs,
configuration data.
5.3.3.6 Access and authentication data
Access and authentication data are data used within DLT system to manage access DLT capabilities, DLT
data or smart contract, which includes passwords, cryptographic keys and security certificates. Access and
authentication data are controlled by DLT administrators and are critical to its administrative activities.
5.3.3.7 Smart contract data
Smart contract data includes not only executable codes of program but also execution results. Smart contract
data can be generated when a DLT developer creates or maintains the smart contract, or a DLT operator
runs the smart contract.
5.3.3.8 Derived data
Derived data include data describing the connections of the DLT system, data describing the usage of the
DLT services, etc. Derived data also include end user identifiable information.
5.3.4 Identifier data categories
ISO/TR 6039 specifies identifiers data including:
— Subject identifiers: Natural persons and legal entities used by administrations of countries for specific
(international) government functions and in some industries. Subjects are entities with rights and
obligations.
— Object identifiers: Object identifiers used for government purposes and in several industries. Objects are
entities without rights and obligations.
5.3.5 Other data categories
5.3.5.1 Overview
There are many other types of data and data types of selected examples that are important in financial use
cases are presented in 5.3.5.2, 5.3.5.3 and 5.3.5.4.
5.3.5.2 Market price data
Market prices are available for many objects. These include, but are not limited to:
— stock prices of listed companies at exchanges;
— currency rates of foreign exchange markets;
— commodity prices for commodity markets;
— derivatives rates;
— interest rates (central banks reference rates and market rates);
— prices of retailers and web-retailers for goods and services.

5.3.5.3 Accountancy data categories
Accountancy data include, but are not limited to:
— Stock data: Accountants use specific terminology included in Reference [13] which uses a balance sheet
that can be presented in an annual report. These stock data include: the value of the goods, debtor
position, creditors position presented on the balance sheet. The stock data covers the aggregation of
data at a certain point in time.
— Flow data: Accountants use terminology included in Reference [13] for flow data such as a) profit and
loss account and b) cashflow statement. Flow data includes the flow of values, as they change over time,
during a predefined time period.
5.3.5.4 Message data in networks
Message data are data in messages which can be structured or unstructured. The (industry) networks
used for business to government or for business-to-business purposes include mostly instructions on the
structure of the data messages used in the network involved.
5.4 Roles from the perspective of data flow
5.4.1 DLT stakeholder roles and stakeholder data
Data flows are triggered by the data-related operations of stakeholders, between system components that
belong to or are associated with them. Stakeholders achieve their aims by means of role-based interactions
with the DLT system.
ISO 23257:2022, 9.2 describes a set of roles/sub-roles which address the main activities associated with DLT
systems and gives overall descriptions for activities of these roles/sub-roles. When discussing data flow and
data taxonomy, the detailed data-related activities of these roles/sub-roles are necessary information.
5.4.2 Roles/sub-roles and their activities related to data flow
5.4.2.1 Data-related activities of DLT users
A DLT user often uses a DLT system on their devices, by using a DLT application or an application that
interacts with a DLT API. Examples of its activities include:
— providing data to or inserting data into DLT systems;
— using data obtained from DLT systems on their devices;
— installing applications on devices.
5.4.2.2 Data-related activities of DLT administrators
A DLT administrator performs administrative activities which can be data-oriented or produce data.
Examples of its activities include:
— developing plans to ensure blockchain data backup and recovery, as well as possible data replication and
failover;
— ensuring robustness of data storage and processing;
— discovery, classification and protection of data;
— managing access and authentication data;
— managing application configuration data;
— managing cross-ledger data exchange;

— managing long-term preservation of data.
5.4.2.3 Data-related activities of DLT providers
5.4.2.3.1 General
As defined in ISO 23257, DLT provider is the business stakeholder owning and operating one or more DLT nodes.
DLT providers can have data interaction with DLT users and are also responsible for the operation of data.
DLT providers include three sub-roles:
— DLT system operators;
— DLT node operators;
— DLT application operators.
5.4.2.3.2 Data-related activities of DLT system operators
Examples of DLT system operators’ activities include:
— providing audit data activities according to audit’s requests;
— maintaining operation data.
5.4.2.3.3 Data-related activities of DLT node operators
Examples of DLT node operators' activities include:
— data tracking to achieve the system performance quality control;
— managing access control of data shared by different DLT users on the same node.
5.4.2.3.4 Data-related activities of DLT application operators
Examples of DLT application operators’ activities include:
— providing data, applications and data related services;
— processing and using data including data from DLT users under an agreement.
5.5 Considerations related to data flow
5.5.1 Data security
Data security covers preservation of confidentiality, integrity and availability of data.
For DLT systems, ensuring full-link security in end-to-end data channels, from IoT user devices to DLT
systems is important.
5.5.2 Privacy protection
As specified in ISO/TR 23244, there is a series of challenges for privacy protection in DLT systems, which are
generally based on characteristics that differentiate them from other ICT systems.
ISO/TR 23244 also lists a range of areas which privacy within a DLT system covers:
— privacy of DLT users;
— personal information recorded in ledgers on a DLT system;

— personal information stored in external resources referenced in DLT content (off-ledger);
— privacy of transactions or data.
Besides, security of authorization data for related parties to use DLT users’ data is also an important concern.
It is possible that a given DLT system contains PII. Establishing whether a given system contains PII requires
a PIA, which is dealt with by ISO/IEC 29134. A PIA ideally can be undertaken as part of the design of a DLT
system in order to ensure that the solution conforms with relevant privacy requirements.
5.5.3 Governance of data
Governing bodies of DLT data are structured differently from traditional IT systems. There are multiple
stakeholders involved in the life cycle of DLT data. ISO/TS 23635 identifies three main tasks that each group
of stakeholders can govern a DLT system through:
— evaluation of the current and future use of DLT system and identification of obligations and risks;
— direct preparation and implementation of policies, procedures and internal control frameworks to
ensure that the use of DLT systems meets obligations and mitigates significant risk;
— monitoring of conformance of policies, procedures and performance of the internal control framework
operations to ensure sufficient risk mitigation and conformance to obligations.
ISO/IEC 38505-1 also provides an example data management life cycle. See Figure 3.
Figure 3 — Example data management life cycle
NOTE Archivists use another life cycle model. To archive is one of two final dispositions, the other being delete.
The deletion of on-ledger data in DLT systems, designed to be immutable, is an important consideration for
stakeholders.
5.5.4 Interoperability
ISO/IEC 22123-1 defines interoperability as the ability of two or more systems or applications to exchange
information and to mutually use the information that has been exchanged.
The interoperability related to data applies to the external flows of data identified.
6 Intra-system data flow
6.1 Overview
A typical process with a serial of data flows taking place within a DLT system is a transaction life-cycle
(see Figure 4). Two stages are considered for a whole transaction process, respectively preliminary stage
and full life cycle transaction stage. For the full life cycle stage, although a transaction life cycle can differ
because of differing protocols or implementations, this document takes a five-step life cycle including
submit, broadcast, consensus, execute and feedback as an example.

Figure 4 — Intra-system data flow process: A user creates a transaction record
NOTE 1 Differing protocols or implementations can order transactions differently.
NOTE 2 The data life cycle model works well only when there are clearly identifiable stages in “real-life”. When data
are actively modified and used during all their lifetime, life cycle model can be unhelpful.
To clarify the data involved activities, this document identifies the following information for each step:
— data categories (from data storage and DLT system role perspectives);
— data flow categories;
— actions of data: data creation, data storage, data processing, data transmission.
NOTE 3 Data content is use case specific.
6.2 Data flow during DLT transaction procedure
6.2.1 Preliminary stage
6.2.1.1 DLT system setup
After the DLT system is created, the DLT developer and provider set up multiple distributed nodes, system
configuration, administrator accounts, etc. Accordingly, the operation data and access authentication data
are created and stored consistently among multiple nodes.
6.2.1.2 DLT user account registration
The DLT user performs registration on the DLT system before utilizing on-chain services. Optionally, the
user can provide identifiable information to establish the link between account and physical item.
— Data creation: The DLT account data are created, including account identity, balance, status, etc.
— Data storage: The account data are consistently stored at distributed nodes. Conforming to the
applicable requirements, policies, rules and considerations in ISO/TR 23244, the sensitive information
in DLT account data can be stored on the blockchain system with protection based on access control,
encryption, etc. Alternatively, the sensitive information can be linked to on-chain identifier and stored
in an off-ledger datastore with restricted access.

6.2.2 Full life cycle data flow in one transaction
6.2.2.1 Outline
One transaction implementation is illustrated in Figure 5. Segments of a life cycle are listed as S1-S5:
— S1: Transaction submission. The transaction message is submitted by user or admin system. If it is
submitted by user, this message can be viewed as data flow D. Otherwise, it is data flow C.
— S2: Transaction broadcasting. The message is validated and broadcasted among distributed nodes, which
corresponds to data flow N.
— S3: Consensus achievement. The consensus protocol is achieved to determine the transaction execution
order, which corresponds to data flow N.
— S4: Transaction execution. Each node executes transaction independently.
— S5: Result feedback. The result is sent back to user or admin system. If it is submitted by the user, this
message can be viewed as data flow D. Otherwise, it is data flow C.
Figure 5 — Illustration of transaction implementation
6.2.2.2 S1: Transaction submission
A user utilizes the corresponding interface to interact with the DLT system and initiates a transaction with
or without smart contract.
— Data transmission: The transaction initiation message is submitted by user, which contains transaction
content, e.g. sender/receiver account identity, and business information. The business information can
be digital asset amount, or parameters to call smart contract.
— Data creation: Transaction data submitted by user is recorded on ledger.
6.2.2.3 S2: Transaction broadcasting
A node which receives initiation message verifies the message by checking message format, account identity
validity, double spending, signature, etc. If this transaction message is valid, it is sent to other distributed
nodes within the given DLT network. Subsequently, other distributed nodes verify the received message
independently and buffer it.
— Data processing: The transaction content is verified per node.
— Data transmission: The transaction content is transmitted among distributed nodes within DLT network.

— Data storage: The transaction content is buffered per node.
6.2.2.4 S3: Consensus achievement
The consensus protocol is performed among nodes to determine the execution order of transactions.
— Data creation: Interactive messages to determine the execution order are created.
— Data transmission: Interactive messages are communicated among distributed nodes according to the
implemented consensus protocol.
— Data storage: The execution order is stored per node.
6.2.2.5 S4: Transaction execution
Each node independently executes transactions based on the agreed order.
— Data processing: The data (e.g. business information, archived blocks, account data, smart contract data)
are processed according to the pre-defined computation rules. Optionally, after computation, the account
data and smart contract data are updated accordingly.
— Data creation: Receipt data are generated. Optionally, new smart contract data and event data are
generated.
— Data storage: The transaction content and receipt data are archived in the confirmed blocks. The smart
contract data and event data are consistently stored at distributed nodes.
6.2.2.6 S5: Result feedback
The receipt data are transmitted to the user who initiates the transaction. Optionally, the event data are
transmitted to the subscribed users.
— Data creation: Log data to record node operation is generated, including event distribution.
— Data storage: The log data are stored per node.
Similarly, the administer can call system-level smart contract and utilize the above procedure to update the
administrator data and op
...