The Dynamics of Governing Enterprise Blockchain Ecosystems

Abstract

The aim of this paper is to analyze how the governance of an enterprise blockchain ecosystem changes as it matures and increases in size. A review of the literature serves to identify five behavioral drivers of governance, which appear to affect the long-term viability of a blockchain ecosystem: access rights, decision rights, incentives, accountability, and conflict resolution. We subsequently report the findings from a comparative case study of how three large blockchain ecosystems implemented various governance mechanisms to exploit and modify the five behavioral drivers over time. Based on twenty-six interviews and approximately 200 h of participant observations, we propose an analytical framework that consists of three distinctive stages in the life cycle of a blockchain ecosystem. Each stage is characterized by an intricate relationship between off-chain and on-chain governance mechanisms. Based on these findings, various recommendations are provided to increase the long-term viability of blockchain ecosystems.

1. Introduction

Growing social unrest, environmental challenges, and geopolitical instability, together with concerns about the effectiveness of traditional institutions, have been increasing (perceptions of) social inequality in many countries. In response to this global trend, emerging technologies such as Blockchain appear to offer more equal, secure, and trustworthy ways of relating to each other, both in personal and business settings (De Filippi et al. 2020). In turn, the rise of blockchain technology requires new types of platforms and business ecosystems to support these new relationships as well as to unlock the full potential of this technology (Elia et al. 2021).

Blockchain ecosystems consist of multiple participants, where no single participant has full or sole ownership. A blockchain ecosystem combines decentralized networks, consensus mechanisms, and security protocols in ways that create auditable and immutable blocks of information (Antal et al. 2021). The lack of expensive intermediators and the guarantee of stakeholders’ inclusiveness together turn blockchain technology into an attractive proposition for the business community (Makridakis and Christodoulou 2019). However, at the same time it raises the problem of how to distribute rewards, roles, and responsibilities among the different stakeholders (Carson et al. 2018).

Blockchain governance is particularly challenging, given that it is highly dynamic and entails both coded and non-coded governance aspects. This governance challenge can be addressed in two perspectives. First, the coded governance aspects can be included in the software code of the protocol and/or application; this is the governance by the chain (Ølnes et al. 2017) or on-chain governance. Second, the governance of the chain (Ølnes et al. 2017), the so-called off-chain governance (van Pelt et al. 2020), consists of all other rules and actions by which a blockchain is governed. The governance of and by the blockchain should be balanced and adaptable to the varying number of participants in the blockchain ecosystem. Otherwise, this blockchain will not be able to offer sustainable solutions that support its current as well as future development.

A good governance structure should allow the blockchain ecosystem to attract and retain new members (van Pelt et al. 2020). Prior work has studied governance structures in terms of so-called behavioral drivers. The most important behavioral drivers are access rights, decision rights, incentives, accountability, and conflict resolution (Beck et al. 2018; van Pelt et al. 2020; Tozzi 2019; Zwitter and Hazenberg 2020). These behavioral drivers require the implementation of both on-chain and off-chain governance mechanisms, which need to be consistent with each other (Lumineau et al. 2021). Institutional pressures, internal and external to the blockchain, have a strong influence on its behavioral drivers and therefore on how blockchain governance structures are designed and evolve (Alston et al. 2021). However, prior studies in this area merely studied these behavioral drivers in a static manner, without considering the growing number of participants in the ecosystem and potential changes in the environment in which the ecosystem operates. Furthermore, the existing literature does not provide insights into which behavioral drivers should be prioritized at different stages of the ecosystem’s lifecycle.

The purpose of this paper is to complement the extant literature by analyzing how the behavioral drivers of the governance structure of a blockchain ecosystem (possibly) adapt as the ecosystem grows and evolves over time. Unlike recent work in blockchain governance dynamics, which focuses on public permissionless blockchains (e.g., Alston et al. 2022; Cowen 2019), we focus on enterprise-driven permissioned blockchains. We conduct a multiple case study (Eisenhardt and Graebner 2007) of three different blockchain ecosystems: Energy Web Foundation, VeChainThor, and Corda Network Foundation. We draw on insights from twenty-six interviews with blockchain developers and ecosystem managers as well as approximately 200 h of participant observations. Our findings distinguish three different stages of blockchain ecosystem maturity, characterized by an increased level of governance decentralization and number of participants. We provide empirical evidence on how the interlock between off-chain and on-chain components changes as the blockchain ecosystem grows and matures, and which behavioral drivers are perceived to be the most important ones at each of the three stages. We conclude by providing recommendations on designing blockchain governance protocols that provide a smooth transition between the three stages.

2. Theoretical Background

Governing a blockchain ecosystem is a difficult task with many challenges. If users and developers are not satisfied with the current governance approach, they may decide to leave the chain and design and operate a side chain (forking), risking the continuity of the existing blockchain (Risius and Spohrer 2017). On-chain governance typically involves voting mechanisms, but the voter engagement is usually low due to technical challenges, lack of personal interest, or perceived lack of transparency (Buterin 2017). In addition, the scalability of the number of transactions poses a challenge (e.g., in terms of the average time it takes for the validator to confirm a transaction), so that the specific consensus mechanism adopted constrains the maximum number of participants and transactions that a blockchain can carry (Dinh et al. 2017).

Finally, blockchain ecosystems need to comply with local laws and rules (Yeung and Galindo 2019). In this respect, tokens or coins are conceived to be a financial security and are therefore subject to financial supervision in most Western countries. Moreover, the European Parliament is in the process of developing the Markets in Crypto-assets Regulation (MiCA 2020), which regulates and standardizes various digital securities. In addition, laws such as the General Data Protection Regulations (GDPR) impose requirements that are hard to reconcile with the immutable nature of blockchains (Hofman et al. 2019).

In the remainder of this section, we explore these governance challenges in terms of five behavioral drivers of blockchain governance and the various technical layers of a blockchain stack.

2.1. Behavioral Drivers of Blockchain Governance

The parties involved in any data transaction need to decide on the way it is executed. Previous studies of blockchain governance (Hacker 2018; Hütten 2019; Yermack 2017; Zachariadis et al. 2019) have identified various behavioral drivers that are critical to the success of the ecosystem: access rights, decision rights, incentive mechanisms, accountability, and conflict resolution.

Access rights (also called accessibility rights) are the rights to read, write, or commit data on the blockchain (Zachariadis et al. 2019). Access to read means being allowed to access the ledger and view its transactions. Access to write means being allowed to generate transactions and send them to the network. Access to commit means being allowed to update the state of the ledger. Depending on how these access rights are granted, one can distinguish between public and private blockchains and between permissioned and permissionless blockchains (Hileman and Rauchs 2018). A public blockchain is one where any participant has the right to read transactions, such as Bitcoin or Ethereum. In private blockchains, the rights to read transactions are restricted to a limited set of participants (Hileman and Rauchs 2018). A permissionless blockchain enables records to be shared by all network users, updated by miners (who can produce a new block) and nodes (who can either validate or produce a new block). Conversely, the write and commit functions in permissioned blockchains are restricted to a limited set of participants (Hileman and Rauchs 2018). Hence, one needs the network’s permission to perform these functions.

Decision rights are the rights to control the blockchain platform regarding who is allowed to provide input for a decision and who has the authority to make decisions about the platform; the way decision rights are distributed thus determine the degree of (de)centralization (Zachariadis et al. 2019). In this respect, on-chain and off-chain decision rights can be distinguished: on-chain decisions are programmable and are included in the algorithm of the blockchain. Off-chain decisions are not included in the software. The latter decision rights often start with the lead developer in the founding stage of a blockchain-based ecosystem and during the growth of the ecosystem they ultimately move to the group of stakeholders that participates in its collaborative governance (Singh and Kim 2019). Hence, the lead developers at the founding stage tend to have a leading role in defining the off-chain decision logic (Parkin 2019; van Pelt et al. 2020; Singh and Kim 2019).

Collective off-chain decision-making processes might slow down the governance of the blockchain (Yeung and Galindo 2019). Consequently, developers often try to promote on-chain over off-chain forms of governance. However, even on-chain decision-making can still be a murky process (Cole et al. 2019), and the lack of transparency may hinder the building of trust in the system (Brous and Janssen 2020). That is, in the on-chain process of voting, various debates and negotiations taking place behind the scenes are often not visible to all stakeholders. For instance, although all discussions in Bitcoin are public, only a limited number of developers have administrator rights and thus they make the ultimate decisions (Jones 2019). As such, the Bitcoin community has repeatedly been incapable of reaching consensus and therefore it experienced many conflicts, which led to the creation of side chains such as Bitcoin Lite and Bitcoin Cash (Parkin 2019).

Incentive mechanisms motivate participation and action in the blockchain. These include economic incentives to join the ecosystem, transaction fees (Beck et al. 2018), and stock-based incentives (Yermack 2017). Ideally, economic incentives help to create and enforce trust among participants (Hütten 2019). Before the first generation of blockchains, a trusted third party was needed to foster trust among parties (Nakamoto 2008). Today, a third party is no longer needed and generating trust has become an inherent design feature, safeguarded in the immutability of blockchain records as well as consensus mechanisms (Schmitz and Leoni 2019).

Accountability is the possibility to be held formally responsible for an action. The lack of formal authority in a decentralized ecosystem can imply a lack of accountability (Hacker 2018). This raises a major challenge in the open but complex infrastructure of blockchain technology: it needs to be highly accessible, but must also enable (commercial) efforts toward innovative value creation; the more participants engage with the blockchain platform, the more challenging it becomes to capture the value (growth) (Schmeiss et al. 2019). The latter is especially problematic for private blockchains that need to become financially sustainable over time; in this type of blockchain ecosystem, a (minimal) hierarchy in which formal authority is clearly defined serves to manage the blockchain’s risk profile and protect the shareholders’ interests (Reijers et al. 2018). As a result, accountability is more straightforward in private blockchains, in which the infrastructure is distributed among a limited and controlled number of entities, than in public blockchains in which accountability tends to clash with the need for maintaining privacy (Zachariadis et al. 2019).

The last behavioral driver is conflict resolution. A common threat to the integrity of a blockchain is forking. A so-called hard fork is a rule (e.g., software) change, in which all nodes in the network must update their software (Parkin 2019): if one group of nodes continues to use the old software while the other nodes use the new software, a permanent split occurs (called a “hard fork”). In a public blockchain, no formally assigned authority has the power to determine the outcome of disputes among the participants (Yeung and Galindo 2019; Zachariadis et al. 2019), other than those that can be resolved by hard forks. However, the exit costs for network members after a fork occurs are large enough so that conflicts are usually resolved off-chain (Alston et al. 2021). Other blockchain types, such as (private) permissioned ones, have similar on-chain mechanisms for conflict resolution; however, these blockchains can also allow for off-chain conflict resolution among members of the ecosystem, such as installing special councils that have fiduciary responsibilities toward seamless blockchain operations (Hedera 2020).

2.2. On-Chain Governance Mechanisms

With regard to its technical structure, a blockchain stack usually consists of three layers: the protocol, network, and application layer (Chen et al. 2021). The protocol layer refers to the level which holds the blockchain blocks and the rules of the blockchain, usually in the form of consensus algorithms. The network layer refers to the level that has access to the protocol or maintains the protocol. This network provides for the security and resilience of the system (Shekhtman and Waisbard 2021). The application layer is the level at which user transactions occur, that is, the interface with the end-user. In this layer, the logic of data transfer is captured in smart contracts (Kapsoulis et al. 2020).

The three layers are interdependent and involve different sets of actors, hardware, software, and governance responsibilities. Through these interdependencies, on-chain governance processes interact with the behavioral drivers captured in Section 2.1. Figure 1 outlines these interactions. In the remainder of this section, we describe various on-chain consensus mechanisms used in blockchain governance: proof of work, proof of stake, and proof of authority.

2.2.1. Proof of Work

The first consensus mechanism, introduced by Bitcoin in 2009, is the so-called Proof of Work (Nakamoto 2008). In a Proof of Work (PoW) protocol, a consensus is created by means of a combination of cryptography and computational power, to ensure the authenticity of data recorded on the blockchain (Nakamoto 2008). Nodes in the network use their computational power for mining new blocks and, to a much lesser extent, validating transactions (Talamo et al. 2020). When the block is found to be valid, the node or miner is eligible to create a new block. This new block must include a hash of the previous block, a timestamp, and the transactions of the resolved block (Akbar et al. 2021). As long as the majority of the CPU power in the network is controlled by nodes that adhere to the protocol rules, they will generate the longest chain in the network and therefore surpass attackers on the network (Nakamoto 2008).

To ensure data authenticity on the blockchain, miners are incentivized to keep the network reliable and secure. The first miner to solve a cryptographic puzzle in this area obtains a reward for creating a block set by the protocol and receives all the transaction fees associated with the transactions included in the block (Akbar et al. 2021). After the mining period, the transaction fees are determined by market dynamics or a consensus on the future approach among the stakeholders (Kim 2019).

PoW is mainly used in public blockchains such as Bitcoin; the nodes validating new blocks remain unidentified in these blockchains. For deviating from the protocol, validators are indirectly punished and bear the computational costs. They receive no rewards for creating a block when the rest of the network does not accept it. Nodes can leave and join the network at any moment and accept the longest PoW chain of transactions developed when the node is not present in the network (Nakamoto 2008).

When nodes in the network do not agree on the software changes proposed (Maddrey 2018), PoW validators have to decide whether to split their computational resources between the forked chain and the original chain or to select another chain to continue the mining activities. Thus, miners have an incentive to allocate resources to what they believe is the correct branch of the fork (i.e., the branch that is most likely to continue to distribute rewards for activities performed). Therefore, they have to decide on which chain to accept, abandoning the other chain (Sompolinsky and Zohar 2015).

2.2.2. Proof of Stake

The Proof of Stake (PoS) is an alternative consensus mechanism, utilized by various blockchains such as Ethereum 2.0, Cardano, and Solana. This consensus mechanism is developed to overcome the shortcomings of PoW, while maintaining the security and reliability of the blockchain in general. The concept behind PoS is that a blockchain is secured by nodes that have a stake or financial interest in the blockchain (Larimer 2013). Compared to the PoW consensus mechanism, it is more energy-efficient because nodes do not require computational power to solve a cryptographic puzzle (Xiong et al. 2022).

In the PoS protocol, nodes own a stake in the network (i.e., tokens) to participate in the consensus process. These tokens are held in a specific staking wallet or are sent to a smart contract, depending on the design characteristics of the blockchain. Based on the stakes the nodes are holding, these nodes select a leader to validate blocks and add any new blocks to the chain (Nguyen et al. 2019). In some PoS protocols, nodes with a significant stake size have a greater probability of adding a block, whereas other protocols prefer the so-called coin-age (Zheng et al. 2017), that is, the time in which a coin has owned the node (Larimer 2013). In the latter case, nodes with higher coin-age are more likely to be selected as block validator.

With the PoS consensus mechanism, validators do not receive rewards for creating a new block. Instead, the nodes (selected as block validators) are incentivized by collecting the transaction fees paid by the entities that broadcast a transaction to the network. This financial incentive is paid to the nodes for block creation and maintaining the network’s reliability and security. Similar to the PoW mechanism, PoS is frequently used in public blockchains and actors remain unidentified. Any deviations from the protocol result in direct punishment because the validator then loses (part of) its stake in the system.

PoS initial hardware costs are much lower than in PoW blockchains. In addition, limited electricity costs arise from participating in the validation process. Therefore, the barrier to entry can be perceived to be significantly lower than in the case of PoW systems. However, the PoS protocol often requires a minimum amount of tokens to be staked before one can join the validation process, which then constitutes a significant entry barrier. However, participants can join a so-called staking pool (Jenks 2018), in which tokens are aggregated and staked on behalf of the entire pool; participants then receive rewards as a percentage of their stake (Muzzy 2020).

In the event of a conflict, validators in a PoS do not have to choose in which chain they continue their validation practice. Validators will receive the same stake in the newly forked chain, allowing them to collect transaction fees in multiple chains simultaneously. Hence, validators have an economic incentive to validate transactions on multiple chains. Moreover, validators, miners, and node operators can vote (with their tokens) on which transactions to include in the next block—also known as the “rule of the wealthy” (de Filippi and Mcmullen 2018).

2.2.3. Proof of Authority

The Proof of Authority (PoA) is a reputation-based consensus mechanism that provides a practical and efficient solution for permissioned blockchains. It restricts block creation to a fixed set of validators, called authority nodes (Liu et al. 2019). The latter go through a Know Your Customer (KYC) procedure, required for financial institutions that need to verify the identity, suitability, and risk awareness of the professional behind the (potential) authority node; they are subsequently selected through a voting process, initiated by a steering committee. The PoA approach appears to allow a permissioned blockchain ecosystem to design its own decision-making processes, both on-chain and off-chain.

In addition to being a verified entity, authority nodes are often required to have a certain stake in the system, similar to PoS. Authority nodes are also expected to contribute significantly to the ecosystem, periodically reviewed by the steering committee. The PoA consensus mechanism is exclusively used in permissioned blockchains, because people need to confirm their real identities to be selected as authority nodes that can create blocks and validate transactions (Liu et al. 2019). Each authority node is expected to behave according to the rules of the network, as any malicious behavior can be witnessed by other participants and is likely to damage the node’s reputation (Joshi 2021).

In the PoA protocol, an authority node is selected randomly, following a randomized rotation scheme. The node can package transactions, create a block on the chain, and broadcast the generated block to the network (Liu et al. 2019). All authority nodes in the network send the received block to other authorities in the network. The block is added to the chain when all authorities in the network have received it (Gorkey et al. 2020).

Whenever authority nodes do not agree on the proposed block, during the process of block acceptance, a smart contract can trigger a formal voting mechanism for the participants. A majority of the votes implies the proposed block is accepted, after which the majority decision is automatically executed (De Angelis et al. 2018; Gorkey et al. 2020). Without a smart contract, the voting will take place off-chain; the outcome will then be included in the blockchain when the technical team has processed the result of the vote. Similar to the PoS mechanism, authority nodes do not receive rewards for creating blocks.

Given that validators in the PoA protocol are identified entities, any traced misbehavior can be used as evidence against a validator, based on cryptographical proof (Graf et al. 2020). Validators are required to obtain the permission of a governing board, such as a foundation board, to join as an authority node (Gorkey et al. 2020; VeChain Foundation 2019). For any conflict not resolved on-chain, a governance mechanism needs to be in place to resolve conflicts off-chain. This is usually carried out in the form of a governance board (Muzzy 2020).

2.2.4. Summary of Main Programmable Consensus Mechanisms

Table 1. Key characteristics of the three most common consensus mechanisms in terms of their behavioral drivers.

Drivers	Proof of Work	Proof of Stake	Proof of Authority
Incentive	Block reward + transaction fees	Transaction fees	Transaction fees
Accountability	Node operators are not liable; therefore, no one can be held accountable for individual action.	Node operators are not liable; therefore, no one can be held accountable for individual action.	The majority of the node operators are known and can be held accountable for the actions on the blockchain; all participants are known and can be held (contractually) liable for their actions
Accessibility	Initial hardware requirement	Minimum collateral deposit	KYC requirement and collateral deposit
Conflict resolution	Every transaction stored in a block is linked/hashed to a previous transaction; alteration of the protocol is unlikely	Every transaction stored in a block is linked/hashed to a previous transaction; alterations of protocol are unlikely	All changes are voted upon through an on-chain voting mechanism
Decision rights	On-chain voting on strategic and operational affairs; structured off-chain discussion process, topics mainly raised by the core team	On-chain voting regarding strategic and operational affairs; structured off-chain discussion process on topics mainly raised by the core team	Limited voting on-chain on strategic topics by the ecosystem members and off-chain decision-making by a core team of the blockchain

outlines the main characteristics of the three consensus mechanisms in terms of the behavioral drivers (described in Section 2.1). The overview of these mechanisms thus far demonstrates that blockchain ecosystems have been experimenting with various (consensus-like) governance formulas, also because the technology continues to evolve. However, the existing literature does not provide clear guidance on which governance mechanism can be best adopted by a specific blockchain. The remainder of this paper serves to develop an overarching logic and framework in this area.

3. Methods

We draw on grounded theory-building (Eisenhardt 1989; Glaser and Strauss 1967) to obtain insights into the governance of blockchain ecosystems. This approach seeks to provide “tentative answers to novel questions of how and why … suggesting new connections among phenomena” (Edmondson and McManus 2007, p. 1158). We apply grounded theory-building to a comparative case study of three blockchain ecosystems: the Energy Web Foundation (EWF), VeChainThor (VCT), and Corda Network Foundation (CNF). Our unit level of analysis is the blockchain ecosystem. In this respect, the comparative case method serves to create “better grounded, more accurate, and more generalizable” theory (Eisenhardt and Graebner 2007, p. 27) than a single case approach.

3.1. Case Selection

We followed a theoretical sampling strategy to enhance the internal as well as external validity of our findings. We searched for blockchain ecosystems that are sufficiently mature and experienced in developing and adapting their governance structures over time, so that we could observe their dynamics from birth until stabilization. Moreover, the three selected ecosystems have extensive experience in building applications on top of their blockchain protocols. This experience is required to ensure that the governance bodies of these blockchains have extensively interacted with a large number of stakeholders in their ecosystem over its lifetime. Likewise, we ensured that all cases have a heterogeneous pool of network members, namely entrepreneurs, consumers, traders, developers, industry bodies, large corporations, and external investors. This social diversity is relevant to be able to observe potential frictions between different types of stakeholders. To facilitate the data collection and validation of the findings, another selection criterion was that the blockchain must be transparent in its reporting via white papers, financial reports, and GitHub communities.

An additional criterion was that the selected ecosystems would need to operate in different geographical settings and industrial sectors, and have developed distinct governance structures. These differences are instrumental in enriching the comparison across cases and fostering the generalizability of our findings. The three cases selected arose from initiatives founded in Europe, Asia, and the United States. The three sectors are energy, logistics, and finance. The richness in the governance structures is further described in Section 4 and summarized in

Table 2. Comparison of how the five behavioral drivers are operationalized across the three cases.

Behavioral Driver	EWF	VCT	CNF
Accessibility	All current and new validators are vetted by the board council of the foundation. Utility nodes or applications are accessible to every member.	Validators are split in several levels according to the vetting mechanisms established by the council, and the token holding requirements. Utility nodes or applications are accessible to every member.	Only accessible to foundation members. Each business network has one seat in the foundation and has the power to create its own admission rules.
Decision rights	The foundation has full decision power over the protocol consensus mechanisms. The infrastructure is designed and maintained in a joint effort between the validator group and the foundation’s operations team.	The foundation has full decision power over the protocol and network layers. Participants can submit requests to the board for approval, and voting can be followed online.	The foundation has a rotating election process allowing members to vote on the composition of the board. Board has full power over protocol and network layers. Participants can propose changes to be voted on by the board.
Incentives	Non-profit foundation, financed by an initial token offering. Validators receive rewards for each transaction processed. Each application built on top has its own reward mechanism.	Non-profit foundation, financed by an initial token offering. Shifted to a dual token system (VET/VTHO) to reward long-term holding of the token and reduce volatility.	Non-profit foundation founded by members of R3 corporation. Tokens are not mandatory. Instead, applications usually follow a software-as-a-service business model.
Accountability	Validators are held accountable for problems related to the protocol and network layers. The utility provider is accountable for problems related to the application layer.	Validators are held accountable for problems related to the protocol and network layers, but without a formal contractual relationship in place. The utility provider is accountable for problems related to the application layer.	Notaries are responsible for validating transactions and avoiding double counting, but the foundation is held legally accountable for any mistakes made.
Conflict resolution	The board controls all activities related to protocol and infrastructure. Validators are consulted via emails or phone calls to try to reach consensus on proposals. Each application has full freedom to operate.	An elected steering board manages all activities related to the protocol and network layers, including any conflicts which may arise.	Conflicts are addressed by the board or have a contractual base for action.

.

EWF is a non-profit organization founded in Switzerland in 2017. Its ambition is to be the software link between people’s personally owned utilities (e.g., solar panels) and established utilities (e.g., regional or national providers of electricity and gas). Its mission is to promote and develop new technologies and applications, especially in the form of new open and decentralized software architectures for the energy sector (Energy Web 2022) and to accelerate the global transition to a low-carbon future (Energy Web Foundation 2022).

VCT is a non-profit entity established in Singapore in 2017, two years after this initial project started. VCT’s mission is to provide a public blockchain solution that hosts large-scale commercial decentralized applications. VCT’s blockchain solution has initially targeted the traceability of goods in the supply chain by using smart chips, QR codes, or Radio Frequency Identification (RFID) tags. These devices broadcast vital information via the blockchain network, which can be accessed in real-time by authorized stakeholders in the supply chain.

CNF is a non-profit organization established in 2018 in New York by the for-profit enterprise R3. CNF’s blockchain applications focus on highly regulated industries, such as banking. The long-term vision of CNF is that the blockchain network is governed transparently, with a fair and representative structure that provides a long-term, stable operating environment for its members (Doychev 2019). These members themselves are all individual, stand-alone entities and CNF therefore has fewer community-building activities than various other blockchain initiatives.

3.2. Data Collection

Regarding these three blockchain ecosystems, we conducted twenty-six (26) semi-structured interviews with various core team members and other stakeholders, collected a large volume of publicly available documents, and also engaged in around 200 h of participant observations. We chose a semi-structured interview format to ensure that we covered all the topics described in Section 2 and at the same time provide interviewees with enough freedom to deepen the aspects they considered the most interesting. We interviewed several blockchain ecosystem members who hold a managerial position; in addition, we interviewed various other staff members (e.g., business developers) and stakeholders (e.g., members of advisory boards and industry bodies). Appendix A provides an overview of all people interviewed.

We prepared an interview protocol which was divided into three different parts: the first part involves questions about each of the behavioral drivers listed in Section 2.1; the second part addresses how the blockchain stack works at the technical level (incl. the level of decentralization), based on Section 2.2; and the final set of questions addresses the maturation process of the blockchain and how the ecosystem has evolved since its foundation. Appendix B contains a sample of the interview questions used. We used our first round of interviews to test the protocol, which was refined in the second round.

All interviews were recorded and transcribed verbatim, after receiving consent from our interviewees. Interviews lasted on average an hour and were conducted in the period from 2020 to 2022, in three distinct phases. The purpose of the first round of interviews was to understand high-level differences across the organizational structures of the blockchains. The second round of interviews served to better understand the observed differences and the behavioral drivers of each ecosystem. The third round was used to validate our preliminary findings and discuss potential ways of improving the current governance structure of each blockchain ecosystem.

The participant-observations were also conducted in 2020 to 2022, with the purpose of obtaining a better understanding of the context in which blockchain communities develop (Kawulich 2005) as well as validating our findings. These participant-observational data can be divided into three categories: four workshops with blockchain advisory boards in which the main risks and challenges in the governance of blockchain ecosystems were discussed; three governance review sessions for several Calls for Proposals from the European Union, to stimulate the development of the European blockchain domain; and monthly meetings with members of the core team of each blockchain studied. This resulted in around 200 h of audio-recorded data and/or written notes (by the lead author).

3.3. Data Analysis

To analyze the interview, documentary, and participant-observation data, we used a combination of inductive and deductive coding. The coding started inductively, to ensure we were “giving voice to the data” (Skjott Linneberg and Korsgaard 2019). This first coding cycle thus focused on descriptive and exploratory coding. Subsequently, the second coding cycle drew on deductive coding, so-called pattern coding (Saldaña 2021), by matching the codes from the first round with the five behavioral drivers and consensus mechanisms described in Section 2. This hybrid coding approach provides results that are theoretically relevant but also stay close to the data. The software application MAXQDA was used to code the data in a consistent and structured manner. Coding was performed iteratively across the documentary, interview, and workshop (i.e., group session) data. Data coding was performed independently by the first author and one of the coauthors.

4. Findings: Three Stages in the Governance of a Blockchain Ecosystem

Our data analysis resulted in mapping three different stages in how a blockchain ecosystem is structured and governed. Each stage involves a distinct set of challenges and strategies. Before moving from one stage to the next, each ecosystem apparently needed to meet a few preconditions to pass the gate to the next stage. Moreover, the relative importance of each of the five behavioral drivers appears to change across stages. Likewise, each stage presents a different balance between off-chain and on-chain governance aspects. Overall, as the three blockchain ecosystems evolve over time, a progressive trend towards decentralization is observed. In addition, when the number of stakeholders joining the network increases over time, the on-chain governance dimension becomes more prevalent. In the remainder of this section, we describe these findings in more detail.

4.1. Stage 1: Developing the Initial Idea and Creating a Consortium

The first stage in developing a blockchain ecosystem consists of all the activities before the blockchain is actually booted up and functional. The initiating team typically consists of several innovators that believe in the benefits of the technology and have substantial financial resources. For example, interviewee 1 said: “Initially, they just said, we think we need to do something with blockchain. Let’s put in some money on the table so that we are all involved and let’s go ahead and there was no clear strategy and no clear governance.” These initial team members also believe that a collaborative attitude is necessary to increase the chance of success.

Moreover, our interviewees emphasized that, while a decentralized system is desired, access rights are often limited to ensure reliability, security, and trust at this early stage: “And so how do we kind of thread the needle between sticking to the principles of we want, you know, a decent decentralized network and we want participation from many different companies, but we also don’t want to just let anybody in because we need to make sure that you’re reliable” (interviewee 7). The first stage focuses on defining the mission and creating a proof of concept of the future chain: “when we started, we […] create something that we call a memorandum of understanding, a very light legal document that has the initial rules of engagement” (Interviewee 17).

To raise broad awareness about the project and acquire the required financial resources, the venture team also writes a white paper that is made publicly available. This white paper usually contains sections devoted to governance and the business model. Importantly, this white paper is not a fixed document, but can be revised in response to the feedback received from the community. In fact, the EWF and VCT white papers are currently in their second version.

In the first stage, the most important behavioral driver appears to be accessibility, that is, making the envisioned blockchain ecosystem accessible for a (relatively small) group of participants. According to one interviewee, it is advisable “not to put a thing in code until they have […] a minimum viable ecosystem” (Interview 14). This minimum viable ecosystem entails a collaboration agreement between a relatively small number of consortium participants (e.g., 3 to 5), who are willing to invest their resources and make the initial ecosystem viable. Despite the intention to open the future blockchain to many other stakeholders and possibly even make some of the tokens publicly tradable, the membership of the initial consortium is quite selective in stage 1. These founding members can also be required to each supply tens of even hundreds of thousands of dollars, before the blockchain becomes operational—as interviewees 9 and 14 observed.

This selective membership as anchors of the envisioned blockchain provides a key incentive for joining the ecosystem. As one interviewee explains, “if [a logistics company is] setting up a platform, it is the leader, so it can bring others into the system, […], its customers, other logistics companies” (interviewee 10). The long-term objective is to create large-enough network effects, so that it becomes very difficult to switch to a different blockchain once a substantial number of stakeholders have committed to the ecosystem. The contributions and risks taken by the founding members are rewarded in the form of being able to control the governance of the ecosystem as well as financial incentives such as the ownership of a large portion of tokens in the blockchain. Once the governing board has been established, its members discuss and agree on matters such as the power structure, accountability, and exit rights.

Once the board structure and the off-chain governance rules (i.e., a formal agreement about how to create and change on-chain rules) have been set, the technology is discussed and fleshed out. The selected technological solutions need to take into account a variety of environmental factors such as intellectual property, antitrust rules, and data protection rules, but must also address cybersecurity concerns. At this point, the ecosystem brings in software developers, who will become a critical stakeholder.

Overall, to move to the next stage, three different preconditions need to be fulfilled. First, the founding members have to agree upon the initial governance rules and formalize them in a white paper. Second, founding members need to provide sufficient financial resources to ensure the viability of the blockchain in the short term. Third, a proof of concept must be developed and made available.

4.2. Stage 2: Translating the Proof of Concept into the Technical Infrastructure

In stage 2, the main focus is on creating and testing the operational blockchain, beyond a simple proof of concept (PoC). Due to the testing nature of this stage, the blockchain is not yet open to the public; access is restricted to the founding members of the ecosystem and other key contributors. Because no third-party applications can be developed, the infrastructure work focuses on the protocol and the network layers, which need to operate according to the rules agreed upon in stage 1. In stage 2, the most important behavioral drivers appear to be accountability and conflict resolution.

We also observed a progressive shift from off-chain to on-chain governance in stage 2: “One of the reasons why you see a lot of the parties not moving from PoC to production, is because they realize they can’t do it alone (…). They see the value once they control that thing. But yeah, if you control everything yourself, you don’t need a blockchain” (interviewee 3). The main challenge here is to design algorithms that can mimic, as closely as possible, the agreed-upon off-chain governance rules. Given the closed nature of the ecosystem in this stage, on-chain consensus mechanisms designed for open permissionless blockchains (such as PoW or PoS) are not yet useful.

Hence, the blockchain ecosystem at this stage tends to build upon consensus mechanisms such as PoA, restricting the creation of blocks to a set of validators whose identities are known; for example, interviewee 7 emphasized that contributors need to be reliable, having “the technical capability to securely run this node; that you are, you know, a reputable organization that is engaging in legitimate business activities.” Although this limits the level of decentralization in the network, many interviewees observed that benefits—such as increased security, regulatory transparency, and increased capacity—outweigh the costs. For instance, both EWF and VCT developed their core protocol based on open-source PoA algorithms. CNF uses a proprietary protocol with a more complex consensus mechanism, involving two types of consensus: validity consensus, which ensures that all required signatures for the transaction are present and lead up to the proposed transaction; and uniqueness consensus, which prevents the accidental duplication of transactions. While all parties in the CNF network can participate in the validity consensus mechanism, only specific notaries (appointed by parent company R3) can participate in the uniqueness consensus mechanism. This dual validation system was designed to increase the security of transactions.

In the EWF and VCT blockchains, validators are also legally accountable. In cases where board members detect behavior among validators or notaries which undermines the security, integrity, or availability of the blockchain, they maintain the right to remove them as validators or node operators from the chain. To reward this accountability, validators in both EWF and VCT obtain a share of the transaction fees per created block, plus a predetermined block reward; in addition, they can manage the number of tokens in circulation. In CNF, only notaries are legally accountable; they receive no reward, given that they are employees of the parent company managing the blockchain. Interviewee 3 reflected on the topic of accountability and decision rights as follows: “The discussions around that, it’s very much tech driven [...]. You may find in a tech governance document a description or a nice module how a new party can be given governance rights as a typical administrator. […] And then ultimately, if you give them enough rights, this new party could be able to kick the old administrator out. The question is who ultimately decides […] And that’s not a technological question, but a classic governance layer who decides what is a qualified majority and where 100% consent is required for particular subjects.”

At the end of stage 2, the blockchain needs to be ready to accommodate new stakeholders that will build applications on top of the existing network layer. To be successful in this transition, three preconditions need to be met. First, an incentive structure has to be in place to attract new members to the ecosystem, while providing profit for the founding members. Second, the economic rules of the blockchain have to be clearly defined. Third, the governance board of the blockchain needs to be restructured to provide new members with some decision-making power, while founding members keep a preferential position in the growing network.

4.3. Stage 3: Opening the Blockchain to External Partners

Once the initial system has been thoroughly tested and the members are satisfied with the existing governance rules, the blockchain may evolve to stage 3, which consists of opening the blockchain for applications to be developed. In this stage, the blockchain ecosystem demonstrates its utility by expanding its value sharing protocol. The objective of this expansion is to extend the range of applications offered on the network. These applications, which will ensure the financial viability of the ecosystem, have to be built on top of the protocol and network layers defined in stage 2. In stage 3, any remaining roadblocks in the blockchain design must be lifted in order to grant more access to other participants. For example, interviewee 4 recalls: “So it came from realizing that, in order to be successful, the blockchain had to comply with a certain number of minimum requirements that the existing technology did not necessarily have for various reasons. By collecting feedback from customer […], we decided to rewrite the blockchain strongly inspired by an existing open source blockchain called Ethereum.”

The dominant behavioral driver within stage 3 is incentive creation, needed to motivate participation and action of application builders. One of the interviewees, for example, observed: “But still, they [the application builders] need to see the advantage of joining your network and to change or adjust their current system to connect with a blockchain system to also gain those advantages” (interviewee 25). The implementation of incentives varies greatly across the three ecosystems. In some cases, incentives for application developers are provided by creating a token economy. Tokens are digital crypto assets that participants in the blockchain can exchange; the equivalent value in fiat currency of these tokens may fluctuate. Typically, as a blockchain ecosystem grows in users and economic activity, the value of its tokens also increases due to the result of positive network effects.

For instance, EWF has generated approximately 58 million tokens, a number that remains fixed. From this total volume, only 30 million tokens are in circulation and are tradable in several public exchanges; the rest belong to the founding organizations and their community fund. The assumption here is that the more frequently these 30 million tokens are used for transactions, the more the demand for them will increase and consequently also the token price. This process generates value for both the application developers and the founding members. At the same time, it limits volatility in the real value of the token: “The value of the token is important because technically it is their business model. And they still sit on quite a lot of tokens [...]. And they have the vision that in the future, they’ll implement a certain structure which will reduce the supply of tokens, to drive up value.” (interviewee 8).

To reduce the deleterious effect of market volatility, VCT uses a completely different economic system, consisting of two different tokens, VET and VTHO. VET tokens grant access to governance processes and rewards; they are traded in exchanges. VTHO tokens are needed to perform any transactions on the blockchain and represent the energy and cost of conducting those transactions. VTHOs are awarded for holding VET for a long enough time.

In CNF, however, the use of tokens is optional and thus not a necessity. Tokens represent an agreement between an issuer and a holder, rather than a digital currency as in many other blockchains. Every business network in CNF is free to create its own token, one that is considered appropriate for its business case and has its own meaning. As a result, somebody that is not part of that business network (within the broader CNF blockchain) cannot hold or buy these tokens. This lack of on-chain incentives is compensated for by an off-chain opportunity: each legal entity in CNF is offered a seat in the board, which allows them to vote on both mandatory and advisory governance topics.

The distribution of tokens and granting access to the chain to new members and developers imply progressive decentralization of the blockchain. Thus, once the blockchain reaches stage 3, it can no longer be closed but needs to become an (open) permissioned chain, where all users can read all the transactions, although only some members have the right to write and commit. The consortium needs to decide how to materialize this, while also protecting the original mission of the ecosystem as well as the interests of its founding members. This decentralization may lead to changes in the on-chain consensus protocol. In particular, more than half of the voting rights in VCT are currently assigned to nodes, which must make significant investments in tokens and must hold on to that investment for a long period of time, using PoS. Therefore, the reward mechanism is tightly connected to the authority to make decisions.

Once the application layer has been set up, the blockchain ecosystem could in principle run itself, without any supervision. However, our interview and other data suggest that an off-chain governance structure is still useful to further guide the development of the blockchain ecosystem. For example, one interviewee made the following observation: “In theory, the foundation could have just gone away, and we say OK great: it’s up to you now validator community, you know, take it and run, and you don’t need us anymore. The general feedback we got was that there’s still a valuable role for us as the foundation to play in terms of continuing to be a steward of the technology” (Interview 7).

4.4. Comparison of Behavioral Drivers across the Three Cases

In Section 4.1, Section 4.2 and Section 4.3, we have explored how on-chain and off-chain governance mechanisms operate and evolve when the blockchain ecosystem moves from an idea to an economically sustainable platform. In general, we observe a common pattern where on-chain governance becomes more prominent over time, as new stakeholders join the ecosystem. In the first stage, the focus is on creating a set of off-chain rules shared by all founding members. In the second stage, these rules are translated into code at the protocol and network layers, which may require several iterations until everyone agrees with them. In the third stage, the on-chain governance is expanded and built on top of the protocol layer. While the challenges that blockchain ecosystem developers face are common, the solutions observed in the three cases differ substantially, which suggests that there is no one-size-fits-all approach. Table 2 presents a summary of how each of the three blockchains has solved various challenges in terms of the five behavioral drivers. Notably, this table outlines the state of the governance approach of each blockchain as it is today (cf. after completing stage 3).

5. Discussion and Conclusions

Blockchain ecosystems are dynamic environments subject to institutional (internal and external) pressures, which make them evolve over time (Alston et al. 2022). In the case of permissionless blockchains, previous work identified four major drivers of change: the structure of the protocol, the organization of the network of stakeholders, the competition across (cryptocurrency) platforms, and the existing legal and regulatory landscape (Alston et al. 2021). In this paper, we focus on enterprise-driven permissioned blockchains. Our evidence suggests that in the case of permissioned blockchains, the main challenge is to generate enough legitimacy to attract, and retain, a large-enough number of participants and application developers to the ecosystem, so that all members can benefit from network effects.

In line with previous work on corporate blockchain governance (Beck et al. 2018; van Pelt et al. 2020; Tozzi 2019; Zwitter and Hazenberg 2020), this paper focuses on the behavioral drivers of governance. However, these studies have not explored how the various behavioral drivers, and the relative weight of each of them, change over time. Our findings suggest that in the early stages, accessibility tends to be the most important driver. As the number of stakeholders grows and the ecosystem reaches stage 2, accountability and conflict resolution become more relevant. Incentives become the most relevant driver when the ecosystem reaches stage 3, given that it is then required to attract external application developers.

Building on the research agenda proposed by Lumineau et al. (2021), who theorize about how traditional (off-chain) and blockchain (on-chain) governance mechanisms complement and/or substitute each other, we provide empirical evidence on how the interlock between off-chain and on-chain components may evolve as the blockchain ecosystem grows and matures. Our findings suggest that blockchain ecosystems tend to frequently change, especially in their early stages. The programmable (i.e., on-chain) structure of blockchain governance is not immutable, but can only be changed if there is sufficient support in the governing board. Many participants in the blockchains studied are concerned about privacy, cybersecurity, and high volatility—problems that could (in principle) be tackled exclusively on-chain.

The iterative changes in blockchain governance over time should be perceived as natural transformations, given that the ecosystem’s needs at each of the stages are substantially different, as is the number of participants. In the context of permissionless blockchains and cryptocurrencies, some authors (Alston 2020; Cowen 2019; Rajagopalan 2018) have considered blockchains to be constitutional regimes, where the rights and powers of each actor are not assigned by human administration, but by code, in order to enhance network neutrality. It may happen that existing members might be reluctant to accept specific changes to the governance structure, for instance, if those changes reduce their power or rewards. To avoid situations where (e.g., founding) members oppose and block the evolution of the blockchain ecosystem, early governance rules included in the white paper (written in stage 1) should incorporate clearly defined “rules for changing the rules.” However, in the case of permissioned blockchains, our findings suggest that ecosystem participants may have more trust in the governance structure if there are off-chain mechanisms involving people they can contact and who can be held legally accountable.

Several recommendations for managers of blockchain ecosystems can be inferred from our findings. First, our data suggest that the probability of creating a successful blockchain ecosystem is largely dependent on network effects. To maximize these network effects, the founders of a blockchain should engage in community building initiatives already in stage 1, even if the technical infrastructure has not been created yet. At the same time, it is not advisable to allow many participants to join the ecosystem at this early stage, because it is a very fragile one. This dilemma can be best addressed by establishing extremely transparent rules of and for participation as early as possible; this set of rules reinforces the mechanism of self-selection and thus serves to attract new stakeholders that can add value to the ecosystem while it drives others (not fitting into the ecosystem) away. A high level of accountability can also be established by using traditional contracts and liability mechanisms.

The interlock between on-chain and off-chain governance mechanisms, and the communities deciding about them, poses challenges to the sustainability of the ecosystem. For instance, it is likely that (especially non-technical) users do not fully grasp all technological details, which may lead to misunderstandings. Furthermore, members with technical expertise may not see governance as a major concern in the early stages. In a similar fashion, it is important to clearly distinguish between the governance of the foundation behind the blockchain and the governance of the chain itself, although we observed that both are often mixed up in the discussion. Tradelens is an example of a blockchain which had to amend its governance after a difficult start, due to an imbalanced distribution of power among its members (Allison 2018).

Some level of conflict among ecosystem members as well as initial technical problems with the blockchain is practically unavoidable. In this respect, conflict resolution mechanisms are often overlooked during the initial design of the blockchain and are then developed after conflicts have already arisen. Our findings suggest it is important to install a (preliminary) conflict resolution procedure already in stage 1. This preliminary conflict resolution mechanism can be turned into a programmable (on-chain) solution which can be implemented in stage 2. Real-life examples of on-chain conflict resolution mechanisms include Polkadot’s referenda voting system and Tezos’ on-chain amendment and voting process, both based on PoS. Besides voting, Polkadot has also implemented a “slashing” mechanism where misbehaving validators may be punished and may lose a percentage of their tokens, depending on the severity of the infraction. In some blockchains, there is the option of forking a blockchain, but this may fragment the ecosystem (at a too early stage) and lower its credibility when trying to attract new members. As such, the substantial uncertainty arising from the possibility of experiencing a fork may motivate corporate entities in particular to not join the ecosystem.

Limitations and Directions for Future Work

The study reported in this paper has several limitations. Comparative case studies “face a particularly difficult trade-off between theory and empirical richness” (Eisenhardt and Graebner 2007, p. 29). The data presented in this paper may thus contain simplified views of a much more complex reality. In addition, it is possible that the views of our interviewees are biased, or that they have not shared information which is relevant to our research. To reduce those risks, we have triangulated interview data with publicly available documentation as well as participant observations.

In addition, this study is limited to three enterprise blockchains. We selected EWF, VCT, and CNF as illustrative cases of successful blockchain ecosystems with a wide variety of stakeholders. It is likely that the study of other cases, for instance, blockchains that have not managed to achieve stage 3 in a sustainable manner, might offer additional insights into why some governance structures are not adequate. Overall, the generalizability of the stage-gate framework can only be truly validated by means of large-scale quantitative theory-testing.

The scope of blockchain-based applications is rapidly growing. In the future, blockchain communities may develop novel governance structures that require extensions or modifications of the framework arising from our study. For instance, one can imagine that blockchains will develop beyond stage 3, which would entail an even higher level of decentralization, involving a completely self-regulated on-chain system (Morrow and Zarrebini 2019). From a conceptual point of view, such a blockchain could have multiple purposes and could also become interoperable with other blockchains. Given the young age of all existing blockchain ecosystems, it is too early to tell whether and under which conditions such transformations will occur and succeed.

Moreover, further research is needed into the interrelationship between on-chain and off-chain governance mechanisms. A large portion of previous research on blockchain governance has focused on permissionless blockchains and cryptocurrency applications. Permissioned and permissionless blockchains tend to have quite different objectives and type of stakeholders. As such, more work is needed to understand which governance lessons are generalizable to both types of blockchains, and which lessons are particular to only one type. Likewise, future work can explore how to design consensus mechanisms that are tailored to the governance preference of a specific ecosystem.

Another interesting question is at which point a blockchain ecosystem is ready to move to the next stage, given the stage which it currently is in. This question raises opportunities for researchers to develop metrics for assessing the maturity of a blockchain ecosystem and to provide recommendations accordingly. These metrics may be based on, for instance, the number of users, validator nodes, and applications created in the blockchain; the number of transactions per day; or the total capitalization.