Government Blockchain Association

Blockchain Maturity Model (BMM)

Blockchain Maturity Requirements
Version: 0.9
Date: November 11, 2021
Status: Draft

Approvals

Executive Director
Gerard R. Dache Title Date

Director, Standards
Meiyappan Masilamani Title Date

This document is the work product of the GBA Standards & Certification Working Group.
 Government Blockchain Association
Blockchain Maturity Model

Contents
1 Introduction.............................................................................................................................1
1.1 Purpose.............................................................................................................................1
1.2 Scope.................................................................................................................................1
1.3 References.........................................................................................................................1
1.4 Structure...........................................................................................................................2
1.4.1 Level 1: Feasible.........................................................................................................2
1.4.2 Level 2: Functional.....................................................................................................2
1.4.3 Level 3: Operational...................................................................................................2
1.4.4 Level 4: Stable............................................................................................................2
1.4.5 Level 5: Scalable.........................................................................................................2
1.5 Terms & Definitions..........................................................................................................2
2 Elements..................................................................................................................................2
2.1 Decentralization................................................................................................................1
2.2 Governance.......................................................................................................................2
2.3 Identity Management.......................................................................................................3
2.4 Interoperability.................................................................................................................4
2.5 Performance......................................................................................................................4
2.6 Privacy...............................................................................................................................5
2.7 Reliability...........................................................................................................................6
2.8 Resilience (Fault Tolerance)..............................................................................................7
2.9 Security..............................................................................................................................7
2.10 Sustainability.................................................................................................................8
3 Domain Specific Requirements................................................................................................9
3.1 Financial Services..............................................................................................................9
3.1.1 Level 1: Feasible.........................................................................................................9
3.1.2 Level 2: Functional.....................................................................................................9
3.1.3 Level 3: Operational...................................................................................................9

Status: Draft Page i Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model

3.1.4 Level 4: Stable..........................................................................................................10

3.1.5 Level 5: Scalable.......................................................................................................10
3.2 Election Systems.............................................................................................................10
3.2.1 Level 1: Feasible.......................................................................................................10
3.2.2 Level 2: Functional...................................................................................................10
3.2.3 Level 3: Operational.................................................................................................10
3.2.4 Level 4: Stable..........................................................................................................10
3.2.5 Level 5: Scalable.......................................................................................................10

Appendixes:
A Terms & Definitions
X Authors, Contributors, and Acknowledgements
ACM Amendment History and Change Management

Status: Draft Page ii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

GBA BMM Contributors

This standard was developed by experts from around the world from a diverse range of
industries, technologies, and cultures. This document was drafted by, reviewed, and baselined
by the following contributors.

Allyson Ugarte
Rose Enterprises

David Hardidge
Queensland Audit Office

Dino Cataldo Dell'Accio

United Nations

Frederic de Vaulx
Prometheus Computing

Gerard Dache
Govt. Blockchain Assoc.
Ismael Arribas
International Standards
Organization
John Carpenter
Global Blockchain Summit

Juan Cabrera
Govt. Blockchain Assoc.

Meiyappan Masilamani
Govt. Blockchain Assoc.

Paul Dowding
L4S Corporation

Tatiana Revoredo
The Global Strategy

Status: Draft iii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

1 Introduction
Blockchain is a rapidly advancing technology. It is the core technology behind
cryptocurrency and in about ten years has exploded to become the 7th largest economy in
the world. However, it is still very much an immature technology. Organizations around the
world are building platforms, application, and implementing the technology in almost every
industry. Some governments are in the process of purchasing and acquiring blockchain
based solutions. However, they have little if any experience in acquiring, implementing, or
maintaining blockchain based systems.
This model is not associated with a specific single domain solution but developed to be
applicable to solutions in all domains.

1.1 Purpose
The purpose of the Blockchain Maturity Model (BMM) is to provide government
acquisition professionals a framework to assess blockchain based solutions for suitability
for use in enterprises or as a basis to support optimal acquisition decisions.
This model also has requirements and expectations to establish, implement, maintain,
and continually improve blockchain solutions. The requirements in this document shall be
satisfied to achieve a Government Blockchain Association (GBA) certification.

1.2 Scope
This standard applies to a blockchain solution and not an organization or the processes
used to develop the blockchain solution.

1.3 References
The BMM has five components 1in the series. They are:
 BMM Overview
 Blockchain Maturity Requirements
 Training Program Requirements
 Assessment Program Requirements
 BMM Terms & Definitions
This document describes the Blockchain Maturity Requirements that form the basis for
both training and certification.

1
At the present time, this document is the only component that is ready for review and comment. The
other components are in early-stage development.

Status: Draft iv Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

1.4 Structure
The capabilities defined in the Blockchain Maturity Model (BMM), are articulated in two
types of requirements and expectations for assessment. There are Generic requirements
& expectations, and Domain specific requirements & expectations.
Generic requirements & expectations refer to the set of elements that a blockchain
solution should have for it to be a reliable solution. Domain specific are a set of elements
that are necessary for the application of blockchain technology to specific domains.
Within each element, there are five levels. The five levels relate to degrees of reliability
and dependability for the given element or domain specific element.  The five levels are:
• Level 1: Feasible
• Level 2: Functional
• Level 3: Operational
• Level 4: Stable
• Level 5: Scalable

To be assessed at any level, all expectations of that level, and below, must be met for all
the capabilities.
1.4.1 Level 1: Feasible
Elements are assessed as “feasible” when there is adequate evidence of their capability
to function as intended based on the results of preliminary analysis, studies, and test
results. The evidence should be suitable to support further research & development
funding.
1.4.2 Level 2: Functional
Elements are assessed as “functional” when there is adequate evidence that –
individually considered – they function as intended, generating the expected outcome
and, therefore, they are ready for proof-of-concept deployment.
1.4.3 Level 3: Operational
Elements are assessed as “operational” when there is adequate evidence that they work
as intended, generating the expected outcome, together with all the other parts of the
blockchain solution. Hence, the solution is capable of operational deployment, with
supporting documentation and recording of its performance.

Status: Draft v Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

1.4.4 Level 4: Stable

Elements are assessed as “stable” when there is adequate evidence that they are
capable of maintaining continuity of their operations, with consistent and reliable
performance, over a long-period period of time.
1.4.5 Level 5: Scalable
Elements are assessed as “scalable” when there is adequate evidence that they are
capable of adapting to any scale of deployment, while maintaining consistent and
reliable performance.

1.5 Terms & Definitions

The terms and definitions used in this model are recorded in Appendix A: Terms &
Definitions.

2 Elements
For a solution to be reliable for use by organizations, it must be capable of meeting
requirements and expectations in the following elements:
 Decentralization  Privacy
 Governance  Reliability
 Identity Management  Resilience
 Interoperability  Security
 Performance  Sustainability
The following subparagraphs describe each element along with requirements and
expectations associated with each level.

2.1 Decentralization2
The goal of decentralization in a blockchain solution is to measure the degree of
distribution of nodes to maximize the benefits of blockchain technology. The table below
describes the requirements associated with each Level. The sub paragraphs below the
table provides the expectations and outcomes for each level depicted in the table.
Level 1: Feasible A charter3 shall address how the system shall be designed to
write and read data to a distributed system wherein control is
distributed among the persons or organizations participating
in the operation of the system.

2
See the glossary for the term “Decentralization”
3
See glossary for the definition of the term “Charter”

Status: Draft vi Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Level 2: Functional The system shall consist of independently controlled validator

nodes that have a decentralization score 4 of five (5) or higher.
No single person or entity may have administrative control of
the hardware for more than 50% of the nodes. This includes
nodes hosted on the same cloud provider.
The administrative control of hardware shall be with a person
or legal entity that exists in the jurisdiction of more than one
city.
Level 3: Operational The system consists of independently controlled validator
nodes that have a decentralization score of twenty-five (25)
or higher.

No single person or entity may have administrative control of

the hardware for more than 25% of the nodes. This includes
nodes hosted on the same cloud provider)

The administrative control of hardware shall be with a person

or legal entity that exists in the jurisdiction of more than one
state or province.
Level 4: Scalable The system consists of independently controlled validator
nodes that have a decentralization score of one hundred
twenty-five (125) or higher.

No single person or entity may have administrative control of

the hardware for more than 15% of the nodes. This includes
nodes hosted on the same cloud provider)

The administrative control of hardware shall be with a person

or legal entity that exists in the jurisdiction of more than one
country.
Level 5: The system consists of independently controlled validator
Maintainable nodes that have a decentralization score of six hundred
4
See the glossary for the term “Decentralization Score”

Status: Draft vii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

twenty-five (625) or higher.

No single person or entity may have administrative control of

the hardware for more than 10% of the nodes. This includes
nodes hosted on the same cloud provider)

The administrative control of hardware shall be with a person

or legal entity that exists in the jurisdiction of more than one
continent.

2.2 Governance
The goal of governance5 in a blockchain solution is to provide effective management of
key components, including assets, nodes, consensus mechanisms, infrastructure/network,
system, participants, protocols, records, and smart contracts or life cycle scripts.
Governance may be performed by a variety of mechanisms ranging from a centralized
authority to one or more mutualized network agreement. The table below describes the
requirements associated with each Level.
Level 1: Feasible The process for governing the solution shall be documented.
the governance plan and/or model shall include the following
minimum criteria:
● How data is protected and governed
● How decisions are made
Level 2: Functional The blockchain solution is governed by a group of people
and/or devices in accordance with the governance
established at level one.
Level 3: Operational Governance of the blockchain is performed by adjusting
resource allocation in response to blockchain performance
and activity.

The governance model includes the following activities:

5
ISO-37000 Guidance for the Governance of Organizations for supplemental guidance to this element.

Status: Draft viii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

● Governance rules and roles are established (plan)

● Blockchain solution functions according to the rules
and roles (do)
● The compliance and efficacy is monitored (check)
● Rules and roles are modified to maintain performance
standards and expectations (act)
Level 4: Stable The blockchain is governed by a group of stakeholders that
may be node operators, token holders, or users of the
blockchain system.
Level 5: Scalable The blockchain is governed by a broad group of global
stakeholders that may be node operators, token holders, or
users of the blockchain system.

2.3 Identity Management

The goal of identity management in a blockchain solution is to ensure that the blockchain
can satisfy regulatory and legal requirements imposed by many governments to Know
Your Customer (KYC) and to implement Anti-Money Laundering (AML) protections at the
required node or network level. The table below describes the requirements associated
with each level.
Level 1: Feasible The solution includes individual profiles with unique
identification and tracking of user activity. The project
charter shall identify requirements for identity
management.
Level 2: Functional Verification of name, email address, and phone number is
required to access and use the solution.
Level 3: Operational The solution requires the uploading of identity information
such as a government issued driver’s license or other
institutional credentials.
Level 4: Stable The solution compares user provided identity credentials
with government or other official identities through an
automated interface with credentialing authorities.
Level 5: Scalable The system uses biometrics and other immutable

Status: Draft ix Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

characteristics to validate identity.

2.4 Interoperability
The goal of interoperability is to facilitate the ability of a blockchain solution to share and
use information and assets with other legacy and blockchain solutions. The table below
describes the requirements associated with each Level.
Level 1: Feasible The project charter describes other systems that will need
to interoperate with the blockchain solution.
Level 2: Functional The blockchain solution has the capability to write data and
read data to external systems.
Level 3: Operational
Level 4: Stable The blockchain solution communicates with other systems
that are owned, operated, and used by parties outside of
their own organization or community.
Level 5: Scalable The blockchain solution interoperates with other systems
using industry recognized standards, interfaces or
protocols.

2.5 Performance
The goal of performance in a blockchain solution is to ensure that the transaction
volumes and speed are suitable for the use of the blockchain. This is measured based on
an understanding of demand requirements and resource utilization. It includes
consideration of latency, memory, transaction speeds, transaction finalization 6
Specific factors are considered for domains. See the Domain Specific Requirements
section of this document for additional information. The table below describes the
requirements associated with each Level.

Level 1: Feasible The demand and resource utilization is defined, modeled

and documented in a project proposal, charter, design or
other solution documents. It includes the consideration of

6
See glossary for definition of transaction finalization.

Status: Draft x Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

latency, capacity throughput and scalability. Performance

measures of key component are identified.
Level 2: Functional The blockchain solution has a mechanism to measure
utilization of key components 7against threshold targets.
Level 3: Operational The blockchain solution has a mechanism to adjust
resources to meet changes in demand and to respond to
peak or unusual demand surges.
Level 4: Stable Predictive analytics and/or statistical process controls are
used to anticipate demand changes and to preemptively
adjust resources in advance of demand increases that may
impact performance.
Level 5: Scalable A system of incentives is in place to respond to current and
future demand requirements without the intervention of
any single party or administrator. A decentralized or
automated function is in place that is not dependent on any
person or organization.

2.6 Privacy
The goal of privacy in a blockchain solution is to ensure that the solution has an adequate
encryption and protections of Personal Identifiable Information (PII) in accordance with
international standards such as the General Data Privacy Regulation (GDPR) internally and
externally to the network considering the key components, composed of nodes,
consensus mechanisms, infrastructure/network, system, deterministic scripts and smart
contracts.
The table below describes the requirements associated with each Level. The sub
paragraphs below the table provides the expectations and outcomes for each level
depicted in the table.
Level 1: Feasible Privacy objectives and controls are defined for each
component of the blockchain solution. Project Charter for
Privacy shall be documented.
Level 2: Functional Privacy objectives and controls are defined, documented and
evident for each component of the blockchain solution.

7
See glossary for definition of key components

Status: Draft xi Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Level 3: Operational Privacy objectives and controls are defined, documented, and
tested for each component of the blockchain solution.
Determination of the level of privacy meets the minimum
requirements of the participants or regulatory authorities.
Level 4: Stable Privacy objectives and controls are defined, documented, and
tested for each component of the blockchain solution. A Risk
assessment is conducted, and mitigating controls are
implemented at the enterprise level.
The level of privacy demonstrably meets the minimum
requirements of the participants or regulatory authorities.

Level 5: Scalable Privacy objectives and controls are defined, documented, and
tested for each component of the blockchain solution.
An Impact assessment is conducted, and mitigating controls
are implemented at the enterprise and global level.
The level of privacy demonstrably meets the minimum
requirements of the global participants or regulatory
authorities.

2.7 Reliability
The goal of reliability in a blockchain solution is to provide the assurance that adequate
controls address and mitigate the resolution of the disputed forks, blocks, errors or fraud
within the performance and security criteria of the network. The table below describes the
requirements associated with each Level. The sub paragraphs below the table provides
the expectations and outcomes for each level depicted in the table.
Level 1: Feasible Project Charter shall describe how controls address and
mitigate the resolution of the disputed forks, blocks, errors or
fraud within the performance and security criteria of the network .
Level 2: Functional The solution shall implement a mechanism to ensure it is
partition tolerant.
Level 3: Operational The solution shall include a mechanism where inconsistencies
in the network wide data on the blockchain is identified and

Status: Draft xii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

resolved via an automated process.

Level 4: Stable The solution shall automatically prove and present it’s
integrity. It also includes safeguards and segregation of duties
to limit unauthorized tampering of network wide data by
large scale enterprise actors such that it would be logistically
unlikely or financially detrimental to be attempted.
Level 5: Scalable The solution includes safeguards and segregation of duties to
limit unauthorized tampering of network wide data by large
scale enterprise actors by being beyond the computational
means available at present.

2.8 Resilience (Fault Tolerance)

The goal of resilience in a blockchain solution is to ensure the continuity of operations
during unforeseen events, limitations, and failures. Resilience management aims at
optimizing the capacity and availability of critical components. Critical components may
include nodes, consensus mechanisms, infrastructure/network, system, smart contracts
and deterministic scripts. The table below describes the requirements associated with
each Level.
Level 1: Feasible The blockchain solution shall be described in terms of critical
components that if fail, degrade the blockchain functionality.
Each component has a defined threshold that would impact
performance.
Level 2: Functional The blockchain solution has documented measures that
describe the performance of the critical components and the
overall process.
Level 3: Operational A capacity assessment of critical components is established,
implemented, and maintained.

The critical components are monitored to verify operational

status and corrective action taken if a system failure is

Status: Draft xiii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

identified.
Level 4: Stable Critical components are quantitatively analyzed to predict
and prevent failure. Preventive action is taken to ensure
system uptime and performance in accordance with defined
expectations.
Level 5: Scalable Mechanisms are in place to automatically adjust the
availability and capacity of critical components.

2.9 Security
The goal of security in a blockchain solution is to provide assurance that adequate
controls address and mitigate the security risks of its key components, composed of
nodes, consensus mechanisms, infrastructure/network, system, deterministic scripts and
smart contracts.
The table below describes the requirements associated with each Level.
Level 1: Feasible Security objectives and controls for confidentiality, integrity,
availability, and partition tolerance are defined for each
component of the blockchain solution. Project Charter for
Security shall be demonstrated.
Level 2: Functional Security objectives and controls are defined and documented
for each component of the blockchain solution.

A risk assessment methodology and plan is established that

addresses applicable threats associated with the STRIDE
threat model (spoofing, tampering, repudiation, information
disclosure, denial of service, and elevation of privileges)
Level 3: Operational Security objectives and controls are defined, documented,
and tested for each component of the blockchain solution.

A risk assessment is conducted, documented, and

Status: Draft xiv Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

implementing the controls and document the residual risks.

Level 4: Stable Security objectives and controls are defined, documented,
and tested for each component of the blockchain solution. A
technical vulnerability assessment is conducted, and
mitigating controls are implemented at the enterprise level.
Level 5: Scalable Security objectives and controls are defined, documented,
and tested for each component of the blockchain solution. A
technical vulnerability assessment is conducted, and
mitigating controls are implemented at the global level.

2.10 Sustainability
The goal of sustainability 8in a blockchain solution is to ensure that the resources required
to sustain the solution are socially responsible. The primary resource for a blockchain is
energy. Consequently, this element focuses on energy consumption, efficiency, and
optimization.
The table below describes the requirements associated with each Level. The sub
paragraphs below the table provides the expectations and outcomes for each level
depicted in the table.
Level 1: Feasible The amount of energy consumption is estimated, considered,
and documented.
Level 2: Functional The energy consumption of the solution is measurable.
Level 3: Operational The solution provides incentives to conserve energy
consumption.
Level 4: Stable The solution uses mechanisms to manage energy
consumption.
Level 5: Scalable The solution uses self-adjusting mechanisms to optimize
energy consumption.

8
The authors of this model recognize that sustainability includes many aspects beyond energy
consumption. However, the measures that relate to a blockchain solution have not yet been determined.
Other sustainability goals and objectives may be included in future versions of this model as they become
apparent to the BMM team.

Status: Draft xv Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

3 Domain Specific Requirements

The requirements below are supplemental to the required elements described above. The
domain specific requirements are applicable to achieving a supplemental BMM rating. The
following domain specific supplements are available.
 Elections
 Financial Services
 Gaming
The requirements are described below in the sub-paragraphs.

3.1 Financial Services

Blockchain solutions used for financial services shall identify operational concepts and
scenarios that are unique to their regulatory and statuary (legal) requirements. The table
below describes the requirements in detail.
3.1.1 Level 1: Feasible
The project charter shall identify or reference the statutory and regulatory authorities
that have jurisdiction over the implementation, maintenance, and transaction
processing of the blockchain solution. It also includes or references technical,
operational, and procedural requirements.
3.1.2 Level 2: Functional
Blockchain solutions for the financial services industry shall be capable of processing
future dated transactions, obligations (i.e. payables and receivables). They shall also
have the capability to support accounting and reconciliation tasks and activities.
3.1.3 Level 3: Operational
No additional requirements.
3.1.4 Level 4: Stable
No additional requirements.
3.1.5 Level 5: Scalable
Latency, memory scalability and computational scalability need also to be considered

3.2 Election Systems

3.2.1 Level 1: Feasible
No additional requirements.

Status: Draft xvi Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

3.2.2 Level 2: Functional

No additional requirements.
3.2.3 Level 3: Operational
No additional requirements.
3.2.4 Level 4: Stable
No additional requirements.
3.2.5 Level 5: Scalable
No additional requirements.

Status: Draft xvii Date: 11/11/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix A: Terms & Definitions

Term Definition
Administrative Control The ability to make changes to either node hardware or ledger
updates.
Asset Anything that has value to a stakeholder. See ISO/TS 19299:2015
3.3
Block Structured data comprising block data and a block header
Block data Structured data comprising zero or more transaction records or
references to transaction records.
Block header Structured data that includes a cryptographic link to the previous
block unless there is no previous block
Block reward reward given to miners or validators after a block is confirmed in a
block chain system
Blockchain distributed ledger with confirmed transactions organized in an
append-only, sequential chain using cryptographic links
Blockchain system system that implements a blockchain
Charter The term “charter’ or “project charter” refers to one or more
documents that describes how the blockchain solution will be
implemented. It could be a proposal, white paper, project plan,
design document, technical data package or any other
combination of work products that define the intentions of parties
to implement a blockchain solution.
Components Referred to nodes, consensus mechanisms,
infrastructure/network, system, deterministic scripts and smart
contracts.

Consensus Agreement among DLT nodes that a transaction is validated and that the
distributed ledger contains a consistent set and ordering of validated
transactions

Consensus Mechanism Rules and procedures by which consensus is reached

Consensus Mechanisms

Crypto-asset Digital asset implemented using cryptographic techniques

Status: Draft B-1 Date: 5/7/2021
 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix A: Terms & Definitions

Term Definition

Cryptocurrency crypto-asset designed to work as a medium of value exchange

Cryptographic hash function mapping binary strings of arbitrary length to binary strings of
fixed length, such that it is computationally costly to find for a given output
function
an input that maps to the output, it is computationally infeasible to find for
a given input a second input that maps to the same output, and it is
computationally infeasible to find any two distinct inputs that map to the
same output

Cryptographic link Reference, constructed using a cryptographic hash function technique,

that points to data.

Cryptography Discipline that embodies the principles, means, and methods for the
transformation of data in order to hide their semantic content, prevent
their unauthorized use, or prevent their undetected modification.

Decentralization This term is used to describe the degree to which decision or

actions can be taken by a single party compared to a general
population of stakeholders

Decentralization

Decentralization Score A value or measure that describes the level of decentralization. It consists
of multiplying the number of validator nodes by the percentage of nodes
that need to achieve consensus.

Decentralized application Application that runs on a decentralized system

DApp

Decentralized system distributed system wherein control is distributed among the persons or
organizations participating in the operation of the system

Status: Draft B-2 Date: 5/7/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix A: Terms & Definitions

Term Definition

Digital Asset Asset that exists only in digital form or which is the digital representation
of another asset.

Domain Area The set of functions that are necessary for the application of
blockchain technology for specific uses.

Element A single characteristic that a blockchain solution should have for it

to be a reliable solution.

Elements The set of characteristics that a blockchain solution should have

for it to be a reliable solution.

Immutability property wherein ledger records cannot be modified or removed once

added to a distributed ledger

Interoperability The ability of two or more systems or applications to exchange

information and assets. It also includes the ability to mutually use the
information and assets that have been exchanged.

Key Component A component that if it fails or is degraded would negatively impact the
overall performance of the blockchain solution.

Nodes

Shall Referring to a mandatory requirement.

Should Refers to support the establishment, implementation,
maintenance and continually improve.

Smart Contract

Transaction Finalization

Status: Draft B-3 Date: 5/7/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix A: Terms & Definitions

Status: Draft B-4 Date: 5/7/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix X: Authors, Contributors, and Acknowledgements

Special thanks to the following people for their hard work, contributions, and inputs:

Status: Draft B-1 Date: 5/7/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix ACM: Amendment History and Change Management

Amendment History and Change Management

Version Changes / Reasons Change reference Changed by Date
v0.1/draft Initial Initial Executive 01Oct2020/
Director 01Nov2020
v0.2/draft Compliance with other Section 3.2 and Sub Executive 06Nov2020
Guideline and Standards Sections (SS) and their Director
added as Section 3.2.1 requirements
and subsequent section
numbers changed until
Section 3.2.9. Ballot
Presentation changed to
Ballot Delivery. Included
3.2.7 Ballot Return.
v0.3/draft This new Appendix ACM Appendix ACM Working 24Nov2020
added for tracking the Group
amendments and Leader
manage the changes.

V0.4/draft 2.9 Reliability element 07Jan2021

inclusion.
Deletion of the sub
sections of the Functional
Areas 3.1 and 3.2
Inclusion of the reference
of Technical
Ver Addition in introduction, 21Jan2021
0.5/draft Detailing the level five of
the Governance in par to
Definition towards global.
Detailed this BMM as
Requirements &
Expectations.

Status: Draft B-1 Date: 5/7/2021

 Government Blockchain Association
Blockchain Maturity Model (BMM)

Appendix ACM: Amendment History and Change Management

Ver0.6/draft Addition of 10th element 22Apr2020
“Sustainability”, With in
the meetings held it has
been decided to have the
ISO standards referred
for reaching the
expectations. Against
each level the
requirements will be
given. Security level
approach will be
maintained for all the
elements. Removing the
Functional areas (3.1 to
3.2.9) from this
document. The Levels 3
and 4 amended.

Status: Draft B-2 Date: 5/7/2021