ISO/DTS 18126

Taxonomy and classification for smart contracts

This document specifies a taxonomy and classification for smart contracts. It includes a taxonomy of smart contracts concepts, a taxonomy of smart contracts for DLT systems, and a taxonomy of smart contracts application domains, use case purposes, and economic activity sections. It also highlights smart contracts challenges and risks. The audience includes but is not limited to academics, architects, customers, users, tool developers, regulators, auditors and standards development organizations.

Titre manque

General Information

• Status: Not Published
• ICS: 35.240.99 - IT applications in other fields
• Technical Committee: ISO/TC 307 - Blockchain and distributed ledger technologies
• Drafting Committee: ISO/TC 307 - Blockchain and distributed ledger technologies
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 24-Dec-2025
• Completion Date: 24-Dec-2025

Overview

ISO/DTS 18126 specifies a comprehensive taxonomy and classification for smart contracts used in distributed ledger technology (DLT) systems. The standard organizes knowledge into structured taxonomies covering smart contract concepts, DLT-specific characteristics, and application domains - and calls out challenges, risks and security considerations. Its primary audience includes academics, architects, developers, regulators, auditors and standards bodies seeking a consistent framework to compare, select and evaluate smart contract solutions.

Key Topics

The document breaks the subject into clear, reusable taxonomy elements and classification criteria. Key topics include:

• Smart contract concepts: definitions and conceptual organization that support consistent terminology and understanding.
• Smart contracts for DLT systems: characteristics, lifecycle stages, roles and responsibilities, requirements, programming languages, data inputs/outputs, security vulnerabilities, and expected outcomes.
• Application domains and use cases: taxonomy of domains, use-case purposes and economic activity sections to map real-world deployments.
• Challenges and risks: classification of technical, legal and operational risk factors relevant to design, deployment and governance.
• Classification guidance: criteria for grouping smart contracts to help stakeholders compare alternatives and assess suitability.

These topics are aligned with related ISO work and extend definitions used in ISO/TS 23258 and ISO/TS 23635 to the specific context of smart contracts.

Applications

ISO/DTS 18126 is practical for a wide range of stakeholders and use cases:

• Architects & developers: adopt a common taxonomy to design interoperable smart contracts, evaluate lifecycle requirements and address security vulnerabilities.
• Regulators & auditors: use the classification to map legal and compliance implications across application domains and identify high-risk patterns.
• Tool developers & vendors: align product capabilities (testing, analysis, verification) with standard taxonomy elements such as programming language and data inputs/outputs.
• Academics & researchers: apply the taxonomy to structure studies, datasets and comparative analyses of smart contract behavior and economics.

Practical benefits include improved clarity for procurement, better risk management, more consistent documentation and enhanced comparability across implementations.

Related Standards

ISO/DTS 18126 references and complements existing ISO work on DLT and vocabulary (for example ISO/TS 23258 and ISO/TS 23635). The document also includes informative annexes that list: de facto standards from standards developing organizations, de jure market standards, common security vulnerabilities, and a case study on the DAO attack. These annexes provide contextual material useful for implementation, security analysis and policy development.

By standardizing taxonomy and classification, ISO/DTS 18126 helps stakeholders make informed choices about smart contract design, deployment and governance within DLT ecosystems.

Standards Content (Sample)

FINAL DRAFT
Technical
Specification
ISO/TC 307
Taxonomy and classification for
Secretariat: SA
smart contracts
Voting begins on:
2025-12-24
Voting terminates on:
2026-02-18
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
Taxonomy and classification for
Secretariat: SA
smart contracts
Voting begins on:
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: [phone]
Email: [e-mail]
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 Abbreviated terms . 2
5 Taxonomy and classification of smart contracts . 2
6 Taxonomy . 3
6.1 Taxonomy of smart contracts concepts .3
6.2 Taxonomy of smart contracts for DLT systems .5
6.2.1 Characteristics of smart contracts . .5
6.2.2 Life cycle .6
6.2.3 Roles and responsibilities .8
6.2.4 Requirements .9
6.2.5 Programming language . .10
6.2.6 Data inputs and outputs .10
6.2.7 Security vulnerabilities .11
6.2.8 Expected outcome .11
6.2.9 Role of the purpose within the system . 12
6.2.10 Source of value . 12
6.3 Taxonomy of smart contracts application domains, use cases purposes and economic
activity section . 12
6.3.1 Overview . 12
6.3.2 Taxonomy of application domains . 12
6.3.3 Taxonomy of smart contract use cases purposes . 13
6.3.4 Taxonomy of economic activity sections .14
7 Smart contracts challenges and risks .15
8 Classification of smart contracts . 17
Annex A (informative) Existing de facto standards for smart contracts (developed by standards
developing organizations) .20
Annex B (informative) Existing de jure standards for smart contracts (developed by the
market) . .21
Annex C (informative) Security vulnerabilities of smart contracts .22
Annex D (informative) The DAO attack case study .25
Bibliography .26

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 documents 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
Smart contracts on distributed ledger technology (DLT) systems have the potential to facilitate collaboration
across world industries, sectors and markets as well as track a vast range of transactions and interactions.
The term "smart contract" was first introduced by Nick Szabo in the early 1990s. Back then, smart contracts
were mainly drawn up to automate the terms of a contract. But it was only with the advent of blockchain and
DLT that this concept gained widespread interest. In 2014, Vitalik Buterin created a new generation of smart
contracts that expanded Nick Szabo’s concept. These contracts were decentralised and immutable once
they were implemented into DLT systems; they focused on moving digital assets according to pre-specified
rules. The notion of smart contracts within DLT systems was developed further in this new generation. The
term “smart contract” is most popularly used in the context of public blockchain and DLT systems, in which
the smart contract code can be executed with a deterministic result in an arbitrary virtual machine of a
mining peer. Other concepts, mostly private ledges, intentionally name the distributed code “chain code” to
emphasize differences in the execution concepts. Namely the chain code is installed and executed at selected
[1]
peers (ISO/TR 23455 ).
A comprehensive smart contract taxonomy is important for smart contracts to be effectively evaluated
and interpreted. A taxonomy for smart contracts is useful for defining information and data classification
rules and for identifying classification items and classification criteria. A consistent taxonomy is a valuable
resource in its own right that also supports and helps to understand other relevant standards (ISO/TS 23258
[2]
).
[2]
This document expands the definitions from ISO/TS 23258 to smart contracts in the context of the
taxonomy of smart contracts concepts, the taxonomy of smart contracts for DLT systems and the taxonomy
of smart contracts application domains, use cases purposes and economic activity sections. This document
[3]
also derives inputs from ISO/TS 23635 .
This document will help users, industry, policy makers and other interested parties or stakeholders to further
understand smart contracts and their essential features, helping them to compare and choose the right
options according to their business needs, risk appetite and applicable legal and regulatory requirements.
This document can also be used to inform scientific research and to support a wider understanding and
adoption of smart contracts.
Annex A covers existing de facto standards for smart contracts published by standards developing
organizations (SDOs).
Annex B covers existing de jure standards for smart contracts developed by the market.

v
FINAL DRAFT Technical Specification ISO/DTS 18126:2025(en)
Taxonomy and classification for smart contracts
1 Scope
This document specifies a taxonomy and classification for smart contracts. It includes taxonomies of:
— smart contracts concepts;
— smart contracts for DLT systems;
— smart contracts application domains, use case purposes and economic activity sections.
This document also highlights the challenges and risks of smart contracts.
The target audience for this document includes but is not limited to academics, architects, customers, users,
tool developers, regulators, auditors and standards developing organizations.
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
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:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
DLT system
distributed ledger system
distributed ledger technology system
system that implements a distributed ledger
[4]
[SOURCE: ISO 22739:2024 , 3.35]
3.2
legally binding smart contract
smart contract (3.3) whose outcomes are intended to be or are otherwise found to be legally binding among
the parties
Note 1 to entry: Smart contracts are typically enforceable under law through the legal system (which can involve
alternate dispute resolution rather than a court of law).
3.3
smart contract
computer program stored in a distributed ledger technology system (3.1) 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.
[4]
[SOURCE: ISO 22739:2024 , 3.88]
3.4
taxonomy
scheme of categories and subcategories that can be used to sort and otherwise organize itemized knowledge
or information
[5]
[SOURCE: ISO 5127:2017 , 3.8.6.07, modified — Note 1 to entry has been removed.]
4 Abbreviated terms
AI artificial intelligence
DAO decentralized autonomous organization
DApp decentralized application
DLT distributed ledger technology
DoS denial of service
NFT non-fungible token
PII personally identifiable information
SDO standards developing organization
5 Taxonomy and classification of smart contracts
Classifying smart contracts into different categories based on their similarities and differences in several
aspects makes them easier to understand. Such classification is also known as the taxonomy of smart
contracts. This taxonomy helps potential smart contract users and other stakeholders compare smart
contracts. That way, they can choose the right options according to their business needs, risk appetite and
applicable legal and regulatory requirements. Furthermore, smart contracts taxonomies can help with
knowledge advancement and can lead to a significant breakthrough in the utilization of smart contracts.
The taxonomy can also inform scientific research and can support a wider understanding and adoption of
smart contracts.
This document elaborates on taxonomies of:
— smart contracts concepts;
— smart contracts for DLT systems;
— smart contracts application domains, use cases purposes and economic activity sections.
[2]
This document expands the definitions from ISO/TS 23258 to the context of smart contracts. It also
[3]
derives inputs from ISO/TS 23635 . See Figure 1 for an overview.

Key
direction of inputs
expands inputs for smart contracts
feedback
a) [2]
Source: ISO/TS 23258
Figure 1 — Taxonomies for smart contracts
6 Taxonomy
6.1 Taxonomy of smart contracts concepts
Smart contracts are self-executing decentralized computer programs that automatically and
deterministically execute when certain conditions are met. Smart contracts enhance the capabilities of the
DLT systems such as automation, efficiency, transparency, trust, security, reliability and interoperability.
Smart contracts can be of different types as presented in Table 1.
An application logic contract is a type of smart contract designed to execute specific functions or processes
within decentralized applications (DApps). Application logic contracts are vital for the smooth operation of
the DApps, managing everything from user interactions to complex operations.
A decentralized autonomous organization (DAO) smart contract is a type of smart contract that supports
an organization that operates through rules that are coded into the DLT system blended with governance
mechanisms. A DAO smart contract enforces the governance and decision-making processes of the
organization in a decentralized and autonomous manner, without the need for traditional management
structures.
A token smart contract is a type of smart contract deployed on a DLT system to create, manage and facilitate
the transfer of tokens. A fungible token smart contract is related to fungible tokens and non-fungible tokens
(NFT) smart contract to NFTs.
Table 1 — Taxonomy of smart contracts concepts — types of smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Application logic
contract
Decentralized
autonomous or-
Governance smart
ganization smart
contract
contract (DAO
smart contract)
Smart contract
Fungible token
smart contract
Token smart con-
Non-fungible
tract
token smart con-
tract (NFT smart
contract)
Smart contracts are written codes and, depending on applicable law, can be legally binding. In particular,
the outcome produced can be qualified as legally binding. See Table 2 for classification. Legally binding
smart contracts engender various legal outcomes that can result in effective reversal of smart contract
transactions. The smart contract transactions executed can be nullified or voided. Legal enforcement in non-
legally binding smart contracts depends on the content and technical capabilities of said smart contracts.
Table 2 — Taxonomy of smart contracts concepts — legally binding
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Legally binding
Smart contract
smart contract
There are different options for storing and executing smart contracts as shown in Table 3. Identifying the
right option for deploying and executing smart contracts is important to fulfil the use case requirements
and address factors like security, efficiency, scalability and privacy.
On-chain smart contracts are smart contracts stored and executed directly on the main chain. On-chain
smart contracts as usually operated in public DLT systems are operated in the three-step-process: deploy-
[1]
invoke-operate (ISO/TR 23455 ). On-ledger smart contracts are smart contracts stored and executed
directly on the main ledger.
Off-chain smart contracts are smart contracts stored and executed outside the main chain but can interact
with the main chain when necessary. Executing a contract off-chain can provide significant benefits
compared with executing code natively on-chain, including scalability, privacy, security and cost. Off-
chain smart contracts, such as smart contracts used in private DLT systems, are operated in the three-step
[1]
process: install-instantiate-invoke (ISO/TR 23455 ). Off-ledger smart contracts are smart contracts stored
and executed outside the main ledger.
Sidechain smart contracts are smart contracts stored and executed on a sidechain. They enable the creation
and enforcement of specific rules and conditions within the sidechain, facilitating the execution of complex
transactions and applications. Side ledger smart contracts are smart contracts stored and executed on a side
ledger.
Subchain smart contracts are smart contracts that are designed to operate within the subchain rather than
the main chain. Subchain smart contracts can lower transaction costs and make the solution more flexible
and efficient. Sub ledger smart contracts are smart contracts that are designed to operate within the sub
ledger rather than the main ledger.

Table 3 — Taxonomy of smart contracts concepts — storage and execution
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Off-chain smart
contract
Off-ledger smart
contract
On-chain smart
contract
On-ledger smart
Smart contract
contract
Sidechain smart
contract
Side ledger smart
contract
Subchain smart
contract
Sub ledger smart
contract
Other concepts presented in Table 4 include the interoperability, portability and upgradability of the smart
contracts.
Interoperable smart contracts interact with and operate across different DLT systems, enabling them to
exchange data and execute transactions seamlessly across various systems. Cross-chain smart contracts
interact and execute transactions across multiple blockchain networks rather than being confined to a
single chain.
Mobile smart contracts are part of a lightweight and scalable blockchain or distributed ledger that is suitable
to be stored on, and executed by, mobile devices such as smartphones.
Portable smart contracts can be easily moved and deployed across different DLT systems without significant
modifications. Portability enables them to migrate, interact and execute across different DLT systems.
Upgradable smart contracts can be updated after they have been deployed. Upgradability is crucial for
addressing bugs, adding new features and maintaining security. Proper techniques should be applied in this
regard to address the immutability property of the DLT systems.
Table 4 — Taxonomy of smart contracts concepts — additional concepts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Interoperable Cross-chain smart
smart contract contract
Mobile smart
contract
Smart contract
Portable smart
contract
Upgradable smart
contract
6.2 Taxonomy of smart contracts for DLT systems
6.2.1 Characteristics of smart contracts
Not all DLT systems support a smart contract function. Smart contracts are usually written in high-level
computer programming languages in order to represent business logic or pre-determined criteria to
trigger transfer of values. They can be stored the DLT system and can have variables to store data and
functions which access, process and write data. Smart contracts can express business logic and conditions

for self-execution. This allows them to execute complex transactions. Smart contracts are also flexible
and customisable. This means they can be used to transfer value, represent varied assets and store assets
through smart contract wallets and others.
From the execution perspective, in some systems, smart contracts can be executed on any node and in others
can be executed on only some limited set of pre-specified nodes.
Smart contracts characteristics are dependent on their underlying ledger technology. Some of these
characteristics such as immutability and transparency are by-design properties of the ledger. Smart
contracts inherit these properties from the ledger.
In general, when developed, used and deployed, smart contracts can present or exhibit the following
characteristics:
— business characteristics:
— cost-effectiveness
— customizable
— efficiency
— formalization of contracts
— speed
— technical characteristics:
— availability
— decentralized
— deterministic
— distributed
— immutability
— re-usability
— self-execution
— transparency
6.2.2 Life cycle
Smart contract’s lifecycle spans various phases as shown in Figure 2 and further listed in Table 5.

Figure 2 — Smart contract lifecycle
Smart contract design is the phase for defining the architecture, logic and interactions of the smart contract.
Smart contract coding is the phase for writing the code that defines the logic, rules and functionality of a
smart contract using a programming language compatible with the DLT platform. Smart contract validation
ensures that the smart contract meets all functional and security requirements. Smart contract verification
formally verifies the correctness and security of the smart contract. In the smart contract code verification,
formal methods and tools are used to prove the correctness of the contract's code. If integration with
external data or functionalities is required, it should be addressed and managed during the smart contract
phase.
Smart contract testing is the phase for verifying that the smart contract functions correctly and securely.
Smart contract code testing tests the code for bugs, errors and vulnerabilities. Smart contract specific
testing tests specific functionalities and scenarios unique to the contract.
During the smart contract review, the code is reviewed and the audit reports are generated with issues
found.
Smart contract deployment is the phase for deploying the smart contract to a DLT system. In the smart
contract off-chain deployment, certain logic or computations run off the main chain while keeping essential
data on-chain. In the smart contract on-chain deployment, the smart contract is deployed directly in the
main chain. In the smart contract sidechain deployment, the smart contract is deployed on a sidechain
that operates parallel to the main chain. In the smart contract subchain deployment, the smart contract is
deployed in a logically separate chain that can form part of a DLT system.
Execution of contract is the process of executing the smart contract's code based on specific inputs and
conditions. Stateful execution of contract involves changes to the contract's state, such as updating balances
or records. Stateless execution of contract does not alter the contract's state and is used for read-only
operations.
Monitoring and maintenance make smart contracts durable, safe and efficient. Continuous monitoring
involves observing the contract's performance and security post-deployment. Maintenance involves
updating and improving the contract as needed. They can be done by using upgradeable smart contract
techniques and ensuring the proper functioning of deployed smart contracts.
Smart contract termination is the process of ending the smart contract's operation. Smart contract internal
termination is triggered by conditions or logic within the contract itself. Smart contract safe termination is
a secure and controlled way to terminate the contract, ensuring all parties are aware and any obligations
are fulfilled.
Self-destruction refers to a smart contract's ability to permanently terminate itself, deleting the smart
contract bytecode from the ledger and transferring any remaining crypto assets to a designated address.
The self-destruction phase is irreversible and renders the smart contract address non-functional anymore.

Table 5 — Smart contracts — Life cycle phases
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
Coding
coding
Smart contract
Design
design
Smart contract
off-chain deploy-
ment
Smart contract
on-chain deploy-
ment
Smart contract
Deployment
deployment
Smart contract
sidechain deploy-
ment
Smart contract
subchain deploy-
ment
Stateful execution
of the contract
Execution of the
Execution
Stateless exe-
contract
cution of the
contract
Entity Process Action
Smart contract
maintenance
Monitoring and
maintenance
Smart contract
monitoring
Smart contract
Review
review
Smart contract
Self-destruction
self-destruction
Smart contract
internal termina-
Smart contract
tion
Termination
termination
Smart contract
safe termination
Smart contract
code testing
Smart contract
Testing
testing
Smart contract
specific testing
Smart contract
Validation
validation
Smart contract Smart contract
Verification
verification code verification
[2]
NOTE The life cycle phases in Table 5 are listed in alphabetical order to align with ISO/TS 23258 .
6.2.3 Roles and responsibilities
Roles in the lifecycle of a smart contract include responsibilities related to authorship, creation, development,
ownership, signing and usage, as presented in Table 6.
The smart contract author designs and writes the logic and terms of the smart contract.
The smart contract auditor audits the code of smart contracts to identify errors, bugs and vulnerabilities,
including security related ones. They then report the results of the assessments of the findings and risks
identified.
The smart contract creator deploys the smart contract to a DLT system.
The smart contract developer codes the smart contract using a programming language compatible with the
DLT system.
The smart contract holder possesses tokens or assets governed by the smart contract.
The smart contract owner has control over the smart contract, including the authority to modify, upgrade or
terminate it.
The smart contract signatory signs the smart contract, agreeing to the smart contract terms and conditions.
The smart contract user interacts with the smart contract to perform specific actions or utilize the smart
contract functions.
Table 6 — Smart contracts — roles
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
Author
author
Smart contract
Auditor
auditor
Smart contract
Creator
creator
Smart contract
Developer
developer
Entity Person
Smart contract
Holder
holder
Smart contract
Owner
owner
Smart contract
Signatory
signatory
Smart contract
User
user
6.2.4 Requirements
Smart contracts are mere codes. If they are not well planned, designed, coded and tested, they can leave the
system vulnerable to external attacks and internal errors. Table 7 lists requirements of various types to be
considered when designing, coding, testing and operating smart contracts.
Table 7 — Smart contracts — Requirements
Type of requirement Requirement
Functional requirement Control instruction
Initialization
Interrupt execution
Lifetime
Termination
Non-functional requirement Interoperability
Performance
Portability
Scalability
Security
Upgradability
6.2.5 Programming language
Before selecting a programming language to develop an application or functionality, the blockchain or DLT
that is going to be deployed for the smart contract should be explored.
Table 8 lists some aspects related to programming languages that are relevant in the context of smart
contracts.
Table 8 — Programming languages — relevant aspects to smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Compiled
programming
language
Domain-specific
programming
language (DSL)
General-purpose
programming
language (GPL)
High-level
programming
Smart contract
language
Smart contract
Record Ledger record programming
record
Interpreted
language
programming
language
Low-level
programming
language
Turing complete
programming
language
Turing incomplete
programming
language
Table 9 elaborates on additional aspects of a smart contract record. The code of a smart contract developed
using a programming language supported by the blockchain or DLT platform is stored in a ledger record.
Lifetime should be considered to avoid eternal smart contracts that can cause unwanted executions in
future. Versioning should be robust for managing smart contract upgrades systematically.
Table 9 — Smart contract record — relevant aspects to smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
code
Smart contract Smart contract
Record Ledger record
record lifetime
Smart contract
version
6.2.6 Data inputs and outputs
DLT systems and smart contracts cannot access data from outside of their network. Regarding this aspect,
DLT oracles are useful for smart contracts that cannot access sources of data external to the DLT system.
Some smart contracts, especially in more complex applications, require ingestion of data external to DLT
systems during their code execution which is enabled by DLT oracles. DLT oracles can represent trusted
systems designed to supply external data to a DLT system or to respond to events from DLT systems.

DLT oracles can be categorised as follows:
— software oracles: data are retrieved from online sources, such as application programming interfaces
(APIs), websites or databases (i.e. weather data, stock prices, exchange rates);
— hardware oracles: based on interaction with the physical world, they are retrieving data from sensors,
radio frequency identification (RFID) tags (a type of tracking system that uses smart barcodes in order
to identify items) or internet of things (IoT) devices;
— inbound oracles: deliver data from external sources into the blockchain (i.e. asset prices);
— outbound oracles: send information from smart contracts to the outside world (i.e. triggering a payment
in a traditional banking system);
— consensus-based oracles: use multiple data sources and validators to achieve a reliable consensus about
the correct data before passing it on to the blockchain.
Smart contracts can be differentiated based on the dependence on DLT oracles as follows.
Smart contracts that are dependent on DLT oracles require ingestion of data external to DLT systems. This
creates concern for the trustworthiness of data oracles, such as the lack of assurance in the proper and
accurate relaying of data beyond the trustworthiness of the actual data sources. Neither can ensure the
veracity and integrity of external data imported during the smart contract code execution.
Self-contained smart contracts are smart contracts that do not require ingestion of data external to DLT
systems during code execution. Smart contracts that do not require ingestion of data external to DLT
systems do not raise risks for the trustworthiness of data oracles or of the bridging mechanisms relaying
such data. The execution relies on the smart contract code.
6.2.7 Security vulnerabilities
Vulnerabilities can arise in either the smart contract itself or the underlying DLT system. Smart contract
vulnerabilities arise from various reasons including errors in the design or implementation of the contract,
bad programming practice and programming language weaknesses, malicious DLT oracles or unforeseen
interactions with other smart contracts.
Smart contract security is crucial. A primary challenge is avoiding known vulnerabilities that can be
exploited by attackers. Common examples of smart contract vulnerabilities include reentrancy attacks,
denial of service (DoS) attacks and integer overflow and underflow attacks. Secure coding practices, code
reviews and audits, testing and use of formal verification are mitigation strategies to minimize the risk of
smart contracts exploitations. Smart contract audits assist identifying security vulnerabilities so that they
can be fixed to prevent exploitations by malicious actors.
A list of known vulnerabilities is presented in Annex C. Annex D presents a case study about exploring
vulnerabilities in smart contracts.
6.2.8 Expected outcome
An aspect to consider regarding expected outcomes from smart contracts can be the ability to meet a
certain kind of expectation. In other words, their ability to perform as expected will determine if they are
fit for purpose. Smart contracts are expected to operate in ways that primarily serve business expectations,
such as the execution of a payment transaction upon the delivery of a product or the execution of an escrow
arrangement. Business expectation can require the deployment of smart contracts that adhere to specific
business processes and arrangements. Business expectations vary from simple to complex transactions.
However, smart contracts can serve other expectations that are non-business. These can include activities,
actions or transactions that extend beyond business, trade or profession or that fall within the private or
personal sphere of affairs. For example, family expectations or arrangements or gifts can qualify as non-
business expectations.
6.2.9 Role of the purpose within the system
Smart contracts in DLT systems can be categorized into three distinct types based on their role and
interaction within the system as follows:
— In-ledger / in-chain smart contracts
These contracts operate at the core of the DLT infrastructure. Their role is to execute programmable
consensus conditions (e.g. block validation or consensus mechanisms) in coordination with validators
miners. They ensure the technical stability of the decentralized ledger (e.g. managing mining rewards,
updating consensus rules). Their scope is strictly protocol-bound and does not provide external services.
— On-ledger / on-chain smart contracts
Focused on digital services, these contracts execute programmable transactions directly recorded on the
ledger (e.g. tokenized asset transfers, decentralized finance (DeFi) platforms). They interact with end-
users and stakeholders through native interfaces, shaping the network’s economic viability. Their logic is
transparent and immutable but dependent on the system’s performance.
— Off-ledger / off-chain smart contracts
Designed to integrate external data or functionalities, these contracts act as DLT bridges (e.g. oracles for
financial data, decentralized storage). They address challenges like privacy (via off-chain computations)
or scalability (by minimizing ledger usage). Their execution can be bidirectional, combining cryptographic
proofs and external triggers.
6.2.10 Source of value
Source of value can be categorized as intrinsic value or extrinsic value.
Intrinsic value smart contract is the smart contract that does not incorporate any right or have any
connection with any asset, right or value outside the DLT system. The value referenced or incorporated in
the smart contract is within the DLT system.
Extrinsic value smart contract is the smart contract that incorporates rights or have a connection with an
asset, right or value outside the DLT system.
6.3 Taxonomy of smart contracts application domains, use cases purposes and economic
activity section
6.3.1 Overview
Smart contracts use cases are described by standardization bodies, policy making bodies, developers,
manufacturers, solution providers, consulting companies, economic organizations, academics and
researchers. This results in diverse and non-harmonized documentation.
This subclause generalizes specific smart contract use cases so that they apply to more than one activity
sector. It does so by distinguishing cross-sector application domains, cross-sector smart contract use case
purposes and economic activity sections.
6.3.2 Taxonomy of application domains
Application domains are described as areas of interest where smart contracts apply. Cross-sector application
domains bring a first abstraction layer for any smart contract service or solution deploying any use case in
[2]
any activity sector. See ISO/TS 23258 .
Common legal and regulatory obligations can benefit from, and require, common smart contract standards.
Common standards for smart contracts supporting regulatory or regulated services can contribute to
transparency and auditability by providing a solid framework for smart contract design and execution.
This facilitates audits and reviews by third parties and allows stakeholders, such as financial entities and

regulators, to verify the integrity and credibility of smart contract solutions used for regulatory compliance
against established standards.
Cross-sector applications domains where smart contracts apply include:
— collaboration, decision making, structuration;
— contract management, automation;
— disintermediation in distribution, actions traceability;
— electronic payment, cryptocurrency and token exchange;
— intellectual property protection, certification;
— rights and identifier management, identification.
6.3.3 Taxonomy of smart contract use cases purposes
Cross-sector use case purposes bring a second abstraction layer as they are associated with each cross-
[2]
sector application domain according to ISO/TS 23258 .
Table 10 shows applications of smart contracts based on the purpose of the cross-sector use case, which is
associated to the six cross-sector application domains.
Table 10 — Cross-sector use case purpose for each cross-sector applications domain — application
to smart contracts
Cross-sector application domains
Smart contracts use cases purpos-
[2]
(ISO/TS 23258 ) | Horizontal cate- Cross-sector use case purpose
es
[6]
gories (ISO/TR 3242 )
Governing DAO smart contract
Collaboration, decision making, struc-
turation | Governance
Creating and generating Resource Oracle contract
Application logic contract
Agreeing, committing, consenting,
Escrow contract
contracting and engaging
Multi-signature contract
Contract management, automation |
Automation
Accounting, billing and charging Simple payment contract
Guaranteeing, insuring and responsi-
Insurance contract
bilizing
Commercialising, delivering, distrib-
uting, exchanging pr
...

ISO/TC 307
ISO/CD TS 18126.2(en)
Secretariat:  SA
Date: 2025-12-09
Taxonomy and classification for smart contracts

ISO/CD TSDTS 18126.2:2025(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: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO/CD TSDTS 18126.2:2025(en)
Contents
Foreword . iii
Introduction . iii
Scope . iii
Normative references . iii
Terms and definitions . iii
Abbreviated terms . iii
Taxonomy and classification of smart contracts . iii
Taxonomy . iii
Taxonomy of smart contracts concepts . iii
Taxonomy of smart contracts for DLT systems . iii
Taxonomy of smart contracts application domains, use cases purposes and economic
activity sections . iii
Smart contracts challenges and risks . iii
Classification of smart contracts . iii
(informative) Existing de facto standards for smart contracts (developed by standards
developing organizations) . iii
(informative) Existing de jure standards for smart contracts (developed by the market) . iii
(informative) Security vulnerabilities of smart contracts . iii
(informative) The DAO attack case study . iii
Bibliography . iii

Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Taxonomy and classification of smart contracts . 2
6 Taxonomy . 3
6.1 Taxonomy of smart contracts concepts . 3
6.2 Taxonomy of smart contracts for DLT systems . 6
6.2.1 Characteristics of smart contracts . 6
6.2.2 Life cycle . 7
6.2.3 Roles and responsibilities . 9
6.2.4 Requirements . 10
6.2.5 Programming language . 10
6.2.6 Data inputs and outputs . 11
6.2.7 Security vulnerabilities . 12
6.2.8 Expected outcome . 12
6.2.9 Role of the purpose within the system . 13
6.2.10 Source of value . 13
iii
ISO/CD TSDTS 18126.2:2025(en)
6.3 Taxonomy of smart contracts application domains, use cases purposes and economic
activity section . 13
6.3.1 Overview . 13
6.3.2 Taxonomy of application domains . 14
6.3.3 Taxonomy of smart contract use cases purposes . 14
6.3.4 Taxonomy of economic activity sections . 15
7 Smart contracts challenges and risks . 17
8 Classification of smart contracts . 19
Annex A (informative) Existing de facto standards for smart contracts (developed by standards
developing organizations) . 22
Annex B (informative) Existing de jure standards for smart contracts (developed by the
market) . 23
Annex C (informative) Security vulnerabilities of smart contracts . 25
Annex D (informative) The DAO attack case study . 29
Bibliography . 30

iv
ISO/CD TSDTS 18126.2:2025(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 documents 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/CD TSDTS 18126.2:2025(en)
Introduction
Smart contracts on distributed ledger technology (DLT) systems have the potential to facilitate collaboration
across world industries, sectors and markets as well as the tracking oftrack a vast range of transactions and
interactions.
The term "smart contract" was first introduced by Nick Szabo in the early 1990s. Back then, smart contracts
were mainly drawn up to automate the terms of a contract. But it was only with the advent of blockchain and
distributed ledger technologyDLT that this concept gained widespread interest. In 2014, Vitalik Buterin
created a new generation of smart contracts expandingthat expanded Nick Szabo’s concept. These contracts
were decentralised and immutable once they were implemented into DLT systems; they focused on moving
digital assets according to pre-specified rules. The notion of smart contracts within DLT systems was
developed further in this new generation. The term “smart contract” is most popularly used in the context of
public blockchain and DLT systems, in which the smart contract code can be executed with a deterministic
result in an arbitrary virtual machine of a mining peer. Other concepts, mostly private ledges, intentionally
name the distributed code “chain code” to emphasize differences in the execution concepts. Namely the chain
[1]
code is installed and executed at selected peers (ISO/TR 23455 ISO/TR 23455).
A comprehensive smart contract taxonomy is important for smart contracts to be effectively evaluated and
interpreted. A taxonomy for smart contracts is useful for defining information and data classification rules and
for identifying classification items and classification criteria. A consistent taxonomy is a valuable resource in
[2]
its own right that also supports and helps to understand other relevant standards (ISO/TS 23258 ISO/TS
23258).
[2]
This document expands the definitions from ISO/TS 23258 ISO/TS 23258 to smart contracts in the
contextscontext of the taxonomy of smart contracts concepts, the taxonomy of smart contracts for DLT
systems and the taxonomy of smart contracts application domains, use cases purposes and economic activity
[3]
sections. This document also derives inputs from ISO/TS 23635 ISO/TS 23635.
This document will help users, industry, policy makers and other interested parties or stakeholders to further
understand the smart contracts and their essential features, helping them to compare and choose the right
options according to their business needs, risk appetite and applicable legal and regulatory requirements. This
document can also be used to inform scientific research and to support a wider understanding and adoption
of smart contracts.
Annex A covers existing de facto standards for smart contracts published by standards developing
organizations (SDOs).
Annex B covers existing de jure standards for smart contracts developed by the market.
vi
ISO/CD TSDTS 18126.2:2025(en)
Taxonomy and classification for smart contracts
1 Scope
This document specifies a taxonomy and classification for smart contracts. It includes taxonomies of:
— smart contracts concepts;
— smart contracts for DLT systems;
— smart contracts application domains, use case purposes and economic activity sections.
This document also highlights smart contractsthe challenges and risks of smart contracts.
The target audience for this document includes but is not limited to academics, architects, customers, users,
tool developers, regulators, auditors and standards developing organizations.
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
3 Terms and definitions
For the purposes of this document, the following terms and definitions / terms and definitions given in ISO
22739 as well asand the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
DLT system
distributed ledger system
distributed ledger technology system
system that implements a distributed ledger
[SOURCE: ISO 22739:2024, 3.35]
[SOURCE: ISO 22739, 3.35]
3.2
legally binding smart contract
smart contract (3.3) whose outcomes are intended to be or are otherwise found to be legally binding among
the parties
Note 1 to entry: Smart contracts are typically enforceable under law through the legal system (which can involve
alternate dispute resolution rather than a court of law).
ISO/CD TSDTS 18126.2:2025(en)
3.3
smart contract
computer program stored in a distributed ledger technology (DLT) system (3.1) 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]
[SOURCE: ISO 22739, 3.88]
3.4
taxonomy
scheme of categories and subcategories that can be used to sort and otherwise organize itemized knowledge
or information
[SOURCE: ISO 5127:2017, 3.8.6.07]
[SOURCE: ISO 5127, 3.8.6.07, modified — Note 1 to entry has been removed.]
4 Abbreviated terms
AI artificial intelligence
DAO decentralized autonomous organization
DApp decentralized application
DLT distributed ledger technology
DoS denial of service
NFT non-fungible token
PII personally identifiable information
SDO standards developing organization
5 Taxonomy and classification of smart contracts
Classifying smart contracts into different categories based on their similarities and differences in several
aspects makes them easier to understand. Such classification is also known as the taxonomy of smart
contracts. This taxonomy helps potential smart contract users and other stakeholders compare smart
contracts. That way, they can choose the right options according to their business needs, risk appetite and
applicable legal and regulatory requirements. Furthermore, smart contracts taxonomies can help with
knowledge advancement and can lead to a significant breakthrough in the utilization of smart contracts. The
taxonomy can also inform scientific research and can support a wider understanding and adoption of smart
contracts.
This document elaborates on taxonomies of:
— smart contracts concepts;
— smart contracts for DLT systems;
ISO/CD TSDTS 18126.2:2025(en)
— smart contracts application domains, use cases purposes and economic activity sections.
[2]
This document expands the definitions from ISO/TS 23258 ISO/TS 23258 to the context of smart contracts.
[3]
It also derives inputs from ISO/TS 23635 ISO/TS 23635. See Figure 1 for an overview.

Key
direction of inputs
expands inputs for smart contracts
feedback
a)
Source: ISO/TS 23258
Figure 1 — Taxonomies for smart contracts

6 Taxonomy
6.1 Taxonomy of smart contracts concepts
Smart contracts are self-executing decentralized computer programs that automatically and
deterministically execute when certain conditions are met. Smart contracts enhance the capabilities of the
DLT systems such as automation, efficiency, transparency, trust, security, reliability and interoperability.
Smart contracts can be of different types as presented in Table 1.
An application logic contract is a type of smart contract designed to execute specific functions or processes
within decentralized applications (DApps). Application logic contracts are vital for the smooth operation of
the DApps, managing everything from user interactions to complex operations.
A decentralized autonomous organization (DAO) smart contract is a type of smart contract that supports an
organization that operates through rules that are coded into the DLT system blended with governance
mechanisms. A DAO smart contract enforces the governance and decision-making processes of the
organization in a decentralized and autonomous manner, without the need for traditional management
structures.
A token smart contract is a type of smart contract deployed on a DLT system to create, manage and facilitate
the transfer of tokens. A fungible token smart contract is related to fungible tokens and non-fungible tokens
(NFT) smart contract to NFTs.
ISO/CD TSDTS 18126.2:2025(en)
Table 1 — Taxonomy of smart contracts concepts — types of smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Application logic
contract
Decentralized
autonomous
Governance organization
smart contract smart contract
(DAO smart
Smart contract
contract)
Fungible token
smart contract
Token smart
Non-fungible
contract
token smart
contract (NFT
smart contract)
Smart contracts are written codes and, depending on applicable law, can be legally binding. In particular, the
outcome produced can be qualified as legally binding. See Table 2 for classification. Legally binding smart
contracts engender various legal outcomes that can result in effective reversal of smart contract transactions.
The smart contract transactions executed can be nullified or voided. Legal enforcement in non-legally binding
smart contracts depends on the content and technical capabilities of said smart contracts.
Table 2 — Taxonomy of smart contracts concepts — legally binding
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Legally binding
Smart contract
smart contract
There are different options for storing and executing smart contracts as shown in Table 3. Identifying the right
option for deploying and executing smart contracts is important to fulfil the use case requirements and
address factors like security, efficiency, scalability and privacy.
On-chain smart contracts are smart contracts stored and executed directly on the main chain. On-chain smart
contracts as usually operated in public DLT systems are operated in the three-step-process: deploy-invoke-
[1]
operate (ISO/TR 23455 ISO/TR 23455.). On-ledger smart contracts are smart contracts stored and executed
directly on the main ledger.
Off-chain smart contracts are smart contracts stored and executed outside the main chain but can interact
with the main chain when necessary. Executing a contract off-chain can provide significant benefits compared
with executing code natively on-chain, including scalability, privacy, security and cost. Off-chain smart
contracts, such as smart contracts used in private DLT systems, are operated in the three-step process: install-
[1]
instantiate-invoke (ISO/TR 23455 ISO/TR 23455.). Off-ledger smart contracts are smart contracts stored
and executed outside the main ledger.
Sidechain smart contracts are smart contracts stored and executed on a sidechain. They enable the creation
and enforcement of specific rules and conditions within the sidechain, facilitating the execution of complex
transactions and applications. Side ledger smart contracts are smart contracts stored and executed on a side
ledger.
Subchain smart contracts are smart contracts that are designed to operate within the subchain rather than the
main chain. Subchain smart contracts can lower transaction costs and make the solution more flexible and
ISO/CD TSDTS 18126.2:2025(en)
efficient. Sub ledger smart contracts are smart contracts that are designed to operate within the sub ledger
rather than the main ledger.
Table 3 — Taxonomy of smart contracts concepts — storage and execution
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Off-chain smart
contract
Off-ledger smart
contract
On-chain smart
contract
On-ledger smart
Smart contract
contract
Sidechain smart
contract
Side ledger
smart contract
Subchain smart
contract
Sub ledger smart
contract
Other concepts presented in Table 4 include the interoperability, portability and upgradability of the smart
contracts.
Interoperable smart contracts interact with and operate across different DLT systems, enabling them to
exchange data and execute transactions seamlessly across various systems. Cross-chain smart contracts
interact and execute transactions across multiple blockchain networks rather than being confined to a single
chain.
Mobile smart contracts are part of a lightweight and scalable blockchain or distributed ledger that is suitable
to be stored on, and executed by, mobile devices such as smartphones.
Portable smart contracts can be easily moved and deployed across different DLT systems without significant
modifications. Portability enables them to migrate, interact and execute across different DLT systems.
Upgradable smart contracts can be updated after they have been deployed. Upgradability is crucial for
addressing bugs, adding new features and maintaining security. Proper techniques should be applied in this
regard to address the immutability property of the DLT systems.
Table 4 — Taxonomy of smart contracts concepts — additional concepts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Interoperable Cross-chain
smart contract smart contract
Mobile smart
Smart contract
contract
Portable smart
contract
ISO/CD TSDTS 18126.2:2025(en)
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Upgradable
smart contract
6.2 Taxonomy of smart contracts for DLT systems

6.2.1 Characteristics of smart contracts
Not all DLT systems support a smart contract function. Smart contracts are usually written in high-level
computer programming languages in order to represent business logic or pre-determined criteria to trigger
transfer of values. They can be stored the DLT system and can have variables to store data and functions which
access, process and write data. Smart contracts can express business logic and conditions for self-execution.
This allows them to execute complex transactions. Smart contracts are also flexible and customisable. This
means they can be used to transfer of value, represent varied assets and store assets through smart contract
wallets and others.
From the execution perspective, in some systems, smart contracts can be executed on any node and in others
can be executed on only some limited set of pre-specified nodes.
Smart contracts characteristics are dependent on their underlying ledger technology. Some of these
characteristics such as immutability and transparency are by-design properties of the ledger. Smart contracts
inherit these properties from the ledger.
In general, when developed, used and deployed, smart contracts can present or exhibit the following
characteristics:
— Business characteristic
— business characteristics:
— cost-effectiveness
— customizable
— efficiency
— formalization of contracts
— speed
— Technical characteristic
— technical characteristics:
— availability
— decentralized
— deterministic
— distributed
— immutability
ISO/CD TSDTS 18126.2:2025(en)
— re-usability
— self-execution
— transparency
6.2.2 Life cycle
Smart contract’s lifecycle spans various phases as shown in Figure 2 and further listed in Table 5.

Figure 2 — Smart contract lifecycle
Smart contract design is the phase for defining the architecture, logic and interactions of the smart contract.
Smart contract coding is the phase for writing the code that defines the logic, rules and functionality of a smart
contract using a programming language compatible with the DLT platform. Smart contract validation ensures
that the smart contract meets all functional and security requirements. Smart contract verification formally
verifies the correctness and security of the smart contract. In the smart contract code verification, formal
methods and tools are used to prove the correctness of the contract's code. If integration with external data
or functionalities is required, it should be addressed and managed during the smart contract phase.
Smart contract testing is the phase for verifying that the smart contract functions correctly and securely. Smart
contract code testing tests the code for bugs, errors and vulnerabilities. Smart contract specific testing tests
specific functionalities and scenarios unique to the contract.
During the smart contract review, the code is reviewed and the audit reports are generated with issues found.
Smart contract deployment is the phase for deploying the smart contract to a DLT system. In the smart
contract off-chain deployment, certain logic or computations run off the main chain while keeping essential
data on-chain. In the smart contract on-chain deployment, the smart contract is deployed directly in the main
chain. In the smart contract sidechain deployment, the smart contract is deployed on a sidechain that operates
parallel to the main chain. In the smart contract subchain deployment, the smart contract is deployed in a
logically separate chain that can form part of a DLT system.
Execution of contract is the process of executing the smart contract's code based on specific inputs and
conditions. Stateful execution of contract involves changes to the contract's state, such as updating balances
or records. Stateless execution of contract does not alter the contract's state and is used for read-only
operations.
Monitoring and maintenance make smart contracts durable, safe and efficient. Continuous monitoring
involves observing the contract's performance and security post-deployment. Maintenance involves updating
ISO/CD TSDTS 18126.2:2025(en)
and improving the contract as needed. They can be done by using upgradeable smart contract techniques and
ensuring the proper functioning of deployed smart contracts.
Smart contract termination is the process of ending the smart contract's operation. Smart contract internal
termination is triggered by conditions or logic within the contract itself. Smart contract safe termination is a
secure and controlled way to terminate the contract, ensuring all parties are aware and any obligations are
fulfilled.
Self-destruction refers to a smart contract's ability to permanently terminate itself, deleting the smart contract
bytecode from the ledger and transferring any remaining crypto assets to a designated address. The self-
destruction phase is irreversible and renders the smart contract address non-functional anymore.
Table 5 — Smart contracts — Life cycle phases
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
Coding
coding
Smart contract
Design
design
Smart contract
off-chain
deployment
Smart contract
on-chain
deployment
Smart contract
Deployment
deployment
Smart contract
sidechain
deployment
Smart contract
subchain
deployment
Stateful
execution of the
Entity Process Action
contract
Execution of the
Execution
contract
Stateless
execution of the
contract
Smart contract
maintenance
Monitoring and
maintenance
Smart contract
monitoring
Smart contract
Review
review
Smart contract
Self-destruction
self-destruction
Smart contract
internal
Smart contract
termination
Termination
termination
Smart contract
safe termination
ISO/CD TSDTS 18126.2:2025(en)
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
code testing
Smart contract
Testing
testing
Smart contract
specific testing
Smart contract
Validation
validation
Smart contract Smart contract
Verification
verification code verification
[2]
NOTE The life cycle phases in Table 5 are listed in alphabetical order to align with ISO/TS 23258 ISO/TS 23258.
6.2.3 Roles and responsibilities
Roles in the lifecycle of a smart contract include responsibilities related to authorship, creation, development,
ownership, signing and usage, as presented in Table 6.
The smart contract author designs and writes the logic and terms of the smart contract.
The smart contract auditor audits the code of smart contracts to identify errors, bugs and vulnerabilities,
including security related ones. They then report the results of the assessments of the findings and risks
identified.
The smart contract creator deploys the smart contract to a DLT system.
The smart contract developer codes the smart contract using a programming language compatible with the
DLT system.
The smart contract holder possesses tokens or assets governed by the smart contract.
The smart contract owner has control over the smart contract, including the authority to modify, upgrade or
terminate it.
The smart contract signatory signs the smart contract, agreeing to the smart contract terms and conditions.
The smart contract user interacts with the smart contract to perform specific actions or utilize the smart
contract functions.
Table 6 — Smart contracts — roles
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
Author
author
Smart contract
Auditor
auditor
Smart contract
Entity Person Creator
creator
Smart contract
Developer
developer
Smart contract
Holder
holder
ISO/CD TSDTS 18126.2:2025(en)
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
Owner
owner
Smart contract
Signatory
signatory
Smart contract
User
user
6.2.4 Requirements
Smart contracts are mere codes. If they are not well planned, designed, coded and tested, they can leave the
system vulnerable to external attacks and internal errors. Table 7 lists requirements of various types to be
considered when designing, coding, testing and operating smart contracts.
Table 7 — Smart contracts — Requirements
Type of requirement Requirement
Functional requirement Control instruction
Initialization
Interrupt execution
Lifetime
Termination
Non-functional requirement Interoperability
Performance
Portability
Scalability
Security
Upgradability
6.2.5 Programming language
Before selecting a programming language to develop an application or functionality, the blockchain or DLT
that is going to be deployed for the smart contract should be explored.
Table 8 lists some aspects related to programming languages that are relevant in the context of smart
contracts.
Table 8 — Programming languages — relevant aspects to smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Compiled
programming
Smart contract
language
Smart contract
Record Ledger record
programming
record
Domain-specific
language
programming
language (DSL)
ISO/CD TSDTS 18126.2:2025(en)
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
General-purpose
programming
language (GPL)
High-level
programming
language
Interpreted
programming
language
Low-level
programming
language
Turing complete
programming
language
Turing
incomplete
programming
language
Table 9 elaborates on additional aspects of a smart contract record. The code of a smart contract developed
using a programming language supported by the blockchain or DLT platform is stored in a ledger record.
Lifetime should be considered to avoid eternal smart contracts that can cause unwanted executions in future.
Versioning should be robust for managing smart contract upgrades systematically.
Table 9 — Smart contract record — relevant aspects to smart contracts
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6
Smart contract
code
Smart contract Smart contract
Record Ledger record
record lifetime
Smart contract
version
6.2.6 Data inputs and outputs
DLT systems and smart contracts cannot access data from outside of their network. Regarding this aspect, DLT
oracles are useful for smart contracts that cannot access sources of data external to the DLT system. Some
smart contracts, especially in more complex applications, require ingestion of data external to DLT systems
during their code execution which is enabled by DLT oracles. DLT oracles can represent trusted systems
designed to supply external data to a DLT system or to respond to events from DLT systems.
DLT oracles can be categorised as follows:
— software oracles: data are retrieved from online sources, such as application programming interfaces
(APIs), websites or databases (i.e. weather data, stock prices, exchange rates);
ISO/CD TSDTS 18126.2:2025(en)
— hardware oracles: based on interaction with the physical world, they are retrieving data from sensors,
radio frequency identification (RFID) tags (a type of tracking system that uses smart barcodes in order to
identify items) or internet of things (IoT) devices;
— inbound oracles: deliver data from external sources into the blockchain (i.e. asset prices);
— outbound oracles: send information from smart contracts to the outside world (i.e. triggering a payment
in a traditional banking system);
— consensus-based oracles: use multiple data sources and validators to achieve a reliable consensus about
the correct data before passing it on to the blockchain.
Smart contracts can be differentiated based on the dependence on DLT oracles as follows.
Smart contracts that are dependent on DLT oracles require ingestion of data external to DLT systems. This
creates concern for the trustworthiness of data oracles, such as the lack of assurance in the proper and
accurate relaying of data beyond the trustworthiness of the actual data sources. Neither can ensure the
veracity and integrity of external data imported during the smart contract code execution.
Self-contained smart contracts are smart contracts that do not require ingestion of data external to DLT
systems during code execution. Smart contracts that do not require ingestion of data external to DLT systems
do not raise risks for the trustworthiness of data oracles or of the bridging mechanisms relaying such data.
The execution relies on the smart contract code.
6.2.7 Security vulnerabilities
Vulnerabilities can arise in either the smart contract itself or the underlying DLT system. Smart contract
vulnerabilities arise from various reasons including errors in the design or implementation of the contract,
bad programming practice and programming language weaknesses, malicious DLT oracles or unforeseen
interactions with other smart contracts.
Smart contract security is crucial. A primary challenge is avoiding known vulnerabilities that can be exploited
by attackers. Common examples of smart contract vulnerabilities include reentrancy attacks, denial of service
(DoS) attacks and integer overflow and underflow attacks. Secure coding practices, code reviews and audits,
testing and use of formal verification are mitigationsmitigation strategies to minimize the risk of smart
contracts exploitations. Smart contract audits assist identifying security vulnerabilities so that they can be
fixed to prevent exploitations by malicious actors.
A list of known vulnerabilities is presented in Annex C. Annex D presents a case study about exploring
vulnerabilities in smart contracts.
6.2.8 Expected outcome
An aspect to consider regarding expected outcomes from smart contracts can be the ability to meet a certain
kind of expectation. In other words, their ability to perform as expected will determine if they are fit for
purpose. Smart contracts are expected to operate in ways that primarily serve business expectations, such as
the execution of a payment transaction upon the delivery of a product or the execution of an escrow
arrangement. Business expectation can require the deployment of smart contracts that adhere to specific
business processes and arrangements. Business expectations vary from simple to complex transactions.
However, smart contracts can serve other expectations that are non-business. These can include activities,
actions or transactions that extend beyond business, trade or profession or that fall within the private or
personal sphere of affairs. For example, family expectations or arrangements or gifts can qualify as non-
business expectations.
ISO/CD TSDTS 18126.2:2025(en)
6.2.9 Role of the purpose within the system
Smart contracts in DLT systems can be categorized into three distinct types based on their role and interaction
within the system as follows:
— In-ledger / in-chain smart contracts
These contracts operate at the core of the DLT infrastructure. Their role is to execute programmable
consensus conditions (e.g. block validation or consensus mechanisms) in coordination with validators miners.
They ensure the technical stability of the decentralized ledger (e.g. managing mining rewards, updating
consensus rules). Their scope is strictly protocol-bound and does not provide external services.
— On-ledger / on-chain smart contracts
Focused on digital services, these contracts execute programmable transactions directly recorded on the
ledger (e.g. tokenized asset transfers, decentralized finance (DeFi) platforms). They interact with end-users
and stakeholders through native interfaces, shaping the network’s economic viability. Their logic is
transparent and immutable but dependent on the system’s performance.
— Off-ledger / off-chain smart contracts
Designed to integrate external data or functionalities, these contracts act as DLT bridges (e.g. oracles for
financial data, decentralized storage). They address challenges like privacy (via off-chain computations) or
scalability (by minimizing ledger usage). Their execution can be bidirectional, combining cryptographic proofs
and external triggers.
6.2.10 Source of value
Source of value can be categorized as intrinsic value or extrinsic value.
Intrinsic value smart contract is the smart contract that does not incorporate any right or have any connection
with any asset, right or value outside the DLT system. The value referenced or incorporated in the smart
contract is within the DLT system.
Extrinsic value smart contract is the smart contract that incorporates rights or have a connection with an asset,
right or value outside the DLT system.
6.3 Taxonomy of smart contracts application domains, use cases purposes and economic
activity sectionssection
6.3.1 Overview
Smart contracts use cases are described by standardization bodies, policy making bodies, developers,
manufacturers, solution providers, consulting companies, economic organizations, academics and
researchers. This results in diverse and non-harmonized documentation.
This subclause generalizes specific smart contract use cases so that they apply to more than one activity sector.
It does so by distinguishing cross-sector application domains, cross-sector smart contract use case purposes
and economic activity sections.
ISO/CD TSDTS 18126.2:2025(en)
6.3.2 Taxonomy of application domains
Application domains are described as areas of interest where smart contracts apply. Cross-sector application
domains bring a first abstraction layer for any smart contract service or solution deploying any use case in
[2]
any activity sector. See ISO/TS 23258 ISO/TS 23258.
Common legal and regulatory obligations can benefit from, and require, common smart contract standards.
Common standards for smart contracts supporting regulatory or regulated services can contribute to
transparency and auditability by providing a solid framework for smart contract design and execution. This
facilitates audits and reviews by third parties and allows stakeholders, such as financial entities and
regulators, to verify the integrity and credibility of smart contract solutions us
...