2ND GLOBAL ENTERPRISEBLOCKCHAIN
BENCHMARKING STUDY
Michel Rauchs, Apolline Blandin, Keith Bear, Stephen McKeon
2019

VOTE

supported byTable of Contents
Forewords..............................................................................................................4
Research Team.......................................................................................................7
Acknowledgments.................................................................................................8
Executive Summary.............................................................................................10
Section 1: Blockchain 101 - Clearing up Common Misconceptions...................... 12

Introducing key concepts......................................................................................................................................... 12
Mapping different interpretations............................................................................................................................ 15

Section 2: Introducing the Enterprise Blockchain Ecosystem..............................21
Exploring the landscape........................................................................................................................................... 21
Meet the industry actors........................................................................................................................................... 23
Industry development.............................................................................................................................................. 25

Section 3: State of Adoption...............................................................................30
Moving to production.............................................................................................................................................. 30
Project lifecycle......................................................................................................................................................... 31
Project scope............................................................................................................................................................ 32
Network design........................................................................................................................................................ 37

Section 4: Blockchain Strategy and Business Models..........................................45
User motivations....................................................................................................................................................... 45
Strategy implementation.......................................................................................................................................... 47
Internal evaluation of activities................................................................................................................................. 50
Vendor strategies..................................................................................................................................................... 54
Blockchain revenue models...................................................................................................................................... 56

Section 5: Looking Ahead - What does the Future Hold?....................................58
Appendix I: Study Sample...................................................................................64

Survey data............................................................................................................................................................... 64
Live network data..................................................................................................................................................... 65

Appendix II: Technology Platforms......................................................................66

Codebase................................................................................................................................................................. 66
Data Broadcast......................................................................................................................................................... 67
Network consensus.................................................................................................................................................. 67
Smart contracts......................................................................................................................................................... 68
Privacy and confidentiality........................................................................................................................................ 69

Appendix III: Challenges......................................................................................70

Operational challenges............................................................................................................................................ 70
Technical challenges................................................................................................................................................. 71

Forewords

Forewords
Terms such as “blockchain” and “distributed ledger technology (DLT)” haveestablished themselves in our daily lexicon. Yet, rarely do they relate to thesame thing. Unfortunately, this conflation of terminology hampers a clear
assessment of blockchain technology adoption in different industries. Our
2nd Global Enterprise Blockchain Benchmarking Study seeks to shed lighton the diverging interpretations of these terms and the potential confusion
being created. The report delves into the granular detail of how theenterprise blockchain ecosystem has evolved since the publication of our
first report in 2017, by using data collected from more than 160 entities and67 live networks.
We believe this report is distinguished from other studies by its focus
on the state of network deployment and its investigation of the different
development stages of ongoing enterprise blockchain-based projects. Thisapproach has revealed several patterns of development that provide bothindustry participants and the wider public with common points of reference
to build upon. In multiple industries, enterprise blockchains are perceived
as a solution to establish common data standards across organisations,eliminate organisational silos, and facilitate record reconciliation to help
improve overall efficiency and enable the creation of new services.
Adoption of enterprise blockchains within the private sector has been
increasing with several networks moving from ideation to production overthe course of 2018 and 2019. However, the technology is not a panacea andcomes with its share of trade-offs that industry adopters are experiencing
first-hand. As empirically demonstrated in this report, blockchain adoption
by incumbents is indeed a slow and challenging process that requires deep
cross-organisational coordination and careful legal and organisational
design choices. This may at least partly explain the dominance of centralised
approaches to system design observed across the majority of deployednetworks, albeit with an expectation of a gradual distribution of control overthe course of time.
Our hope is that this analysis will make a critical contribution to deconstruct
the enterprise blockchain ecosystem globally. As always, we recognise that
our ability to produce high quality research is highly dependent on thecooperation of industry initiatives and entities and we extend our thanks tothose that have contributed information and data to the co-authors of thisreport.
Dr. Robert Wardrop
Director
Cambridge Centre for Alternative Finance4

2nd Global Enterprise Blockchain Benchmarking Study

The 2nd Global Enterprise Blockchain Benchmarking Study is astraightforward and comprehensive look at the state of blockchain affairs
across the financial services industry. It gives insight into the realities of how
blockchain initiatives are structured, supported and moving to production
with a special focus on private, permissioned Distributed Ledger Technology(DLT). The findings of the study can be corroborated by Invesco’s own
experiences in initiating blockchain and DLT proof-of-concepts (PoCs) tohelp people get more out of life through a superior investment experience.
The study looks at over 160 stakeholders from a global sample of 49
different countries and begins by setting context around defining blockchain
projects. It dives into the terminologies surrounding blockchain initiatives
distinguishing between true DLT projects from the “blockchain meme”, away of classifying projects that satisfy the blockchain hype as opposed to
deploying truly transformational DLT networks. A few salient points shine
through in the report: one being that the success of blockchain cannot
and will not happen in isolation as the power is in the network, that truetransformation of ecosystems takes time, and that new technologies must
prove themselves to build trust in the new paradigm.
It has been noted in some places, that blockchain has entered the “Troughof Disillusionment” phase of the technology hype curve as defined by
Gartner. This study shows that experimentation, adoption, and execution
are still strong, but that most blockchain initiatives fall into the realm of the“blockchain meme”, and “only 3% of analysed networks meet the criteria
of full multi-party consensus systems, whereas one fifth of projects can beconsidered potential DLT systems that are gradually progressing towards
removing single points of failure and control.” There is also still a strong
misconception of trust on the blockchain. Potential participants get wary
about whether blockchain can be trusted; however, it is primarily the on / offramps that are the vulnerable exposure points to malicious intent rather than
the technology.
Blockchain has its roots in Bitcoin, a fit for purpose digital currency andtransactional accounting ledger enabling trust among untrustworthy actors.
Observers caught on that the concepts that make the blockchain whole
could be applied elsewhere, thus, blockchain started as a utopian solution
looking for a problem, which contributed to the adoption of “blockchain
meme” initiatives. Blockchain is still in the early stages of providing real
solutions for actual problems.
The financial services industry is a complex ecosystem, and we’re all living
through the blockchain/DLT transformation together. The true disruptive
potential means that entire paradigms and operating models could beturned on their heads. Many players are exercising caution as they proceed
in into unchartered territory as there are incumbents in positions of power
who will be severely disrupted by blockchain’s success. These players have avested interest to ensure that the technology is not successful.
We’d like to thank all of the individuals and teams dedicated to creating
this global study. As Invesco continues to move forward in our quest to
deliver alpha generating performance and an elite client experience, we’reundertaking multiple blockchain initiatives across various intersections of5

Forewords

our value chain. Our relationship with the CCAF and the access to reports
such as this Global Benchmarking study serve to provide a glimpse into theoverall trends occurring across financial services that help us calibrate ourstrategy and make informed decisions on the right pace at which to move in
adopting blockchain/DLT technology.
Dave Dowsett
Global Head of Technology Strategy, Emerging Technology& Intentional Innovation
Invesco6

2nd Global Enterprise Blockchain Benchmarking Study

Research Team
Authors
Michel Rauchs: Michel is the Lead in Cryptocurrency and Blockchain at the Cambridge Centre for
Alternative Finance.
m.rauchs@jbs.cam.ac.uk		

@mrauchs

Apolline Blandin: Apolline is a Research Manager in Cryptocurrency and Blockchain at the
Cambridge Centre for Alternative Finance.
a.blandin@jbs.cam.ac.uk		

@ApollineBlandin

Keith Bear: Keith is a Research Fellow at the Cambridge Centre for Alternative Finance at
Cambridge Judge Business School.
k.bear@jbs.cam.ac.uk
Stephen McKeon: Stephen is an Associate Professor of Finance at the University of Oregon and a
Visiting Associate at the Cambridge Centre for Alternative Finance.
smckeon@uoregon.edu 		@sbmckeon

7

Acknowledgments

Acknowledgments
We would like to thank Invesco for sponsoring the research study, and specifically Dave Dowsett,
Kevin Lyman, Henning Stein, Bradley Bell and Heather Wied for providing relentless support
throughout the research process.
We would like to express our gratitude to the following individuals for their generous support
and assistance during the research process: Ashwini Anbujaran (Hyperledger), Richard Bloch(Hyperledger), David Boswell (Hyperledger), Gideon Greenspan (Multichain), Antony Lewis (R3),
Dominic de Lisle (Calastone), Marta Piekarski (Hyperledger), William Lovell (Hyperledger), Kevin
Rutter (R3), Todd Henshaw (British Blockchain Association), and Jed Talvacchia (R3).
Special thanks go to our interns Larisa Barbu, Thomas Eisermann, Jaya Lalwani, Jinjun Liu, Jordan
Matthews, Sebastian Resano as well as our visiting students Kristina Klein and Martino Recanatinifor doing a fantastic job with regard to survey dissemination and data collection. We would also
like to thank Xiao Ling from the University of North Carolina for contributing to the survey drafts,
and Hatim Husssain and Robert Pulser for their thorough review of an early draft.
We would also like to thank the entire CCAF team, especially the Centre’s leadership Dr. RobertWardrop, Dr. Raghavendra Rau, and Bryan Zhang, for their continuous support and assistance,
and in particular our in-house designer Louise Smith for the gorgeous design of the report.
In addition we wish to think Philippa Coney and Charles Goldsmith from the Cambridge Judge
Business School for their continued support in producing and publishing this report.
Finally, this research study would not have been possible without the generous support of allorganisations that participated in our surveys:
Note: some survey respondents prefer not to publicly disclose their participation.

8

2nd Global Enterprise Blockchain Benchmarking Study

9

Executive Summary

Executive Summary
Since the publication of the first Global Blockchain Benchmarking Study in September 2017, theenterprise blockchain ecosystem has undergone considerable changes: while two years ago, theindustry landscape was mostly dominated by half-hearted experiments and short-lived proofs-ofconcepts — often announced with great fanfare and publicity, the hype has gradually given way
to genuine development of sustainable blockchain networks that are increasingly being deployedin production environments.
Between July and November 2018, the research team collected survey data from more than 160
start-ups, established companies, central banks, and other public-sector institutions from 49
different countries across the world. Additional data on 67 live enterprise blockchain networks
was collected between April and June 2019 to provide new, empirical insights into the state of theecosystem and capture major trends of the rapidly-evolving industry.
The analysis has revealed the following key findings:•

The Banking, Financial Markets and Insurance industries are responsible for the largest
share of live networks:
The trend indicated in 2017 has continued: 43% of enterprise blockchain networks
deployed in production can be attributed to Financial Services, far ahead of any othersector and industry. The specific use case of a network can be at times difficult to identify,
but supply chain tracking, trading infrastructure, and document certification seem tocurrently dominate.

•

Successful projects require a long-term perspective and commitment:
Transforming critical market infrastructure takes longer than simple application
development: the median enterprise blockchain project takes 25 months between thefirst proof-of-concept and being deployed in production, with some large-scale networks
taking more than four and a half years for the full launch.

•

Founder-led networks between partnering organisations are prevalent:
While much has been written about large-scale consortia developing new blockchain
networks, 71% of live networks have been initiated by a single founder leading theinitiative. 88% of deployed blockchains are designed for shared use between multiple
independent entities, but the majority are restricting membership to partners: only 19%
are jointly operated by direct competitors.

•

Cost reduction is the main value proposition of live networks, but increasing revenue
generation is expected in a second phase:
72% of live networks are currently primarily used to reduce costs for participants throughreduced reconciliation efforts. However, 69% of network participants indicate that the
key motivation for joining the project is the potential of generating incremental revenues
through the provision of new products and services.

•

Hyperledger Fabric appears to be the platform of choice across all industries:
48% of covered projects that are used in production have chosen Hyperledger Fabric as
the core protocol framework underlying the network, followed by R3’s Corda platform(15%) and Coin Sciences’ MultiChain framework (10%).

10

2nd Global Enterprise Blockchain Benchmarking Study•

The majority of live networks retain a high degree of centralisation, but plan to graduallydistribute control over time:
81% of covered networks have a leader entity dominating the governance process(centralised social consensus), and many networks — at least in their current form — use
third-party service providers to host and operate nodes on behalf of network participants(centralised network consensus).

•

Unclear terminology and marketing hype have contributed to the “blockchain meme”:
77% of live enterprise blockchain networks have little in common with multi-party
consensus systems apart from incorporating some of the same technology components(e.g. cryptography, peer-to-peer networking) and using similar nomenclature. The“blockchain meme” nevertheless acts as a powerful catalyst to overcome corporate inertia
and spur wide-reaching organisational change, both within and across organisationalboundaries.

The study also dives into major technological concepts of blockchain technology and lists the key
characteristics that a blockchain network typically fulfills. Furthermore, the report introduces thevarious types of actors that populate the ecosystem and describes their activities and associatedrevenue models, while empirically demonstrating the development of the industry with employee
growth figures. The main blockchain strategy drivers, activity assessments, and remaining key
challenges to broader adoption are highlighted and potential future trajectories are explored.

11Section 1: Blockchain 101 - Clearing up Common Misconceptions

Section 1: Blockchain 101 - Clearing
up Common Misconceptions
Introducing key concepts
Terminology: “Blockchain” or “DLT”?
There are a multitude of terms floating around the industry that, depending on the discussant,may have either the same meaning, or refer to completely different concepts. Similarly, there arevarious conflicting definitions as to what constitutes a “blockchain” or a “distributed ledger”. Thissituation frequently leads to misunderstandings and creates unnecessary confusion that hampers
further development.
Whilst we have repeatedly suggested an alternative, more generic term — distributed ledger
technology (DLT) systems — we recognise that “blockchain” and “DLT” both have establishedthemselves as umbrella terms that are often used interchangeably. We will thus use them as suchthroughout the remainder of the report.

DLT is a subset of distributed systems
DLT can be considered a subset of distributed systems, i.e. systems that consist of multiple
independent components (e.g. computers) that communicate with each other.1 They are often
based on a peer-to-peer (P2P) architecture where computers (nodes) exchange messages directly
between each other without going through a central server.

DLT systems are designed to operate in an adversarial environment
Most distributed systems consist of multiple nodes that collectively store and process data, but
are owned or controlled by a single entity. What sets DLT apart from these systems is the lackof a central authority that coordinates how nodes reach agreement over the state of the system:
DLT systems are specifically designed to operate under adversarial conditions so they can remain
operational even in the presence of unreliable components (e.g. hardware failures, connectivity
issues) and malicious actors who are trying to sabotage the system.

Key characteristics of a DLT system
A DLT system is a multi-party consensus system that enables multiple distrusting entities to reachagreement over the ordering of transactions in an adversarial environment without relying on acentral trusted party.
A DLT system needs to be capable of ensuring the following five properties:•

1

Shared recordkeeping: enable multiple separate entities to provide data inputs andparticipate in the creation of new records.

See Figure 4, page 23 in Hileman, G., and Rauchs, M. (2017) Global Blockchain Benchmarking Study. Cambridge Centre for
Alternative Finance. Available at: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3040224 [Last accessed: 29 July 2019].

12

2nd Global Enterprise Blockchain Benchmarking Study•

Multi-party consensus: require multiple separate entities to collectively reach agreement
over the ordering 2 of transactions in the absence of a central authority.

•

Independent validation: enable each participant to independently verify the state of theirtransactions and the integrity of the system. This also involves detecting unauthorisedchanges applied to records in a trivial way.

•

Tamper evidence: allow each participant to detect on-consensual changes applied torecords trivially.

•

Tamper resistance: make it hard for a single party to unilaterally change past records (i.e.
transaction history).

It is worth noting that DLT systems are dynamic and constantly evolving. This continuoustransformation may affect system characteristics and thus potentially its core properties
highlighted above. As we will see, a number of “DLT systems” currently operate in closed,
safeguarded environments with no adversarial dynamics for a variety of reasons. Moreinformation can be found in the Distributed Ledger Technology Systems: A Conceptual
Framework report from 2018.3

Permissioned vs. Permissionless
DLT systems can be public and permissionless: anyone is free to join, use, and leave the network
as well as participate in the network consensus without having to ask for permission. Because
these systems have dynamic membership (i.e. the number of peers on the network is unknown
and subject to change), they rely on a combination of economic incentives via their native token
and game theory in order to properly function and remain secure.
DLT systems can also be private and permissioned: access to the network is restricted to alimited number of participants, courtesy of a gatekeeper. Different levels of permissions (e.g. theright to participate in “network consensus”) are assigned to network participants. These systems
have fixed membership (i.e. the number of peers on the network is known): since all participants
are identified, contractual agreements can be established between them to penalise misconduct.
The remainder of this report will exclusively focus on private and permissioned DLT systems that
operate in an enterprise context.

2

In some cases, there may be multiple valid but competing claims in the system of which only one can eventually get processed(e.g. someone trying to send the same token to two different recipients simultaneously).

3

Rauchs, M. et al. (2018) Distributed Ledger Technology Systems: A Conceptual Framework. Cambridge Centre for Alternative
Finance. Available at: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3230013 [Last accessed: 18 July 2019].

13

Section 1: Blockchain 101 - Clearing up Common Misconceptions

Decomposing “consensus”
Common blockchain parlance often involves the notion of “consensus”, but generally lacks a clear
specification about the nature of agreement, i.e. what consensus is reached over. We introduce
the concept of two related, but distinct types of consensus in Figure 1.
Figure 1: Every DLT system has two types of consensus
Wider ecosystem

1. Social consensus:

Blockchain network

Reaching agreement overwhat actually constitutes
the system (incl. consensus
rules, how network
consensus is reached, etc.)

2. Network consensus:
Reaching agreement overthe system state (i.e. latest
ledger version) within
the universally-accepted
consensus rules

First, network participants and other stakeholders need to agree on the ruleset (expressed in
the protocol via the consensus rules) that governs the system as well as an adequate process for
applying changes to the rules. Social consensus goes beyond mere governance of the system:
it also involves the implicit agreement between stakeholders over the very nature (and, thus,
associated characteristics) of the system.4 Any party remotely involved in the system — whether
directly or indirectly — can potentially play a role in social consensus, although with varying
degrees of influence over the process.

“Social consensus” sets the rules while “network consensus” enforces themOnce stakeholders have agreed on the nature of the system including its key properties, network
participants need to establish agreement over the records produced by the system - i.e. thecontent itself. Network consensus refers to the process of resolving potential conflicts within theboundaries of the P2P network that may arise from multiple valid, but conflicting ledger entries.
This type of consensus, which is performed by block producers, is limited to the ordering oftransactions and operates within the socially-agreed ruleset.

Social consensus can always override network consensus
While different, both consensus types are closely linked. Social consensus implicitly includes
network consensus, as the latter produces the latest system state that is universally accepted by
all network participants and external stakeholders. It is, thus, important to point out that social
4

For instance, Bitcoin’s social consensus can be considered the implicit agreement between miners, developers, users, exchanges,
wallets, and other stakeholders over essential properties (e.g. 21-million coin limit) that “define” what Bitcoin is in the first place.

14

2nd Global Enterprise Blockchain Benchmarking Study

consensus can always override network consensus, because changes to the rules can invalidate
transaction ordering decisions taken by block producers such as miners.
A functional DLT system should have an appropriate system of checks and balances that preventsa single entity or colluding group of actors from dominating either social or network consensus,
as this would create a single point of trust - and, thus, also failure. For instance, block producers
are put in check by fully-validating nodes (auditors) that threaten to reject mined blocks that do
not comply with protocol rules.

Mapping different interpretations
Unclear terminologies, fuzzy boundaries, and the lack of robust definitions have resulted in theterms “blockchain” and “DLT” effectively losing their meaning. This development does not only
impact effective communication and understanding, but also risks the conflation of distinct
concepts under a single umbrella term making it difficult to objectively assess and compare
different projects.

The terms “blockchain” and “DLT” have effectively lost their meaning

Introducing two major interpretations
In an attempt to make the terms meaningful again and to facilitate discussions, we suggest
grouping all uses of self-labelled “blockchain” or “DLT” projects into one of two categories:
1. Use of blockchain as multi-party consensus systems:
Federated business networks with no single entity in control; operating in adversarial
environments and occasionally resolving conflicts around transaction ordering.
2. Use of blockchain as a “meme”:
No/limited notion of multi-party consensus nor potential disagreement over transaction
ordering; often acting as a catalyst for transforming a variety of systems and processes.

Category 1: multi-party consensus systems
This category refers to DLT systems as defined on page 12. The key distinctive characteristic isthe notion of multi-party consensus: several independent entities need to reach agreement overa shared set of data without relying on a central coordinator, with occasional disagreements overtransaction ordering being resolved via network consensus (see page 14).
In a permissioned environment, these systems are best described as federated business networks
that distribute control among network participants so that both social consensus and network
consensus are not prone to be easily dominated by a single entity. However, as explained in
the subsequent sections, most networks initially adopt a more centralised approach at launch
for a variety of reasons.5 As a result, we suggest referring to these networks as potential DLT or
enterprise blockchain systems as they do not meet the criteria at the time of analysis, but havea clear and committed roadmap on gradually distributing control over time as to effectively
becoming “true” multi-party consensus systems.

5

Section 3 provides an overview of the current degree of centralisation in live networks that have been deployed in production.
Section 5 presents several explanations regarding the rationale behind this approach.

15

Section 1: Blockchain 101 - Clearing up Common Misconceptions

Category 2: the “blockchain meme”
This category comprises all projects and networks that, while identifying as “blockchain” or“DLT”, do not constitute multi-party consensus systems as previously defined. Instead, theygenerally make use of several component technologies used by DLT systems in order to meetthe requirements of a given business case. Figure 2 provides an overview of the key component
technologies — cryptographic primitives and concepts from distributed systems — that are
frequently used separately.
Figure 2: Component technologies used in “blockchain”
Component Technologies
DLT systems employ a set of component technologies that can – and are – used separately

Cryptographic primitives

Distributed systems

Digital signatures: authentication

P2P networking: no central server required

Cryptographic hashing functions: integrity checks

Message passing protocols: secure messaging

Merkle trees: data structure with specific features

Consensus algorithms: (Byzantine) fault tolerance

Timestamping: proof-of-existenceDistributed databases: replication for robustness

Encryption: keep communications private“Blockchain meme” projects are designed to serve business cases in which a) the notion ofmulti-party consensus is either not required or feasible, and/or b) where disagreements over theordering of transactions (e.g. events, facts) are not possible. This means that by definition, theseprojects cannot display the key characteristics that define a blockchain or DLT system.

16

2nd Global Enterprise Blockchain Benchmarking Study

What’s the technical rationale behind the “blockchain meme”?
Projects and networks may use blockchain-related concepts and tools with no intent of
supporting multi-party consensus for a variety of reasons:•Single source of “truth”: an append-only log of events that produces a single, consistentsource of “truth” available to all participants.6•

Benefits of component technologies: the application of some cryptographic primitives andthe borrowing of specific concepts from distributed systems can provide significant benefits
to existing offerings (e.g. more security, increased resilience, additional cryptographic
assurance through independent validation, integrity checks and better authentication).

•

Readily-available blockchain protocol frameworks: off-the-shelf blockchain software libraries
and platforms that are readily available, often free and open-source, to rapidly build new
systems and networks with different permissions configurations.

•Fit-for-purpose architecture: solving for a specific use case in practical terms may mean
selecting elements that are distributed in some aspects but centralised in others. Enterpriseblockchain deployment will usually force pragmatic rather than idealistic decisions.

A characteristic common to all “blockchain meme” projects is the use of “blockchain” or “DLT”
branding when promoting their business offerings. Moreover, these projects strive to produce
a single, consistent source of records that stakeholders can access — even though the records
may only be provided by a single controlling entity through a trusted application programming
interface (API). The existence of a single, shared view of authoritative records opens up vast
opportunities that can range from better data management and sharing, to the automation ofcross-entity business processes and workflows.
There are, however, substantial differences between projects that fall into this category: as
indicated by Figure 3, an entire spectrum of project types with different objectives, design
requirements and implementations make this category rather large.

6“Truth” in this context refers to the computer science definition, in the sense that a particular piece of data in the shared ledger exists
and does not conflict with other data in the system, but the data itself is not necessarily true in the objective sense. For example, arecord saying that ‘Alice reports that the sky is yellow’ would be ‘truth’ only in that it confirms what Alice reported, not the truth of thestatement itself.

17

Section 1: Blockchain 101 - Clearing up Common Misconceptions

Figure 3: The “Blockchain meme” spectrum
The “Blockchain meme” spectrum
Sharedinfrastructure

Social coordination
mechanism

Automation ofinterorganisational
business processes“Blockchain-asan-Excuse” (BaaE)

Scope

Jointly-operated
platform

Political tool

Common data
standards

Executive buy-in
and/or marketing

Boundaries

Interorganisational

Interorganisational

Interorganisational

Internal

Locus of execution

SharedDepends on projectand implementation

Depends on
implementation

InternalHigh

Degree of interorganisational change

The “blockchain meme” is perhaps best understood as an influential driver of organisationalchange to promote the development of common data standards between entities, improving
general data availability, and reducing the number of steps required to reconcile individual
ledgers and bookkeeping systems between parties. It can, thus, be thought of as an effective
coordination mechanism for aligning interests between different stakeholders that would
otherwise not collaborate, on matters that would otherwise not be open to discussion.

The “blockchain meme” acts as an agent of behavioural change- both internally and at the industry level
As a result, the “blockchain meme” can act as a powerful catalyst to first encourage entities
to rethink existing infrastructure and business processes, and eventually move towards a newcore industry infrastructure that is commonly owned, shared, and operated by distinct parties.
The “blockchain meme” can help solve political roadblocks in the creation of industry utilities
and drive behavioural change in industries that are generally resistant to change. Depending
on design decisions and network configuration, these systems may also provide additional
cryptographic assurance that is independently verifiable by network participants.

Why does the distinction matter?
An analysis of more than 60 live enterprise blockchain networks that have been deployed in
production reveals that more than three quarters of all projects fall into the “blockchain meme”
category (Figure 4). Only 3% of analysed networks meet the criteria of full multi-party consensus
systems, whereas one fifth of projects can be considered potential DLT systems that are graduallyprogressing towards removing single points of failure and control.

18

Low

2nd Global Enterprise Blockchain Benchmarking Study

Figure 4: The majority of live enterprise blockchain networks can be categorised as“blockchain meme”
Blockchain type
3%

20%

77%

Blockchain meme
Potential multi-party consensus system
Multi-party consensus system

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

Introducing the study samples
All empirical data presented in this report is based on one of the following data samples:1.

Live network sample: CCAF-curated list of 67 enterprise blockchain networks from 25
countries globally that have been deployed in production and are currently live.

2.

Survey samples: in addition to the live network sample, the analysis is informed by datacollected via a combination of three online surveys conducted by CCAF in 2018:
a. Vendors: 60 respondents including start-ups and large corporations from 25 countries
globally.
b. Network operators, participants, and end users: 56 respondents including start-ups andlarge corporations from 22 countries globally.
c. Public sector: 45 respondents including government agencies, public institutions, andcentral banks from 33 countries globally.

More information about the samples can be found in Appendix I. Data sources will be indicatedappropriately below relevant figures and data points.

19

Section 1: Blockchain 101 - Clearing up Common Misconceptions“Blockchain meme” projects generally have little in common with DLT systems as previously
defined, yet they frequently tend to get conflated with actual multi-party consensus systems. Thisdevelopment has contributed to the widely-shared perception of “blockchain” as a magic bulletthat overestimates the actual capabilities of the technology itself. If an internal accounting system
operated by a single company can be branded as “blockchain”, it becomes increasingly difficultfor industry peers, regulators and policymakers, as well as other stakeholders to properly assess
the properties (and associated trade-offs) that distinguish “true” DLT systems from “blockchain
meme” projects. This, in turn, creates challenges for performance comparisons and evaluation ofpotential applicability and impact.
This is not to say that one category or the other is superior: in fact, it is very likely that the global
impact of “blockchain meme” projects will be greater than that of multi-party consensus systems,
simply because the emergence of common data standards for entire industries has the potential
to unleash massive efficiency improvements and the creation of new services and businessmodels. Applications of “true” multi-party consensus systems may remain niche and have little
implications beyond their narrow use case.

The “blockchain meme” has the potential tosignificantly shape the transformation of industries
Nevertheless, it is worth pointing out that the classification is not set in stone and that one
needs to be aware of the business operation and overall strategy constraints that would force
networks to start either as a “meme” or potential DLT systems. As these systems are dynamic andconstantly evolving, their respective analyses should, therefore, follow suit.

20

2nd Global Enterprise Blockchain Benchmarking Study

Section 2: Introducing the Enterprise
Blockchain Ecosystem
Exploring the landscape
In recent years, the blockchain ecosystem has seen an explosion of new entrants that haveintroduced a plethora of new projects, products, and services at an astonishing pace. This canmake it difficult for industry outsiders — and even insiders — to keep track of the proliferation ofnovel offerings that often span multiple market segments.
Figure 5 presents a useful lens to readers for exploring and navigating the changing blockchain
landscape: the framework divides the landscape into three value-creating “layers” (protocol,
network, and application) that are interconnected. It is worth noting that this mental model
is not limited to enterprise DLT projects, but can also be applied to open and permissionlesscryptoasset DLT systems.
Figure 5: A three-layer mental model for exploring the blockchain landscape3
Application layer

Digital assets

Workflow
automation

Identity andauthentication

Supply chain
tracking

Timestamping
andnotarisation

Business applications and use
cases plugging into existing
business networks to createbusiness value

2
Network layer
Business networks jointly
managed and operated bymultiple parties

Fusion Lendercomm

1
Protocol layer
Codebase frameworks andsoftware platforms
Note: this model is based on a framework initially developed by Colin Platt (2016).7

7

Platt, C. (2016) Of permissions and blockchains... A view for financial markets. Available at: https://medium.com/@colin_/ofpeDLrmissions-and-blockchains-a-view-for-financial-markets-bf6f2be0a62. [Last accessed: 05 August 2019].

21

Section 2: Introducing the Enterprise Blockchain Ecosystem

1) Protocol layer: the technological building blocks constituting the “back-end”
The protocol layer is the collection of core protocol frameworks, i.e. the set of core technologicalbuilding blocks that constitute the technological backbone of any blockchain system. The
protocol layer includes the foundational infrastructure components upon which networks andapplications are built. Given that protocols are merely code (either open-source or proprietary),
the protocol layer itself does not deliver much value without a corresponding network.
2) Network layer: the shared business networks producing a single source of “truth”
The network layer consists of the actual P2P networks that bring a blockchain system to life
by connecting participants to enable the sharing and verification of data. The network layer
comprises all business networks that are jointly operated and maintained by multiple participants
with the objective of producing a single consistent source of “truth” regarding a shared setof records. Networks can be built by either using a standard core protocol framework (e.g.
Hyperledger Fabric), or by using a combination of modular core building blocks borrowed frommultiple core protocol frameworks.
3) Application layer: the products and services that create actual business value
The application layer can be thought of as the primary user interface for blockchain networks: it
comprises business applications that connect to existing networks to make use of the underlying
set of data records that has been jointly produced and maintained by network members (“single
source of truth”). The application layer is the main driver of business value as it provides tangible
products and services to end customers and users. “Permissioned” applications that restrict
usage to select parties can also exist on top of an open, permissionless blockchain network.8
Applications can also be “blockchain-agnostic”, meaning that they can plug into several separate
networks depending on demand.9
Figure 6 uses the example of J.P. Morgan’s Interbank Information Network (IIN) to illustrate how
the three-layer framework can be used as a lens for assessing the different components of a given
project. The first live application — IIN Resolve — uses the network to streamline compliancechecks for correspondent banking in an attempt to speed up cross-border payments. Several
more applications are in development to leverage the underlying IIN network.

8

For example, the public and permissionless Bitcoin blockchain (main net) is used by permissioned applications for distributed
timestamping and notarisation.

9

We apply a broad definition to the application concept presented in this model. From a technical perspective, many services
labelled as “blockchain applications” correspond to simple plug-ins rather than veritable applications running directly on top of
the blockchain network. In this context, any external system that interacts with a distributed ledger network can be considered an
application.

22

2nd Global Enterprise Blockchain Benchmarking Study

Figure 6: Illustrating the landscape framework using J.P. Morgan’s IIN
JP Morgan’s Interbank Information Network (IIN)

3

Application

Resolve

2

First application deployed on the
IIN enabling users to streamline
compliance processes.

Network
Information sharing blockchain
business network composed of morethan 200 international banks.

Protocol1

IIN is built using the open-source
Quorum protocol framework,a permissioned variant of the
Ethereum codebase initiallydeveloped by JP Morgan.

Meet the industry actors
Actors and activity types
The blockchain enterprise ecosystem is composed of a diverse set of actors that carry out distinct
activities. Actors and activities can be grouped into six broad categories:•

Vendors design, develop, implement, and maintain the technical infrastructure powering
blockchain networks and applications.

•

Network operators are responsible for managing and governing blockchain networks,
which are jointly run and maintained by network participants.

•

Application providers offer interfaces for end users to plug into blockchain networks inorder to achieve business objectives that leverage the utility of a shared single source ofrecords.

•

A variety of other stakeholders provide tangential services and insights that benefit theecosystem as a whole.

23Section 2: Introducing the Enterprise Blockchain Ecosystem

Table 1 presents an overview of the major actor types of the ecosystem and their associatedactivities.
Table 1: Actors and activities in the enterprise blockchain ecosystem
ACTOR TYPES

Vendors
Entities that design
and build the technicalinfrastructures that powerblockchain networks andapplications

Network operators
Entities that manageand operate blockchain
networks

Network participants
Entities that directly
participate in running
blockchain networks

Application providers
Entities that createbusiness value for end
users by providing
applications that makeuse of the underlying
blockchain networks
End users
Entities that use blockchain
applications to achieve a
specific business objective

10

ACTIVITIESDESCRIPTIONCore protocol
framework
development: design,development, andmaintenance of one
or more core protocol
frameworks• Project lead: originator and lead maintainerof a core protocol framework (can be opensource or proprietary)

Solutions design:development andimplementationof actual businessnetworks for clients• Integration: help clients build and implement
blockchain networks by integrating elementsfrom existing core protocol frameworks10

Commercial
application
development

Design and develop business applications forclients that run on top of, or connect to, existing
blockchain networks

Consulting services

Ideation, business case, and roadmap
development

Administration

Govern network operations, set protocol rules,
and manage change; generally also owningand managing intellectual property (governing
entity)Permissions
management

Assign different permission levels to network
participants (e.g. right to initiate transactions or
to participate in the network consensus process

Gatekeeping

Onboard and offboard network participantsin accordance with access restriction andonboarding policy (gatekeeper)

Transaction validation

Operate and run a fully-validating node to verify
transactions and independently reconstruct thelatest system state (auditor)

Transaction processing

Participate in the network consensus process
by proposing candidate records (e.g. blocks
consisting of ordered, non-conflicting
transactions) to be added to the ledger (record
producer)

Use case servicing

Operate and maintain specialised interfaces toexisting blockchain networks that leverage theaccess to a single source of records to enable a
specific set of use cases(Application) usage

Derive value from using applications and services
enabled by a blockchain network’s single sourceof records. End users can connect indirectly via
intermediaries (e.g. API, application) or directly
by participating in the network running nodes.

• Project contribution: one of several
contributors to a core protocol framework
project• Software development platform: easy-to-use
software environment for clients to develop
their own blockchain networks

Integrators are generally specialised in a suite of core protocol frameworks for which they have the relevant technical expertise andcommunity support.

24

2nd Global Enterprise Blockchain Benchmarking StudyACTOR TYPES

Other stakeholders
Entities that provide
tangential services andinsights of commercial and/or non-commercial nature

ACTIVITIESDESCRIPTION

Funding

Provide funding and/or facilitate access tofunding (e.g. venture capital, incubators,
strategic investors, etc.)

Research

Collect, analyse, and present data on various
aspects of the ecosystem, including thetechnology itself (e.g. academia, industry
research, analytics platforms, etc.)

Advocacy

Support the development of the ecosystem,and the industry in particular, through a variety
of means including engagement with external
parties (e.g. special interest groups, lobbyingorganisations, etc.)

Regulation

Regulate and supervise activities in theecosystem

Legal

Provide legal opinion and advice to organisations
before, during and after the technology adoption
process (e.g. IP, tax, reporting, etc.)

Miscellaneous

Includes all other activities that, either directly
or indirectly, play a role in the ecosystem (e.g.
industry associations, consortia, data services,
legal and regulatory services, education, training
and certification, etc.)

It should be noted that one entity can take multiple actor roles and engage in several activities.
For instance, survey data indicates that the majority of vendors do not specialise in a single
activity, but instead provide a broader range of services that sometimes go as far as acting as
a network operator for client networks. Similarly, one activity can also be carried out jointly bymultiple distinct entities (e.g. gatekeeping and administration of a blockchain network).

The lack of clarity around roles and positioning ofactors indicates the ecosystem is still maturing
Given the (still) relatively early stage of the industry, the boundaries between different roles
and activities are not always clearly delineated and significant overlap can be observed insome instances. Today, for example, the different roles of a network operator are in most cases
performed by the same entity: in the future, one can imagine a potential unbundling of theseroles across multiple entities that will lead to increased decentralisation in network governance.

Industry development
Entry points
The enterprise blockchain industry is composed of hundreds of entities providing products andservices, which range from small start-ups to large, established corporations. Not all firms haveentered the industry in the same manner, however: this study distinguishes between blockchainnative and non-native entities.
•

Blockchain-native: entities that have been founded to, at least initially, exclusively serve theenterprise blockchain market.

•

Non-native: existing entities that have expanded their business offering to include
blockchain-related products and services.
ºº Expansion: begin offering blockchain-related products and services as a new vertical in
addition to existing business lines.

25Section 2: Introducing the Enterprise Blockchain Ecosystemºº Full pivot: discontinue existing business offerings and undertake a complete pivot
towards exclusively providing enterprise blockchain services.
With a few exceptions, blockchain-native firms tend to be relatively small start-ups, whereas
non-native firms are generally larger-scale incumbents from other industries. An interestingobservation relates to cryptocurrency-focused companies that have started to provide
additional enterprise blockchain services, particularly during periods of stagnating or declining
cryptocurrency prices.
Figure 7: While vendors are primarily blockchain-native, operators tend to come fromexisting backgrounds
Entry points
Share of vendors

Share of network operators and participants

36%

35%

64%
65%

Native   Non-native

Note: based on CCAF survey data.

Differences between actor types can also be observed: while nearly two-thirds of surveyed
vendors are considered blockchain-native, a similar proportion of network operators have been
active in other industries before entering the enterprise blockchain ecosystem (Figure 7). Thisis hardly surprising given that most blockchain networks serve a particular use case or industry
that has already existed before. Nevertheless, more than one third of network operators havespecifically set up a new entity to deliver their value proposition.

26

2nd Global Enterprise Blockchain Benchmarking Study

Industry growth
While it can be difficult to quantify the growth of the enterprise blockchain industry due to a lackof reliable data sources, one can employ proxies to provide an approximate estimate. One suchproxy is the number of full-time equivalent (FTE) staff employed by blockchain firms.11
Figure 8 shows that the number of total FTE employees in the enterprise blockchain industry has
grown substantially since 2016, with vendors experiencing the largest growth rates of all actor
types. However, survey takers also warn that the rapidly increasing demand for skilled blockchain
talent is not met with an adequate growth of supply, leading to growing skilled labour shortage.
Figure 8: The total number of FTE staff active in the blockchain industry has grown
substantially, with vendors recording the highest growth rates of all actor types
Total FTE growth rates
2017 YoY2018 Q1+Q2

184%

165%

103%

62%

Vendors

Network operatorsand participantsNote: based on CCAF survey data. FTE staff not exclusively focusedon blockchain activities have been removed from the calculation.

Surprisingly, vendors have, in aggregate, grown at nearly the same rate in the first two quarters of2018 than for the entire year in 2017. The total number of blockchain-focused FTE staff employedby network operators has also significantly increased during the covered period, which suggeststhat the industry is increasingly moving towards the adoption of actual business networks that are
deployed in production.
A similar pattern can be observed at the firm level: the average blockchain company has grownconsiderably in size since 2016, with entities acting as vendors employing more people (median)and recording the highest growth rates (Figure 9).

11

We only consider FTE staff that are exclusively involved in enterprise blockchain activities in order to remove noise from firms that
also operate in other market segments. Moreover, not all employees of blockchain firms are directly involved in blockchain-related
activities: some employees may be assigned to complementary business areas such as accounting and legal services. In fact, survey
data shows that native blockchain vendors have on average 73% of their employees working exclusively on blockchain activities,
compared to 28% of non-native companies.

27

Section 2: Introducing the Enterprise Blockchain Ecosystem

Figure 9: Both vendor and network operator companies have significantly grown in size
Firm growth
Median FTE staff exclusively engaged in blockchain activities

15
88%
100%

60%
8

8

67%

5

4
3

2016

2018 Q2

2017
Vendors   

Operators

Note: based on CCAF survey data. Only takes into account firms thathave been operating throughout the covered time period.

However, there are staggering differences between firm sizes within the same category: whilesome vendors have fewer than 5 employees dedicated to blockchain services, the largest
organisations have more than two thousand blockchain-focused staff, up from 300 in 2016 and
800 in 2017. Network operators tend to be much smaller in size: the largest entity employed some
70 people at the end of Q2 2018, up from 35 in 2016 and 50 in 2017.

Consortia and ecosystem building
Blockchain networks require collaboration between distinct parties in order to develop their fullpotential. As a result, we can observe an explosion of new initiatives in recent years that attempt
to pool attention and create joint efforts between interested parties to harness the technology
and build network effects.
These initiatives can range from simple partnerships between companies and projects tostrategic investments and the development of large-scale technology and industry consortia(Figure 10). Survey data suggests that partnerships between vendors and projects are the major
type of collaborative activities, although more than 40% of vendors are also engaged in one orseveral consortia.

28

2nd Global Enterprise Blockchain Benchmarking Study

Figure 10: Direct partnerships are the preferred collaboration model for vendors
Collaborative initiatives
Share of vendors

81%

Partnerships

43%

Consortia

41%

Government initiatives

32%

Joint ventures

Strategic investment

24%

Note: based on CCAF survey data.

Another way of looking at the enterprise blockchain ecosystem is to consider it as a collection ofsmaller (sub)ecosystems that have formed around specific platforms, industries, geographies, anduse cases. Most of these initiatives fall into one of the following three categories:•

Technology-focused: veritable ecosystems have developed around (primarily opensource) core protocol frameworks and related technology platforms that comprise vibrantdeveloper communities with hundreds of active contributors. The Hyperledger ecosystemmanaged by the Linux Foundation and R3’s Corda platform appear to be the most popularin terms of members and active contributors at the time of writing. Standard-setting
bodies such as the Ethereum Enterprise Alliance may also fit in this category despite
having no specific mandate to deliver technology solutions.

•

Industry-focused: dozens if not hundreds of industry initiatives have emerged to provide away for relevant industry actors to pool resources in order to explore blockchain-based use
cases and establish common data standards and governance structures. One example ofsuch an initiative is the B3i consortium of the insurance industry.

•

Geography-focused: some initiatives are also focused on a specific geographic region or
country to facilitate the local development and implementation of blockchain networks.
These initiatives can apply at different levels: e.g. regional, national, state, and municipal.
Examples include the Alastria network in Spain, the Blockchain Federal Argentina network,
as well as several government-sponsored initiatives such as the Blockchain Roadmap
launched by the Australian Ministry of Industry, Science and Technology and Ministry for
Trade, Tourism, and Investment12, and the Dubai Blockchain Strategy.13

12

Ministry for Industry, Science and Technology (2019) Advancing Australia’s blockchain industry. Available at: https://www.minister.
industry.gov.au/ministers/karenandrews/media-releases/advancing-australias-blockchain-industry [Last accessed: 17 June 2019].

13

Smart Dubai (2019) The Dubai Blockchain Strategy Available at: https://www.smartdubai.ae/initiatives/blockchain [Last accessed: 21
June 2019].

29

Section 3: State of Adoption

Section 3: State of Adoption
Moving to production
The enterprise blockchain landscape has changed considerably since the publication of the first
Global Blockchain Benchmarking Study in September 2017.14 While over half of surveyed vendors
had production-ready technology platforms two years ago, only 8% of surveyed operators
indicated running a live network: the majority were involved in early testing, proofs-of-concept,
and experimental projects.
The picture looks fundamentally different in 2019: while it is almost impossible to keep trackof all production deployments globally, we estimate that there are hundreds of live blockchain
networks that are being used in production environments across a variety of sectors andindustries. As illustrated by Figure 11, the majority of covered blockchain networks have enteredproduction over the course of 2018 and early 2019.
Figure 11: Live network deployments have taken off in mid-2018
Number of new deployments
15

12
10

10

5
3

Q1

3

2

Q2

5

1

2017

Q3

Q4

Q1

Q2

2018

Q3

Q4

Q1

2019

Q2

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

It is, therefore, appropriate to say that DLT has, to a certain extent, moved away from thehype and experimentation phase, and is slowly entering the production phase. Nevertheless,substantial differences between networks can be observed, which will be covered in theremainder of this section.

14

Hileman, G. and Rauchs, M. (2017) Global Blockchain Benchmarking Study. Cambridge Centre for Alternative Finance. Available at:https://www.jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/global-blockchain/ [Last accessed: 15 July2019].

30

2nd Global Enterprise Blockchain Benchmarking Study

Project lifecycle
One stage at a time
Blockchain networks and projects generally progress through several stages until they are
equipped to run in a production environment. The typical lifecycle of a production network canbe broken down into four main stages: initial exploration, proof-of-concept (PoC), pilot/trial, andproduction.
An empirical analysis of more than 60 live networks suggests that the median time between
launching a PoC and eventually deploying a network in production amounts to 25 months, i.e.
roughly two years (Figure 12). The transition from PoC to an advanced trial stage takes up morethan two-thirds of the time, whereas moving from pilot to production is generally completed inabout half a year (median).
Figure 12: Enterprise blockchain projects typically undergo four main stages
Initial exploration

Conducting research and starting
experimentation with blockchain protocols

3 - 29Testing feasibility and assumption(s) regarding theuse of blockchain technology for a particular use case

Pilot/Trial

18
25

Advanced testing in a production-like environment

3 - 27

In production

Full deployment of a blockchain network
in a production environment

7

MEDIAN TIMELINE(months)

TOTAL RANGE(months)

Proof of concept (PoC)

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

A closer look at the total range reveals major discrepancies between projects: whilesome enterprise blockchain networks took merely three months to complete each of theaforementioned stages, others spent more than two years within each phase. Scale and ambition
plays an important role here: small-scale projects with a limited number of participants and a
relatively simple use case have been capable of launching within six months after initialising a
PoC, whereas larger-scale projects that involve complex use cases with multiple participants andriddled with regulatory and legal obstacles have taken more than four and a half years to go live.

Blockchain projects are a journey requiring a long time frameThis supports the view that enterprise blockchain projects are journeys that involve thetransformation of core market infrastructure, which naturally require a longer time frame andmore patience than simple application development. Moreover, successful network launches do
not immediately translate into commercial benefit: most live networks have yet to see extensive
usage after being deployed in production. It will likely take years before significant impact can beobserved.

31Section 3: State of Adoption

Origination
DLT is often said to be a “team sport” requiring collaboration and cooperation between multiple
parties. However, it can be difficult to launch an initiative that gathers sufficient momentum
among participants without strong leadership support and significant efforts of persuasion,i.e. effective coordination. Our empirical analysis identifies three major origination models:
founder-led, consortium-led, and government-led. Given the aforementioned challenges, it is not
surprising to see that more than 70% of blockchain networks have originated from the initiative ofa single entity (founder-led) that effectively assumes leadership of the project (Figure 13).
Figure 13: The vast majority of live networks originated from the initiative of a single entity

71%

22%

6%

1%

Founder-led

A single entity, often with a dominantmarket position, takes the lead insetting up an initiative

Consortium-led

A collection of entities cooperate to
jointly set up an initiative

ORIGINATION
MODEL

Government-led

A government-related institution
brings together a set of entities tolaunch an initiative

Other

Unclear which party initiated the projectNote: based on CCAF dataset of 67 live enterprise blockchain networks.

However, the boundaries between origination models can be somewhat fluid: as these projects
undergo multiple stages, different models may apply at different stages, with new actors joining.
For instance, some projects are initially founder-led, but as competitors join the initiative, a new
structure may evolve moving to a broader-based consortium and possibly a full equity-based
joint venture. Similarly, a government agency can set the ball rolling by bringing together multiple
national entities that eventually take over to turn the project into a corporate-managed venture.
The benefits and limitations of each origination model are discussed in greater detail in
Section 4.

Project scope
Industries and use cases
Companies and institutions from nearly every sector and industry of the global economy havebeen exploring the potential of blockchain technology in recent years. However, no othersector has come close to the Finance and Insurance sector with regard to the deployment oflive enterprise blockchain networks: nearly half of all covered networks have been launchedby financial institutions (Figure 14).15 The Accommodation and Food Services as well as the
Healthcare and Social Assistance sectors come at a distant second place with 6% of all networks
each.
15

Sectors have been categorised in accordance with the North American Industry Classification System (NAICS). The complete NAICS
code list is available at: https://www.naics.com/search/ [Last accessed: 15 July 2019].

32

2nd Global Enterprise Blockchain Benchmarking Study

Figure 14: Nearly half of live blockchain networks have been launched by the Finance andInsurance sector
Live networks by sectors

3%

3%

3% 3%
Finance and Insurance
Cross-industry
Other
Accommodation and Food Services
Health Care and Social Assistance
Retail Trade
Mining, Quarrying, and Oil and Gas Extraction
Transportation and Warehousing
Arts, Entertainment, and Recreation
Wholesale Trade
Public Administration
Real Estate and Rental and Leasing

4%
4%
4%

43%

6%
6%
7%

9%

Note: based on CCAF dataset of 67 live enterprise blockchain networks. Sectors have been
categorised in accordance with the North American Industry Classification System (NAICS).

These findings are mostly consistent with the conclusions from our 2017 study, which revealed
that the Banking and Finance industries in combination with the Insurance sector were
responsible for 42% of all explored use cases.16 An interesting discrepancy arises with regards tothe public sector: while 13% of explored use cases in 2017 were attributable to the public sector,
only 3% of live blockchain networks are government-related in 2019. This suggests that someprojects may have been discontinued, or are still under development.

Identifying use cases of a given blockchain
network is not always straightforward
Blockchain networks facilitate the secure exchange of information between a set of participantsand enable data verification and integrity checks via a consistent audit trail. The specific use
case of a blockchain network, thus, corresponds to the business area(s) from which the shareddata is generated. Interestingly, it can be surprisingly difficult to identify a particular use case ofa live blockchain network whose mission statement has remained relatively vague and/or broad.
Moreover, blockchain networks can also function as shared data platforms that support a wide
range of use cases.
Data suggests that the majority of live networks have launched with a narrow focus on a specificuse case, although the intention to gradually broaden the scope to include other industry-related
usages is often highlighted in the official roadmap. Figure 15 presents the use cases supportedby the covered production networks: tracking items in large and complex supply chains (e.g.
food, gemstones, shipping containers) emerges as the most prominent use case of live networks,
followed by market infrastructures for trading tokenised assets.

16

Hileman, G. and Rauchs, M. (2017) Global Blockchain Benchmarking Study. Cambridge Centre for Alternative Finance, p. 37.
Available at: https://www.jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/global-blockchain/ [Lastaccessed: 15 July 2019]. It should be noted that a different industry categorisation framework was used in 2017, which neverthelessallows an indirect comparison.

33

Section 3: State of Adoption

Figure 15: Supply chain tracking is the dominant use case for one in every five live networks
Use case breakdown of live networks

4%
4%

6%
19%

6%

7%
15%
9%

10%

Supply chain tracking
UnclearTrading
Certification
Trade finance
Payments
Compliance
Healthcare records
Fund management
Other

15%

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

Key value propositions
Network participants and application providers use enterprise blockchain networks to extract
business value for their operations. Blockchain networks can provide value to enterprises in three
ways: (1) reduce costs by removing avoidable reconciliation steps between company ledgers, (2)generate revenues through the provision of new services enabled by the access to shared data,and (3) create new market models and types uniquely enabled by the shared network that did notpreviously exist.
Data shows that currently, more than two-thirds of live networks are primarily designed toreduce costs for network participants and end users (Figure 16). Interestingly, differences canbe observed between founder-led and consortium-led models: while 84% of the former are
predominantly focused on cost reduction, only 40% of the latter have been set up with theprimary objective to reduce operational costs — 20% have been launched to set the foundation
for a new industry utility that creates new market models.

34

2nd Global Enterprise Blockchain Benchmarking Study

Figure 16: Cost reduction is the predominant objective of current enterprise blockchain
networks

72%

6%

8%

14%

Cost reduction

Improved reconciliation efforts leadto efficiency gains that translate into
lower operational costs(Incremental) revenue generation
New services and business models
emerge as a result of having accessto a single shared source of records

VALUE
PROPOSITION

New market models

A shared (industry) utility enables thedevelopment of entirely new market types
and models that did not previously exist

HybridA combination of cost reduction and revenue
generation objectives

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

This situation is a testament to the early days of the enterprise DLT ecosystem: most production
networks are still in the phase of eliminating reconciliation efforts to streamline the exchange
of information between participants and optimise existing workflows. It is likely that the value
proposition of these networks will evolve over time to gradually move the focus from mere cost
reduction to incremental revenue generation as the systems mature. Eventually, we may see theemergence of entirely new products, services, and business models.

35Section 3: State of Adoption

Network usage
It may come as a surprise to some readers that enterprise blockchain networks can be limited tointernal use: in fact, 5% of production networks are exclusively employed within the boundaries
of a company or conglomerate, with different departments or subsidiaries participating in the
network (Figure 17).17 Nonetheless, the vast majority of networks are designed for shared use
between different, non-affiliated entities in order to cross organisational boundaries.
Figure 17: The majority of live networks are designed for shared use between partners

88%

Shared use

The network is jointly used byseparate, non-affiliated entities

Internal use

5%

7%

Other

The network is used internallywithin a company conglomerate
where participants can be separate
subsidiaries or departments

NETWORK
USAGE

24%

19%

57%

Unclear

The participation model is
not explicitly disclosed

Competitors

Partners

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

A look at the type of participants for shared-use networks reveals interesting insights: in theircurrent form, more than half of production networks have been set up between business
partners, whereas only 19% have launched with the participation of direct competitors. A quarterof covered networks have a combination of competitors and partners that are less straightforward
to categorise given that they occupy different positions in the value chain (downstream andupstream).

In their current form, most networks are set up
between business partners rather than competitors
A typical example of competing entities joining forces to develop a shared industry utility is
the financial institutions that are looking for the secure exchange of relevant information andthe automation of existing workflows. In contrast, networks run between business partners are
generally found in supply chains that involve an existing web of collaborating manufacturers,
suppliers, and distributors.
The types of participants also differ depending on the origination model: in founder-led
networks, a leader entity with a dominant market position primarily onboards business partners(65%). In contrast, consortium-led networks tend to predominantly engage competitors (73%divided between direct and indirect competitors - see “Other”). A common approach forconsortium-led networks run by direct competitors is to establish a joint-venture between
participating entities.

17

There are a variety of reasons for companies to use an internal blockchain-based network: for instance, in some countries, legal andregulatory considerations mandate that data cannot be held by a single entity in one place. Furthermore, increased robustness andresilience with regard to data storage, verification, and sharing can be operational motives.

36

2nd Global Enterprise Blockchain Benchmarking Study

Network design
Market share of protocol frameworks
Businesses and institutions can choose from a wide range of core protocol frameworks as thetechnological foundation of their networks. However, data suggests that only four protocol
frameworks dominate the market: Hyperledger Fabric takes the lion’s share, supported bynearly half of live networks deployed in production, followed by R3’s Corda and Coin Science’s
MultiChain (Figure 18).
Figure 18: Hyperledger Fabric is the dominant protocol framework for deployed enterprisenetworks
Supported protocol frameworks
6%

3%

7%

7%
48%
10%

Hyperledger Fabric
Corda
MultiChain
Hyperledger Suite (non-Fabric)
Other
QuorumStellar15%

Note: based on CCAF dataset of 67 live enterprise blockchain networks.

Survey data based on responses from software vendors that integrate existing protocol
frameworks confirm this picture: the Hyperledger suite (with Fabric as the flagship protocol) is
the most frequently supported protocol framework by integrators and software development
platforms (53%), followed by Corda (35%), MultiChain (32%), and Quorum (26%). This distribution
also indicates that many integrators specialise in a set of protocol frameworks, rather than a single
codebase.

The Hyperledger protocol suite is the most frequently supported
framework set by integrators and software platforms
Network operators and participants usually experiment with multiple protocol frameworks
before choosing a particular platform to build their network on. In fact, survey data shows that
26% of operators have switched protocol frameworks at the PoC stage when conducting several
tests.18 However, more than half of surveyed entities also indicated to continue working with theframework initially chosen.

18

For example the WeTrade PoC was originally developed on an Ethereum fork, but ultimately moved to Hyperledger Fabric. Similarly
the B3i insurance consortium started working on Hyperledger Fabric, but subsequently switched to the Corda platform.

37Section 3: State of Adoption

Figure 19: Vendor maturity is considered the most important protocol framework selection
criteria
Core protocol framework selection criteria
Share of network operators and participants

Use case fit
24%

Privacy & confidentiality
24%

Vendor maturity
52%

Security
20%

Performance & scalability
44%

Unique features
16%

Interoperability &extensibility
16%Open source8%

Cost
factors
12%

Other
8%

Note: based on CCAF survey data.

Network operators and participants choose the right core protocol framework on the basisof a set of selection criteria. As illustrated by Figure 19, the maturity and product readiness ofenterprise blockchain vendors are considered the most important factors in the decision process.
Performance and scalability are also ranked as key criteria by surveyed network operators,
although these are often the result of trade-offs and, thus, difficult to directly compare(see call-out box). The selection criteria ranking largely mirrors the sentiment of ecosystem actors
with regard to the remaining key challenges to broader blockchain adoption (see Appendix III).

Beware the trade-offs
Each network is based on a unique set of architecture and design choices optimised for thedelivery of a specific business objective. Every design configuration is a conscious trade-off
between a variety of properties, with the most common trade-off being the achievement of
performance gains at the expense of “decentralisation”. Some properties may be more desirable
than others in a specific context or environment, but it is important to understand that they arealways achieved at the expense of another property. This makes it difficult to directly compare
the performance and scalability of blockchain networks as they generally choose different tradeoffs that result in distinct characteristics.

38

2nd Global Enterprise Blockchain Benchmarking Study

Decentralisation and distribution of control
Blockchains are tools for distributing control over a shared record system across multiple
participants so that, in theory, no single entity can unilaterally exert full authority over the system.
In practice, however, traditional business environments require a certain level of safeguards andprotection measures in place to ensure that potential issues can be quickly resolved without
severely impacting operations. This notion generally presumes the existence of an entity — orsmall set of entities — vested with certain powers.
The remainder of this section will explore the degree of decentralisation in existing enterpriseblockchain networks by considering both network consensus (automated agreement ontransaction ordering) and social consensus (governance).
a) Network consensus
There are two main actors involved in network consensus:•

Auditors: full nodes that independently verify transactions and the system state19•

Block producers: entities that commit transactions to the global ledger by establishing afixed ordering to avoid double-spending 20

Determining the network resilience of a blockchain system requires evaluating two dimensions:first, which entity operates the nodes (control), and second, where these nodes are hosted(hosting). Figure 20 provides a visual representation of this mental model.
Figure 20: Various options are available for the control and hosting of full nodes
Control
Which entity operates nodes?

Network participant
Direct control over node

Third-party service provider
Operating node(s) on behalfof a network participant

N/A
On-premise
Individual nodes are run at
the premises of the nodeoperators

Multi-cloud environment
Individual nodes can behosted in different cloudenvironments

Single-cloud environment
Individual nodes are
hosted in the same cloudenvironment

Hosting
In what environment are nodes hosted?

Network participants only benefit from the ability to independently verify transactions and thesystem state if they operate a full node themselves (i.e. have full control and access to the node);otherwise they are fully dependent on a third-party service provider to whom the auditing
19

Full nodes are software programs run by network participants that enable them to connect to other network participants in a peer-topeer fashion, i.e. directly exchanging messages between each other. Full nodes are an essential component of any blockchain system
as they provide each network participant with the ability to individually check submitted transactions and records for validity andreject invalid submissions. In essence, a network participant running a full node has the capacity to perform an independent audit of
the entire system state without having to trust a third party — hence, sometimes being referred to as auditors.

20

Block producers are sometimes also referred to as miners, bakers, stakers, or validators. The term “validator” can lead to confusion
as it may suggest that only block producers are validating submitted transactions and records. In practice, full nodes do validate
transactions as to independently reconstruct and verify the latest state of the system. Block producers can - and should - run fullnodes as well so they can be sure of the validity of the transactions they are ordering.

39Section 3: State of Adoptionfunction has been delegated.21 The network can be more resilient against failures and external
attacks when nodes are either hosted on-premise by network participants or in multiple cloudenvironments, although the individual configurations and settings do play an important role as
they can widely differ from one organisation to another.22

It is surprisingly difficult to get reliable data on
the network composition of live networks
It is important to note that limited information is available with regard to the exact network
composition of the covered live networks: few disclose the number and hosting environment offull nodes and block producers. In addition, unclear terminology often leads to confusion, such as
the conflation of “users” with “participants” or “nodes”. For networks where data is available, itturns out that the number of nodes can range from a single node to more than 70, all while having
more than 200 members in specific cases.
It is even more difficult to get reliable data on the number of separate block producers in live
enterprise networks, suggesting that many networks rely on a single block producer to date. It
should be mentioned that this would be in line with an examination of use case specifics, whichhave revealed that disagreements over the ordering of transactions are rarely the case — or evenpossible. This explains the absence of multiple block producers.

Most live networks barely distribute control across participants
and are effectively controlled by a small set of parties
Our findings suggest that the majority of enterprise blockchain networks in production are
currently hosted in a single-cloud environment where nodes are all administered and operated
by a single third-party service provider (platform host) who is also responsible for producing
blocks.23 Project members can then connect to the platform host via a trusted API connection. It
turns out that in 69% of these cases, the platform host is also the technology partner (i.e. software
vendor) of the network.
However, there are also exceptions: some networks do provide members with the option to run
their own nodes (on-premise or in the cloud), although interestingly, most participants choose todelegate their auditing power to a third-party service provider. While this may seem to miss the
purpose of a blockchain, there are valid business reasons for doing so at an initial stage.24b) Social consensus
While a diversified network structure and composition ensures that no single participant cantake control over the transaction ordering process, it is worth recalling from Section 1 that social
consensus can always override network consensus by changing the rules of the system. It istherefore important to take into account the governance of blockchain networks as well whenassessing the degree of decentralisation.

21

This may be an implication of the use case that doesn’t require specific participants to validate transactions themselves.

22

For instance, cloud providers would argue that their services are more secure than self-hosted alternatives. Moreover, a network
is often only as secure as its weakest point, which means that cloud-based node owners would need to trust that other network
participants hosting nodes on-premise have implemented similarly high security standards.

23

It is important to note that administration in this context can refer to different functions: cloud administration (e.g. compute andstorage capacity), blockchain network administration (e.g. onboarding new members, peer management), and/or application
administration (e.g. application function by user). A cloud provider may facilitate the former but not necessarily the latter two.

24

Members may have a lack of technical expertise when it comes to manage complex infrastructure components in-house.
Furthermore, they may not feel comfortable with the idea of operating their own infrastructure at an early stage given that they areused to third-party outsourcing. Managing nodes on-premise can also involve complexities related to security and interoperability
issues that most companies are unfamiliar with.

40

2nd Global Enterprise Blockchain Benchmarking Study

Our empirical analysis shows that more than 80% of live enterprise blockchain networks are
currently governed by a leader entity (Figure 21). This leader entity is responsible for coordinating
protocol changes, permissions management, and onboarding policy. The governance structure
may be different from one project to another, with other participants having various degrees ofdecision-making power.
Figure 21: Four in five live networks are governed by a leading participant entity
Enterprise blockchain network governance
5%

3%

11%

Leader entity
Joint venture
Other
Unclear81%

Note: based on CCAF dataset of 67 live enterprise blockchain networks. For further information
about the difference between social and network consensus, please refer to Figure 1 on page 14.

The leader entity generally takes the lead in setting up the network: in fact, 96% of founder-led
networks are governed by the same entity that launched the initiative. In contrast, networks
that originate from a consortium of organisations tend to be governed more often through joint
ventures (33%), although one consortium member is still leading network governance for morethan half of the covered networks.

41

Section 3: State of Adoption

Case study: We.Trade
Overview
We.Trade is a blockchain network launched by a consortium of international banks to support open
account trade finance for small and medium enterprises (SMEs), initially across Europe.
Project lifecycle
The formal We.Trade project was launched on October 17, 2017, having originally started as the Digital
Trade Chain, a consortium of seven international banks (Deutsche Bank, KBC, Rabobank, Societe Generale,
Natixis, Unicredit, and HSBC) in 2016. The first production transactions were announced on July 3, 2018,
after two more banks (Santander and Nordea) subsequently joined the consortium and joint venture. In
October 2018, 3 banks (UBS, Erste Group, and CaixaBank) from the rival UBS-led BATAVIA consortium
joined, in addition to Eurobank that allowed We.Trade to expand to Greece and take the total number ofbanks to 13.
Project scope
We.Trade is an open account trade finance project directed towards European SMEs: each of the thirteen
participating banks provides access to their SME clients via their commercial banking platforms. The
network enables SMEs to discover trusted trading partners in other countries who have already beenvetted and verified locally by participating banks. Since all steps of the transaction are committed to theblockchain ledger and payment notifications are automated via smart contracts, SMEs can have more
confidence that they will get paid at a pre-agreed time. The We.Trade motto “More Trust More Trade” isa fitting indication of the revenue generation objective of the network: the more trust there is between
SMEs, the more trade will ensue, which will lead to more wealth creation, and, in turn, generate additional
revenues for the participating banks.
Network design and composition
The We.Trade network is built on the Hyperledger Fabric core protocol framework and operated bysoftware and services vendor IBM on behalf of the We.Trade Joint Venture. Initially, it was expected that
individual banks could choose whether to run their nodes on premise or deployed on cloud. In the earlystages of planning, two of the original seven banks were planning to run their nodes on-premises; however,all banks subsequently decided to run their nodes in a cloud environment, with the core infrastructure
running on the IBM Blockchain Platform. The original Digital Trade Chain PoC, led by KBC in 2016, wasbased on Ethereum. Hyperledger Fabric was eventually chosen for the production implementation as aresult of the selection of IBM as the platform developer.
Workflow
Only banks that are party to a transaction have the ability to endorse that transaction. Each bank has its
peer node(s), supported by IBM’s Blockchain Platform and cloud services. The bank nodes are integrated
into each bank’s commercial banking, payments and KYC processes. When a purchase transaction iscommitted by a buying SME, their platform processes the transaction in both bank’s ledgers, which is inturn validated by the selling SME and committed to the ledgers by their bank. All steps of the transaction
are reflected on the ledger, including the optional physical movement of goods (via a Track and Trace
API), and payment notifications, which are automatically triggered by smart contract code, based on
the meeting of predetermined settlement criteria. Buying SMEs are able to request a Bank Payment
Undertaking to give the seller confidence of payment, and selling SMEs are able to request invoicefinancing from their bank — all through the We.Trade platform.
Social consensus and governanceWith each bank having stakeholders for requirements, architecture, security, compliance, and more,design meetings rapidly became very large. This and other considerations such as governance andcommercialisation models led to the formation of We.Trade as a Dublin-based Joint Venture with 12 of the
13 banks as shareholders. Interestingly, Eurobank, the latest member to join the network, was on-boarded
as a licensee of the We.Trade platform rather than as a We.Trade shareholder. The We.Trade network
now has some functions such as marketing, bank sales, business development and product management
centralised within the We.Trade Joint Venture, with day-to-day operations distributed across the member
banks, and an overseeing governance model through the We.Trade Joint Venture and platform licensees.

42

2nd Global Enterprise Blockchain Benchmarking Study

A note on blockchain activities in the public sector
In recent years, central banks and other public-sector institutions (OPSIs), which include local municipalities
and governments, national ministries and agencies, as well as international bodies and multilateralorganisations, have increasingly expressed interest in the potential of blockchain technology. Morerecently, however, it appears that initial enthusiasm has cooled down and made way to the sobering
realisation that the journey to practical implementation takes time and is often riddled with obstacles andchallenges.
Compared to data from the 2017 survey, the number of institutions that are still in the early stagesof exploring the technology and conducting research studies has substantially declined, but has nottranslated into a meaningful increase in PoCs or actual trials. This observation applies equally to central
banks and OPSIs, although findings confirm survey results from the 2017 study about central banks being
more conservative than OPSIs and less “adventurous” regarding experimentation and advanced testing.
Only a small number of projects have been actively advanced and made significant progress over thelast two years, which suggests that the experiments have been largely completed and only the morecommitted and serious efforts have moved ahead.

Figure 22: The focus on explored use cases has slightly shifted since 2017
Explored blockchain use cases
Share of central banks

Share of other public-sector institutions (OPSIs)
56%

Central bank-issued
digital currency (CBDC)

Real-time gross settlement(RTGS) systems

82%

New payment andvalue transfer systems
Regulatorycompliance50%

Other clearing/
settlement systems

22%

Business records
management

Other

25%
14%
19%

Taxation
Publicprocurement

41%

Other

2018   

50%

26%
31%

22%
25%

VotingOwnership records
management

43%

35%

Shared government
infrastructure

38%
36%

Regulatorycompliance31%

Ownership records
management

44%

52%

25%

Personal records
management

50%
55%

Payment
networks

57%

13%

6%

17%

4%
39%

63%

2017

Note: based on CCAF survey data.
A comparison with 2017 survey data reveals that the focus on explored use cases has slightly shifted(Figure 22). For instance, the interest of central banks in using blockchain networks for the issuance andmanagement of central bank-issued digital currency (CBDC) has significantly declined.25

25

Other studies have shown that motivations for developing a CBDC, independent of the underlying technology, may vary acrosscentral banks. However, surveyed central banks from our sample share similar reasons: in particular, assessing the potential impact of
CBDC on financial stability and the growing trend toward a cashless society are mentioned as the key drivers behind the explorationof CBDC. Interestingly, the potential ability of CBDC to preserve central bank seigniorage revenue, to facilitate tax collection and
impede tax evasion, as well as to better enforce capital controls are not considered primary incentives.

43Section 3: State of Adoption

This finding suggests that internal research and initial experiments have shown that alternativetechnologies may be better suited, but also confirms the recent announcement of a number of central
banks to abandon initiated CBDC projects. In contrast, blockchain technology remains a popular
candidate tool for increasing the resilience and robustness of critical payment infrastructure such as RTGS
systems.
Meanwhile, surveyed OPSIs have shifted the focus of their blockchain activities from ownership andbusiness records management to personal records management (e.g. birth and death certificates).
Moreover, blockchain technology is increasingly explored as a potential tool for the development of new
payment and value transfer systems that would increase transparency — and thus facilitate regulatorycompliance for companies and institutions alike by providing an auditable log of verified records.

44

2nd Global Enterprise Blockchain Benchmarking Study

Section 4: Blockchain Strategy andBusiness Models
User motivations
Expected benefits
Since early 2015, the ubiquitous blockchain hype has touted innumerable benefits thatorganisations could expect when adopting blockchain technology. But are there any real driversof corporate and institutional interest in exploring blockchains as a new tool for their operations?
According to survey data, the key motivation is the potential of generating revenues through theprovision of new products and services (Figure 23). The prospect of increased process efficiency
and the associated cost savings also encourage organisations to start exploring blockchains.
Figure 23: The potential of new revenue generation is the key driver of corporate blockchain
strategies
Key drivers of enterprise blockchain strategy
Share of network operators and participants

69%

Delivering new revenue-generating products & services
Improving efficiencies across organisation boundaries

62%

Increasing transparency

62%
55%

Potential cost savings
26%

Improving efficiencies within organisation boundaries
14%

Fear of losing competititve advantage

10%

Enabling trading of illiquid assets through tokenisation
Reducing moral hazards

5%
10%

Other

Note: based on CCAF survey data.

This is in line with the findings from Section 3 that showed how the initial focus of live networks
primarily lies on cost reduction, but will gradually shift towards the provision of new products
and services that promise to generate additional revenues. Furthermore, the data confirms our
initial assessment that blockchain technology is considered a “team sport” that develops its fullpotential through collaboration between multiple parties beyond organisational boundaries.
Interestingly, network operators and participants report that general reluctance to change
established business processes remains the key challenge to broader blockchain adoption (seeAppendix III), indirectly confirming the view that “blockchain” is more of a powerful catalyst thatis driving organisational change than a new technology.

45

Section 4: Blockchain Strategy and Business Models

Finally, it is noteworthy that one in seven respondents indicated to have launched a blockchain
strategy for fear of losing competitive advantage. However, it is unclear whether this refers toa genuine concern over missing the train with regards to a potentially groundbreaking new
innovation, or if it can be interpreted as corporate “innovation theatre” for marketing purposes toinfluence external perceptions.

Internal decision-making
Blockchain strategies and projects can originate from various levels of the corporate hierarchy.
Perhaps unsurprisingly, the majority of surveyed organisations indicate that internal innovation
units have been playing a major part in crafting an organisational blueprint for incorporating
blockchain technology into their operations (Figure 24).
Figure 24: Enterprise blockchain projects primarily originate from internal corporate
innovation units
Enterprise blockchain project initiation
Share of network operators and participants

61%

Corporate innovation unit
46%

C-level executives
20%

Department / Cost centre level
Employee focus group12%

Vendor-initiated

10%

Other

10%

Note: based on CCAF survey data.

Notably, nearly half of respondents also mention that chief executives have been paving the way
for their companies to get involved in blockchain activities, which suggests that the technology
is increasingly considered a priority that benefits from executive buy-in. This confirms findings
from another study observing that 53% of top management executives from companies across allindustries assign a high priority to blockchain activities.26 Interestingly, 10% of respondents pointout that internal blockchain activities were launched at the initiative of external vendors.

26

Deloitte (2019) Deloitte’s 2019 Global Blockchain Survey. Available at: https://media.licdn.com/dms/document/
C4E1FAQEDQciR9s2Jow/feedshare-document-pdf-analyzed/0?e=1563868800&v=beta&t=2LCmCNUYCVEe3aU6pI0Hhn9E563n
Gz2mz98xyFmKIN8 [Last accessed: 22 July 2019].

46

2nd Global Enterprise Blockchain Benchmarking Study

Strategy implementation
Market approaches
After organisations have identified a viable business case that can be appropriately delivered by
way of a blockchain solution, two major market approaches are at their disposal: they can either
take the lead and launch a new network, or join an existing blockchain initiative and network.
Each approach has different advantages and opportunities, but also drawbacks and challenges,
as illustrated by Table 2.
Table 2: Pros and cons of different blockchain market approaches for new entrants
MARKET
APPROACH

POTENTIAL ADVANTAGESPOTENTIAL DRAWBACKS• Speed: faster go-to-market• Fees: on-boarding and/or licensing fees

• Cost-effective: limited to no coordination costs
and development costs
A) JOIN
EXISTING
NETWORK• Reduced complexity: technologicalinfrastructure has already been set up andworkflows have been tested• Business case validation: use case fit has alreadybeen tested and validated, and potential
network effects may already in place• Accelerated learning: lessons learnt by othernetwork members• Influence: retain influence over use case fit,technical architecture and standards, as well as
governance and commercial modelB) CREATENEW
NETWORK• Flexibility: create new system from scratch freefrom technical debt
• Relevance: potential to create a new industryleading utility• Commercial up-side: taking a founders’premium for revenue-generating use cases• Existing terms and conditions: limited influence
over decision-making process, technical standards,
and commercial mode
• Limited flexibility: subject to potential technicaland operational debt originating from existingarchitecture• Reduced commercial opportunity: dependingon the project stage, the commercial benefit forrevenue-generating use cases may potentially beless obvious• Costs: coordination, development, governance,and operations• Time: gathering support as well as internal andexternal buy-in is time-consuming• Lack of critical mass: potentially no network effects- project becomes just another isolated network• Regulatory uncertainty: taking the initiative (andcosts) for regulatory and legal approvals

Choosing the right approach depends on a variety of factors, both internal (e.g. businesscase, resource requirements and availability, acceptable time horizon) and external (e.g.
industry context, presence of competing platform). Moreover, the stage of existing projects
an organisation is pondering to join plays an important role: the earlier the project, the more
flexibility and decision-making power can be granted to the new entrant; however, also the morecosts are likely to be incurred in terms of network development and governance arrangements.

Incentives: allocating costs and benefits
Like other major technology and infrastructure upgrades, the launch and maintenance ofenterprise blockchain networks can involve considerable costs. What are these costs and who has
to bear them?
The cost factors can be grouped into four categories that are closely linked to the project stage:the initiative launch, project development, governance arrangements and operational activities.
Depending on the origination model, the cost levels and allocation can vary significantly: for
instance, costs tend to be mutualised and shared between consortium members, whereas infounder-led networks, the initial investment and project-related expenses are generally borne by
the leader entity (Figure 25).

47

Section 4: Blockchain Strategy and Business Models

Figure 25: Cost factors and allocation are dependent on the network model

Founder-led
Consortium-led

Network model

Cost and incentive factors

1

2

3

4

Initiative launch

Development

GovernanceOperation• Costs exclusively
borne by the leading
entity• Costs borne by theleading entity• Rulebook set by thefounder• Leading entity may
hold intellectual
property (IP)• Option to make alevel-playing field
to create incentives
for adoption, or
compromise onlevel-playing field to
extract early revenue
opportunity• Operating model
defined by thefounder - may needto adjust as others
join• Opportunity todrive early criticalmass if founder has
significant market
share in the target
market• Long gestation
period to agree on
proposition detail,business case(s), andsignoffs – all of which
increase launch cost
• Cost can be sharedacross founding
members• Shared build cost
• Individual member
objectives
on approach,technology, andarchitecture may slow
down the build phase• IP ownership needs
to be agreed• Can take a long timeto agree on the rules,
from commercial
model to operations
and IT governance• Option to avoid
favouring early
adopters andfounding members• Founder may
operate the networkor encourage joint
maintenance byparticipants – impact
on cost allocation• Operation more likely
to be outsourced
to a neutral party,or setting up a
joint venture toown operational
responsibility• Maintenance andoperational costs
generally mutualised
among participants

Project stage and maturity

A major consideration linked to both cost factors and eventual commercial benefits are network
effects: blockchain projects unlock their full potential only if all relevant parties to a trade resideon the same network. Choosing the right incentives in accordance with the network model iscrucial to encourage other organisations to join the initiative. Founder-led networks can create
network effects relatively easily, if the leading entity has a dominant market position that can beleveraged to onboard downstream and upstream members of the value chain. Consortium-led
networks should adopt a suitable commercial model that avoids favouring founding members
and early adopters too much if others are to be encouraged to join.

48

2nd Global Enterprise Blockchain Benchmarking Study

Case study: TradeLens
Announced in January 2018, TradeLens is a blockchain-based network started by Danish logistics andtransport giant Maersk and software and services vendor IBM to transform ship-based supply chains.
Given that Maersk controls some 25% of the world’s container traffic, the TradeLens initiative represents
an example of a founder-led network that uses its significant market share and power to achieve a minimal
viable ecosystem without needing to form a consortium first. Press reports then followed at the end of
2018 indicating resistance from other major ocean carriers to join a network led by their major competitor.
However, in May 2019, MSC and CMA CGM announced they were joining TradeLens, thereby taking the
proportion of container traffic supported by the network to just under 50%. In July 2019, Hapag-Lloyd
and Ocean Network Express — the 5th and 6th largest ocean carriers — also joined the network, further
accelerating TradeLens adoption.
This case study illustrates the challenges of building critical mass for founder-led business models and thetime required to get to the tipping point in multi-party networks where participants are also competitors. It
also shows that there are incentives for organisations to join existing initiatives, even if led and managed bya key competitor, rather than to create their own projects that may fail to reach critical mass.

Vendor relationships
Network operators and participants have several options regarding network development andmaintenance from a technical perspective. While some prefer developing the expertise in-houseand reduce the dependency on third-party vendors, the majority of surveyed entities opt for a
relationship with a third-party software or services vendor: in fact, about 60% indicate that their
PoCs have resulted from a combination of in-house and outsourced developments, with the
exception of the year 2016, where most organisations were experimenting internally with freely
accessible open-source protocol frameworks.
Network operators and participants tend to retain the services of the vendor they initiallycontracted. Survey data shows that 61% of organisations engaged in multiple PoCs and/or othertests and trials chose to continue working with the same vendor, whereas only 17% opted for
a complete switch to another vendor (Figure 26). These findings highlight the importance forvendors to build and maintain good relationships with potential clients from the start as customer
retention appears to be relatively high. One explanation can be found in the specialisation ofcertain vendors on a specific protocol framework (e.g. IBM primarily working with Hyperledger
Fabric, ConsenSys working with Ethereum variants) as well as existing trust in the capacities ofthese vendors who have successfully delivered first projects and PoCs.

49

Section 4: Blockchain Strategy and Business Models

Figure 26: Customer retention appears to be relatively high for blockchain vendors
Switching between vendors
Share of network operators engaged in several PoCs

11%

11%

61%

Retain initial vendor
Fully replace initial vendor(s)Use services of other vendor(s) in addition
Other

17%

Note: based on CCAF survey data.

The relationship between network operators and software vendors is also closely linked to theproject stage: the more advanced the project, the more likely a third-party software vendor
is involved. Survey respondents mention that less than one third of pilots and trials have been
exclusively conducted in-house with no technical assistance or support from external parties.
This is akin to traditional software-based projects where businesses contract external software
vendors.

Internal evaluation of activities
Project discontinuation
The vast majority of blockchain experiments, PoCs, and trials do not pass to the next stage.
While projects launches are generally announced with great fanfare including press releases,
blog posts and news articles, many end up being quietly abandoned with little to no publicacknowledgment. This further fuels the hype by creating an artificial perception that blockchain
technology has been widely adopted.
Survey data from network operators and participants who have discontinued at least one
enterprise blockchain project clearly highlights the primary reason: the application of blockchain
technology to a specific business case failing to realise tangible benefits (Figure 27). This is hardly
surprising given that many indicate to have misidentified suitable use cases in the first place.
Moreover, regulatory barriers and the difficulty of collaboratively developing a business caseacross network participants are often cited when explaining the absence of realised benefits.

50

2nd Global Enterprise Blockchain Benchmarking Study

Figure 27: Failure to realise tangible benefits is cited as the major reason for discontinuing
blockchain projects
Major reasons for discontinuing blockchain projects
Share of network operators and participants62%

No realisation of tangible benefits
38%

Confidentiality and privacy concerns
25%

Unsuitable technology for business case19%

Technical issues
Budget overrun and/or lack of additional funding

12%

Lack of executive buy-in

12%Market competition

6%
31%

Other

Note: based on CCAF survey data.

It appears that a considerable number of projects are shut down before they have had theopportunity to realise their full potential: with many live networks, tangible commercial benefits
are often only observed after the network has been running for a while. This is the result of
business model innovation depending on many yet unknown parameters and circumstances. The
uncertainty of returns on blockchain-related investments is largely acknowledged by industry
actors as a key challenge to broader adoption (see Appendix III).

Some projects are discontinued before tangible benefits have the chance to manifest
Interestingly, more than a third of respondents indicate that concerns over confidentiality andprivacy led to the conclusion of projects, which is in line with comments from surveyed entities
on the difficulty of reconciling key blockchain attributes (e.g. difficult to rewrite history) withregulatory compliance requirements (e.g. GDPR). However, it is likely that the sentiment hasslightly shifted in recent months after an increasing number of national and regional legislators
have issued favourable legislations.27

Overall satisfaction
The majority of projects launched by surveyed network operators and participants are still inthe early stages, waiting to unlock their transformative potential after completing the testing
phase and achieving extensive usage. Nevertheless, survey data suggests that two-thirds oforganisations engaged in blockchain activities are either satisfied or very satisfied with the overall
performance and outcome of their projects (Figure 28).

27

See for instance, Chambre des députés du Grand Duché de Luxembourg (2019) Bill of Law 7363. Available at: https://www.chd.lu/
wps/portal/public/Accueil/TravailALaChambre/Recherche/RoleDesAffaires?action=doDocpaDetails&backto=/wps/portal/public/
Accueil/Actualite&id=7363 [Last accessed: 06 August 2019]; State of Wyoming (2019) House Bill 185. Available at: https://www.
wyoleg.gov/Legislation/2019/HB0185 [Last accessed: 06 August 2019]; State of Nevada (2019) SB 163. Available at: https://www.leg.
state.nv.us/App/NELIS/REL/80th2019/Bill/6234/Overview [Last accessed: 06 August 2019].

51

Section 4: Blockchain Strategy and Business Models

Figure 28: Network operators and participants generally tend to be satisfied with theoutcome of their blockchain projects and activities
Degree of satisfaction regarding the outcome of blockchain activities
Share of network operators and participants

7%

2%

37%

24%

Very satisfied
Satisfied
Too early to assess
NeutralPrefer not to answer

29%

Note: based on CCAF survey data.

This self-assessment may initially seem surprising given the high rate of project failure. However,it may also reflect the valuable lessons learnt from negative outcomes and the growing realisationthat blockchain technology is not a panacea for every enterprise problem, despite being
frequently portrayed as such by the hype. Gaining these insights through self-experimentationand hands-on experience can add exceptional value to the organisation’s overall strategy andavoid malinvestment.

Alternative technologies
Figure 27 suggested that one in four network operators discontinued a blockchain project on
the basis that the technology turned out to be unsuitable for the aimed business case. When
asked whether they were aware of alternative technologies such as cloud computing or traditional
distributed databases that may be better suited to deliver the same business case, only 16%
acknowledged that this was the case (Figure 29).

52

2nd Global Enterprise Blockchain Benchmarking Study

Figure 29: One third of network operators believe that blockchain technology is the best
option to address their business case
Awareness of alternative technologies for delivering the same business case
Share of network operators and participants

14%

16%

Better alternatives do exist
No better alternatives do exist
Still investigating
Unsure
Other

14%

33%
23%

Note: based on CCAF survey data.

One third responded that they do not believe an alternative technology could deliver the same
benefits, demonstrating great confidence in the technology’s effective capabilities. 37% of
respondents are either still investigating alternatives or remain unsure about the existence ofpotential substitutes that would provide greater advantages.

53Section 4: Blockchain Strategy and Business Models

Vendor strategies
Platform openness
Vendors that provide software services face an important strategic decision regarding the degree
to which their platforms are open to third-party developers: the underlying codebases can beeither open-source (i.e. outside developers are free to use or modify the code) or proprietary (i.e.
closed-source and not accessible for outside developers).28 Interestingly, survey data reveals that
half of covered platforms are open-source, whereas the other half are proprietary (Figure 30).29
Figure 30: Half of vendor platforms are open to third-party developers, with the majority
licensed under Apache 2.0
Platform openness

Licensing

Share of vendors

28%

6%

6%

6%
50%

13%
69%

22%

Apache 2.0
GPLv3
MIT License
GPL/LGPL
AGPL

Open-source
Majority closed-source
Fully closed-source

Note: platform openness based on survey data. Licensing breakdown
based on a list of 17 blockchain software platforms.

Either decision has its advantages and downsides from the perspective of a vendor’s businessmodel and monetisation strategy: an open platform favours the emergence of a community andecosystem around the software project, encourages experimentation, and facilitates integration
into legacy systems, but cannot be directly monetised. In contrast, a proprietary offering enables
direct monetisation via licensing fees and protects the company’s IP, but may also deter potential
users wanting to avoid vendor lock-in.
28

In this context, we consider a codebase to be open-source when at least the majority of the code has been open-sourced. Similarly, acodebase is considered proprietary when the majority (or the entirety) of the code is close-sourced.

29

However, it is worth distinguishing between software platforms and execution environments: many live blockchain networks are
based on open-source core protocol frameworks but are operated and maintained in closed-source environments. Similarly, vendors
may license proprietary software development platforms that are based on open-source frameworks.

54

2nd Global Enterprise Blockchain Benchmarking Study

There are a variety of licenses available that determine permissions and rights around the use
and modification of open-source codebases.30 Open enterprise blockchain protocol frameworks
and software platforms are predominantly licensed under the Apache 2.0 license (69% of covered
protocols).

Industry targeting
From a technical perspective, a blockchain platform is a shared recordkeeping system that canbe applied to any type of information. Given the broad applicability of data management andsharing tools, it is unsurprising to see that 41% of surveyed blockchain vendors adopt a crossindustry perspective and position their technology platform as a general-purpose tool applicable
to all industries (Figure 30).
Figure 31: More than half of vendors are targeting specific industries with their platforms
Platform targeting
Share of vendors

23%

41%

General-purpose
Industry-focused but repurposable
Industry-specific36%

Note: based on CCAF survey data.

Nevertheless, the development of some platforms and core protocol frameworks has been
primarily driven by industry requirements, that include the introduction of specialised featuresand functionality to meet the needs of specific business cases or industries. For instance, morethan one in five vendors indicate that their platform has been specifically tailored to a particularindustry, with Banking, Financial Markets, and Insurance being the predominantly targetedindustries.
Furthermore, one third of vendors claim to have developed their platform with a specific industry
in mind while keeping the design sufficiently flexible to cater to the needs of other industries
as well. A good example of this strategic change is R3’s Corda framework, which was initiallycustomised to serve the needs of the financial and banking industries, but has since been
repurposed to accommodate unrelated industries and use cases (e.g. supply chain tracking).
30

The MIT license is known as the most permissive open-source license that allows, for instance, commercial use of the code andonly requires crediting original contributors when redistributing software (which can even become proprietary once modified). The
Apache license is only slightly more restrictive in that it offers users additional protection from patent claims. GPL licenses are more
restrictive, requiring derivative works to be made available on the same terms (“share-alike”/”viral licensing”).

55Section 4: Blockchain Strategy and Business Models

Customer types
Big, established corporations have not only dominated news headlines on enterprise blockchain
initiatives and deployments to date, but also the customer base of blockchain vendors. In fact,surveyed vendors report that, on average, 44% of their total customer base is composed oflarge corporations, compared to only 15% of small and medium enterprises (SMEs) (Figure 32).
The market pressure on large established companies to constantly innovate and look for new
solutions may be one explanation for this discrepancy, a situation that SMEs do not generally faceto the same extent.
Figure 32: Vendors have a diversified customer base dominated by large corporations
Average vendor customer base

44%

15%

ns

Es

tio

e
rg

a
or

10%

t

sti

o

ct

La

In

d

d
ivi

St

2%

s
s
nk rofit
p
nra
nt No
Ce
s

up

tar

6%

a
lb

i

bl

Pu

e
cs

n
ri

io
ut

10%

ls

ua

ns

SM

rp

co

13%

Note: based on CCAF survey data.

An interesting observation is the absence of statistical differences between small, medium-sizeand large-scale vendors, which suggests that vendor size has little impact on the type and natureof customers. This is an encouraging sign for smaller service providers that do not seem to havea disadvantage relative to larger, established competitors when it comes to attracting large
corporations as potential clients.

Blockchain revenue models
Given the relatively early stage of the enterprise blockchain industry, innovative new businessmodels leveraging the unique characteristics of blockchain networks and related services are yet
to emerge. Instead, traditional revenue models found in software development and maintenanceare commonly encountered: Table 3 provides an overview of different revenue models that are
currently applied in the enterprise blockchain industry to monetise services, categorised by theblockchain layers at which they occur.

56

2nd Global Enterprise Blockchain Benchmarking Study

Table 3: Overview of different enterprise blockchain revenue models
LEVEL OFHIERARCHY

Application
layer

REVENUE LEVER

REVENUE TYPEACTOR(S)INVOLVED

Application usage: fees paid by users forusing blockchain-based applications andservices• Access fees

End users, application
providersApplication development• Application build cost

Full stack• Licensing fees

• Licensing cost

Vendors, application
providers

Network operations: initial triage of user
queries/problems (Level 1) and problem/
application problem resolution (Level 2/3)
support of the network service to end users

Regular fees

VariousThird-party complementary services to end
users

Various fee models

Application
providers, third-party
entities, other

Network operations: participantsrunning nodes (auditing) and processing
transactions (consensus services)• Data services (commercial
API)

Network participants

Gatekeeping and governance• Onboarding fees

Network layer

Protocol layer• Transaction fees

• Transaction fees (by volume
or value)
Network operators• IP licensing
Cloud delivery services

Usage fees based oncompute, storage, etc.

Vendors

Network servicing: fully-managed
blockchain network on behalf of participants

Fees based on the number ofnodes and activity levels per
memberNetwork operators,
Vendors

Provision of underlying technologicalbuilding blocks, either through opensource or commercialised enterpriseversions• Commercial enterpriseversion (subscription fee)

Vendors

Blockchain-as-a-service (BaaS): fullymanaged blockchain services (e.g. DLT
software support, node management,
application development)

Various fee models

Vendors

Solutions design: education and training,
ideation, consulting, and implementation

Various fee models

Vendors• Support packages

For instance, vendors provide sophisticated enterprise versions of open-source protocol
frameworks and offer service level agreements and premium support packages to customers. A
popular model is the provision of “Blockchain-as-a-Service” (BaaS), which corresponds to a fullstack blockchain service package ranging from project ideation to full deployment, including amanaged cloud environment and active platform maintenance. This model enables customers to
configure and deploy a full network within minutes, to rapidly prototype and test applications in a
sandboxed environment without needing to dedicate significant time, talent and R&D costs.

Services can be monetised across all blockchain layers
Network operators can monetise access to their networks via onboarding fees and IP licensing,while also potentially charging for platform maintenance, upgrades, and operational support.
Network participants can charge transaction fees for processing transactions and setting up
commercial APIs to external parties to provide network insights and data services, but alsobroadcasting transactions to the network. Application providers can charge end users foraccessing network functionality via a third-party interface.

57

Section 5: Looking Ahead - What does the Future Hold?

Section 5: Looking Ahead What does the Future Hold?
Since the publication of the first benchmarking study in late 2017, the enterprise blockchain
industry has slowly moved beyond the hype cycle and entered the production phase — althoughmany deployed networks in their current form have little in common with blockchain systems
initially envisaged as fully distributed multi-party consensus systems (see Sections 1 and 3).

Planned investment
Nevertheless, half-hearted experiments and short-lived PoCs have given way to more serious
initiatives that involve well-specified implementation roadmaps and benefit from long-term
executive commitment. This development is reflected in the projected budgeting of surveyed
network operators and participants: only 4% indicated to moderately cut the budget allocatedto their blockchain activities, whereas more than half planned to significantly raise the blockchain
budget in the medium term to extend operations (Figure 33). This observation mirrors thesentiment of company executives in a recent Deloitte survey that found that the majority oforganisations were planning to allocate a substantial amount to their blockchain strategy.31
Figure 33: The majority of network operators and participants plan to increase theirblockchain-related budget
Planned investment in blockchain-related activities
Share of network operators and participants
4%

18%

52%

Significant budget increase
Small budget increase
No change in budget
Small budget decrease

26%

Note: based on CCAF survey data.

31

Deloitte (2019) Deloitte’s 2019 Global Blockchain Survey. Available at: https://media.licdn.com/dms/document/
C4E1FAQEDQciR9s2Jow/feedshare-document-pdf-analyzed/0?e=1563868800&v=beta&t=2LCmCNUYCVEe3aU6pI0Hhn9E563n
Gz2mz98xyFmKIN8 [Last accessed: 22 July 2019].

58

2nd Global Enterprise Blockchain Benchmarking Study

Adoption estimates
Despite the prospect of substantial budget increases and planned investment from potential
customers, blockchain vendors have become more cautious and have revised their optimistic
adoption estimates from 2017. In fact, more than half of surveyed entities believed that broader
enterprise blockchain adoption in the private sector will take at least three more years, with 5%even mentioning the possibility that it might never become a mainstream technology (Figure 34).
Perhaps less surprisingly, estimates regarding broader blockchain adoption in the public sector
are more conservative, perhaps based on the premise that the private sector generally precedes
the public sector in terms of the adoption of new technologies.
Figure 34: Blockchain vendors expect broader adoption within the next five years in bothprivate and public sectors
Enterprise blockchain adoption estimates
Share of vendors
Adoption in the private sector

5%

2% 5%

Adoption in the public sector

9%

2%
2%

5%
21%
Less than one year
1-2 years
3-5 years
6-10 years
More than 10 years
Probably neverCannot predict

28%

39%

40%

42%

Note: based on CCAF survey data.

Interestingly, the vendor view is remarkably in line with the estimates of other public-sector
institutions (OPSIs) themselves, with the latter appearing to be even more optimistic regarding
broader adoption of enterprise blockchains in the public sector (Figure 35). In contrast, central
banks live up to their name as conservative and prudent institutions that are reluctant to engage
in short-term technology worshipping: only a third of surveyed central banks believe thatblockchain technology will ever play a larger role in the public sector, although the estimatedtimelines vary significantly from one institution to another.

59Section 5: Looking Ahead - What does the Future Hold?

Figure 35: Public sector estimates of broad blockchain adoption are significantly moreconservative
Public sector enterprise blockchain deployment estimates
Share of central banks

Share of OPSIs

11%

15%
25%

11%

Less than one year
1-2 years
3-5 years
6-10 years
More than 10 years
Probably neverCannot predict

10%
45%

11%

5%

10%

22%

35%

Expected developments
It is worth repeating that despite achieving considerable progress in recent years, the enterpriseblockchain ecosystem and industry remains in the early stages. We list below a set of potential
developments that are likely to occur in the medium to long-term future.
Increased collaboration between competitors
Blockchain technology is a team sport that requires broad participation from diverse actors tobuild network effects and eventually unlock its full potential. While the level of collaboration
appears to be relatively high at present, it is often limited to entities within the same trust
boundary: i.e. existing partners, suppliers, and customers.
We expect to see increasing collaboration across trust boundaries (i.e. between directlycompeting entities) in various forms: survey data suggests that partnerships will remain thepreferred method in the foreseeable future, although more than half of surveyed network
operators and participants have also revealed plans to join an existing consortium or start a new
initiative (Figure 36).
Figure 36: Network operators and participants plan to increase collaborative initiatives byentering more partnerships and joining consortia
Planned collaborative initiatives
Share of network operators and participants
73%

Partnerships
55%

Consortia
32%

Government initiatives
27%

Strategic investment
Joint ventures

18%

Note: based on CCAF survey data.

60

2nd Global Enterprise Blockchain Benchmarking Study

The “blockchain meme” hype will cool off
As the hype slowly fades and the industry matures, it is likely that terminology will be adapted
to reflect the practical realities: a spade will be called a spade. This means that “true” multiparty consensus systems will be semantically distinguished from systems that use component
technologies and/or elements of the blockchain toolkit.
This development will bring long-awaited clarity to the discussion and drastically reduce theunintended misinterpretations and confusion. This will lead to a more realistic appreciation of thetechnological limitations and, to some extent, prevent malinvestment of resources into expensive
projects that are doomed to fail from the start.
Live networks will gradually distribute control
Many live networks are initially highly centralised, but plan to gradually distribute control overdifferent network functions to multiple participants over time, citing “decentralisation” as a longterm objective from the outset. The main reason for this approach is the regulated enterprisesetting in which these networks operate: participating entities generally opt for a conservative
approach in the bootstrapping phase that involves the presence of safeguards, such as a central
coordinator, who can intervene in the event of unforeseen circumstances.
In fact, many operators report that participating entities first need to get used to the newarchitecture and familiarise themselves with abstract concepts (e.g. key management, self-hosted
infrastructure), until they feel sufficiently comfortable with the idea of gradually distributing
control and assuming greater responsibilities. This approach enables network participants andend users to gain a better understanding of a system’s functions and properties while operating
in a safe environment. This results in invaluable experience that can then be used to move
forward until all responsibilities related to both social consensus and network consensus are
sufficiently distributed among participants such that no single entity can unilaterally impose
decisions.
Network of networks will emerge
Given the number of blockchain networks already in production, a logical extension besides
growth in the user base is to leverage the network and infrastructure for other businessapplications that are of value to the same community (e.g. the addition of supply chain financing
applications to an existing supply chain tracking network).
Separate blockchain networks will increasingly be required to connect and interact in order toprovide new services — i.e. form a “network of networks”. Recent examples32 of this development
show a trend to connect networks built on the same blockchain technology (albeit with potentiallydifferent implementations) to facilitate interoperability, but this also points to the subsequent
need for differing technologies to also facilitate interoperability.33
Focus will increasingly shift to the application layer
Since the publication of our first study in 2017, the focus has already shifted from the protocol
layer to the network layer. The industry has consolidated around a relatively small number of core
protocol frameworks (see Section 3) and is now actively deploying hundreds of live blockchain
networks. Once major large-scale networks have been established, a rapidly-increasing number ofbusiness applications will be built on top to leverage network data. It is also reasonable to assume
that applications will increasingly become “ledger-agnostic”, i.e. connect to different enterprisenetworks depending on their requirements, rather than limit themselves to a single network.
32

For instance, see the Memorandum of Understanding signed between the Hyperledger Fabric-based Hong Kong’s eTradeConnect
and Europe’s We.Trade networks to facilitate West/East trade. Similarly, comments have been made on the Corda-based Voltron
network connecting with the Marco Polo trade finance network in the future.

33

Early signs of interoperability efforts already exist (e.g. the mutual memberships of EEA and Hyperledger), but much work remains to
be done to facilitate full interoperability across all major enterprise blockchain technologies.

61

Section 5: Looking Ahead - What does the Future Hold?

Increased convergence between private and public blockchains
While this report has exclusively focused on private, permissioned “enterprise” blockchains,
one should not dismiss public, permissionless blockchains that function on the basis of complex
socio-economic mechanisms. Some overlap between these two types of systems can alreadybe observed: for instance, some enterprise blockchain vendors have developed core protocol
frameworks based on open-source public blockchain protocols (e.g. Quorum is a fork of the
Ethereum codebase, the initial Multichain version was a fork of the Bitcoin codebase).
Figure 37: Nearly half of network operators and participants have already been involved inpublic blockchain activities
Use of public and permissionless blockchains
Share of network operators and participants
2%
22%

29%

29%

 urrently used in a production environment
C
Currently tested
Currently investigated
No ongoing investigation
Prefer not to answer

32%

Note: based on CCAF survey data.

Moreover, an increasing number of network operators and participants are experimenting
with public, permissionless blockchain networks to investigate how enterprise use cases may
benefit from an integration (Figure 37). A small number of established corporations already use
the public Ethereum network as a new market infrastructure for the issuance, recording, andtrading of financial instruments.34 Other companies have been using the Bitcoin blockchain as acensorship-resistant public notary for securely timestamping documents, in order to prove their
existence and integrity.
Similarly, enterprise blockchains may find it useful to periodically anchor the latest system state
into a public blockchain for additional tamper resistance and independent third-party auditing.
It is thus likely that in the foreseeable future, the enterprise blockchain and cryptoasset worlds
will converge to the extent that cross-chain communications and asset transfers will becomecommonplace.

34

See for instance Societe Generale’s bond issuance on Ethereum. Societe General (2019), Societe Generale issued the first coveredbond as a security token on a public blockchain. Available at:https://www.societegenerale.com/en/newsroom/first-covered-bondas-a-security-token-on-a-public-blockchain [Last accessed: 11 July 2019].

62

2nd Global Enterprise Blockchain Benchmarking Study

Rise of asset tokenisation
Tokenisation is already underway for assets ranging from traditional financial instruments to realestate and art. For some assets, tokenisation can fractionalise ownership, which may facilitate alarger investor base and hence potentially increase market liquidity. For other uses, tokenisation
can introduce new economic incentive mechanisms to influence consumer and businessbehaviour on digital platforms. Tokenisation allows logic to be embedded into the security,
facilitating automation of tasks such as regulatory compliance. As noted by industry actors,
tokenisation will drive significant future usages of enterprise blockchain platforms by banks,
exchanges, asset managers and custodians.35

35

See for instance R3 (2019) Digital Asset Working Group Report. Available at: https://www.r3.com/reports/digital-asset-workinggroup-report-july-2019/ [Last accessed: 05 August 2019].

63

Appendix I: Study Sample

Appendix I: Study Sample
Survey data
The Cambridge Centre for Alternative Finance carried out three online surveys between July
2018 and November 2018 via secure web-based questionnaires. Surveys were written in English
and distributed via three main channels: (a) directly to prospective survey participants via email
invitations, (b) through the sharing of public survey links in relevant social networks (e.g. Twitter,
LinkedIn), and (c) with support from blockchain consortia R3 and the Hyperledger project, whowere instrumental in assisting with survey dissemination within their network.

Data was collected from more than 160 entities across 49 countries
During the survey process the research team communicated directly with individual organisations
to explain the study’s objectives. The research team collected data from enterprise blockchain
start-ups, established corporations, central banks and other public-sector institutions (“OPSIs”).
The collected data was encrypted and safely stored, and was only accessible to the authors of thisstudy. All individual, entity-specific data was anonymised and analysed in aggregate.
In total, survey data was collected from more than 160 entities across 49 countries and five world
regions:•

Blockchain Vendors Survey: 60 firms including start-ups and established software vendors
from 25 countries providing blockchain development services to third parties.

•

Blockchain Operators and Users Survey: 56 companies from 22 countries engaged inblockchain activities involving the operation and/or usage of a network.

•

Central Banks and Public Sector Blockchain Survey: 45 institutions from 33 jurisdictions
engaged in blockchain-related activities; composed of 17 central banks and 28 OPSIs
including government agencies (e.g. ministries, municipalities, regulators), multilateral
institutions, and state-owned enterprises.

Figure 38: All three survey samples are dominated by European entities
Geographic distribution of survey samples
Share of network operatorsand participants

Share of vendors

10%

Share of central banks
and OPSIs

11%

27%

13%

18%

30%
13%

3%
10%

Asia-Pacific  

47%

46%

7%
5%

Europe  56%

Latin America and the Carribean  64

Middle East and Africa  

North America

2nd Global Enterprise Blockchain Benchmarking Study

Follow-up phone calls, emails, and in-person interviews with industry participants were used toclarify survey responses if needed, with further quality assurance provided by comparing results
to available public data if feasible. The datasets from online surveys were supplemented withadditional desktop research using commonly applied methodologies. Despite best efforts toensure a geographically diverse distribution, European-based entities dominate all three survey
samples (Figure 38).

Live network data
The research team built an additional dataset of 67 live enterprise blockchain networks that havebeen deployed in production. Data was collected via desktop research between April 2019 andJune 2019 and included primary data sources (official documents and statements from company
websites) as well as secondary data sources (e.g. news articles, blog posts, podcasts). Moreover,
the research team conducted phone-based interviews with representatives from several projects
to cross-check public data sources.
Live networks were identified through a variety of channels that included routinely screeningpress releases and news articles, trawling project and ecosystem directories from variousorganisations, attending industry events and practitioner conferences, and publicly requesting
information via social media and the networks of supporting organisations, among others. The
resulting dataset covers enterprise blockchain networks from all five world regions (Figure 39) anda wide range of distinct industries (see Section 3).
Figure 39: Geographic distribution of covered live blockchain networks
Live enterprise networks

22%

22%

Asia-Pacific
EuropeLatin America and the Carribean
Middle East and Africa
North America
Global

15%
28%
6%
6%

65

Appendix II: Technology Platforms

Appendix II: Technology Platforms
Codebase
Figure 40: The majority of core protocol frameworks are based on existing protocols
Is the codebase substantially based on (or derived from) an existing blockchain core protocol
framework (e.g. Ethereum)?
Origin of core protocol framework
Share of vendors36%
 ubstantially based on existing protocol framework
SLoosely based on existing protocol framework
Completely written from scratch

59%

5%

Note: based on CCAF survey data66

2nd Global Enterprise Blockchain Benchmarking Study

Data Broadcast
Figure 41: Platforms increasingly support a more flexible approach to data broadcasting
How is data broadcast across the network?
Data broadcast
Share of vendors
41%
Global50%
27%Multi-channel

31%
Customisable

32%
19%
2018   

2017

Note: based on CCAF survey data. “Global”: every node receives, validates, and broadcasts all data to eachconnected peer. “Multi-channel”: transaction data is only shared between parties involved in the trade.
“Customisable”: various options are available to network participants, including hybrids.

Network consensus
Scope
Figure 42: While still dominant, reaching consensus at the global network level increasingly
gives way to local consensus
At what level is network consensus reached?
Consensus formation level
Share of vendors
45%
Global56%
18%

Multi-channel

8%
Customisable

36%
36%
2018   

2017

Note: based on CCAF survey data. “Global”: consensus reached over the entire state of the system.
“Local”: consensus reached exclusively between parties involved in the transaction.
“Customisable”: various options available to participants, including hybrids.

67

Appendix II: Technology Platforms

Consensus algorithm
Figure 43: Core protocol frameworks support a variety of consensus algorithms
What consensus algorithm(s) are supported by the core protocol framework?
Supported consensus algorithms
Share of vendors
40%

Practical Byzantine Fault Tolerance (PBFT)
30%

Raft
Paxos

15%

Proof-of-Stake variant

15%

Proof-of-Elapsed-Time (PoET)

15%

Round-Robin scheme

10%

Proof-of-Work (PoW) variant

10%

Node-to-Node (N2N)

5%

Federated Byzantine Agreement (FBA)

5%
55%

Other

Note: based on CCAF survey data

Smart contracts
Figure 44: General-purpose languages (e.g. Java, Solidity) dominate smart contracting
platforms
What smart contract modeling language(s) are natively supported at the base layer?
Supported smart contract modeling language
Share of vendors
Existing general-purpose
language(s)69%

New general-purpose
smart contract language(s)Fixed-purpose language(s)

56%

12%

Note: based on CCAF survey data. “General-purpose” refers to expressive languages that are Turing-complete,
whereas “fixed-purpose” refers to simple script languages that enable a limited range of operations.

68

2nd Global Enterprise Blockchain Benchmarking Study

Privacy and confidentiality
Figure 45: Zero-knowledge proofs remain experimental
Which of the following potentially privacy-enhancing methods are supported by your core
protocol framework?
Privacy enhancing methods
Share of vendors

83%

Restricted transaction visibility
78%

Pseudonymous addresses
72%

Encrypted on-chain data
28%

zk-SNARKS
Confidential transactions

22%

Other zero-knowledge (zk) proofs

22%

Homomorphic encryption

11%

Ring signatures11%

zk-STARKS

11%

Other

17%

Note: based on CCAF survey data. “Transaction visibility” refers to restricting
visibility counterparties involved in the corresponding trades.

69Appendix III: Challenges

Appendix III: Challenges
Operational challenges
Private sector
Table 4: What are the main operational challenges limiting mainstream enterprise blockchain
adoption?
Respondents scored these categories on a 1-5 scale:
1: Not important at all   2: Not important   3: Neutral   4: Somewhat important   5: Very important
Lowest average score

Highest average score
Network operatorsand participants

Vendors
Unknown cost-benefits (uncertain ROI)

4.14

4.02

Knowledge gap: poor understanding of the technology

4.22

4.05

Reluctance of changing established processes

4.18

4.22

Reputational risk associated with "blockchain"

2.60

2.93

Hype associated with unrealistic expectations

3.71

3.67

No compelling use case

2.80

2.93

Legal risks/regulatory uncertainty

3.76

3.75

Difficulty of building business networks

3.59

3.52

Vendor immaturity

3.11

3.80

Lack of standardisation/interoperability

3.39

3.89

Doubts about technological durability

3.11

3.49

Lack of deployed large-scale networks upon which application can be built

3.48

3.70

Lack of user friendliness/ease of use

3.52

3.11

Shortage of skilled blockchain engineers/developers

3.93

3.53

Note: based on CCAF survey data.

70

2nd Global Enterprise Blockchain Benchmarking Study

Public sector
Table 5: What are the major challenges inhibiting broader blockchain adoption in the public
sector?
Respondents scored these categories on a 1-5 scale:
1: Not important at all   2: Not important   3: Neutral   4: Somewhat important   5: Very important
Lowest average score

Highest average score
Central banks

OPSIs

No compelling use case

3.93

2.88

Knowledge gap: poor understanding of the technology

4.00

4.29

Reluctance of changing established processes

3.79

4.08

Hype associated with unrealistic expectations

4.21

3.75

Lack of institutional support/buy-in

3.43

3.63

Public sector inertia

3.07

3.63

Lack of harmonised regulatory framework

3.27

3.50

Vendor immaturity

3.93

3.54

Lack of standardisation/interoperability

4.14

3.46

Doubts about technological durability

3.50

3.29

Shortage of skilled blockchain engineers/developers

3.93

3.83

Note: based on CCAF survey data.

Technical challenges
Table 6: What are the main technical challenges that enterprise blockchain networks currently
face?
Respondents scored these categories on a 1-5 scale:
1: Not important at all   2: Not important   3: Neutral   4: Somewhat important   5: Very important
Lowest average score

Highest average score
Vendors

Security risks

3.20

Scalability issues

3.93

Performance concerns

3.71

Insufficient privacy and confidentiality guarantees

3.09

Immature technology that is not fit-for-purpose

3.00

Interoperatibility issues between DLT systems

3.40

Interoperatibility issues with legacy enterprise systems

3.19

Note: based on CCAF survey data.

71

TAX

$

$

Cambridge Centre for Alternative Finance
10 Trumpington Street
Cambridge CB2 1QA
United Kingdom
Email: ccaf@jbs.cam.ac.uk
Tel: +44 (0)1223 339111