Keywords

The Token Economy and the Need for Cross-Ledger Interoperability

Decentralization of Token Economy Instances

By increasing the automation of business processes, favoring economies of scale, and enabling improved customer outreach, digital platforms have become a backbone of business ecosystems. A business ecosystem is an “economic community of interacting actors (here: individuals and organizations) that all affect each other through their activities” (Jacobides et al., 2018, p. 2257). Among the various uses of digital platforms in business ecosystems (e.g., for information exchange in supply chains), digital platforms are often involved in managing ownership of assets, such as fiat money and stocks in online banking or electronic money systems (e.g., DigiCash; Camp et al., 1995), where assets are represented as tokens (i.e., sequences of characters). In this context, asset ownership management refers to the creation of tokens that reference real-world assets (e.g., fiat money) and the use of these tokens to prove and transfer asset ownership (Sunyaev et al., 2021). The concept of using digital tokens for asset ownership management is called the token economy. A token economy instance is an application of the token economy concept in a business ecosystem and comprises the digital platforms used for asset ownership management, the actors providing these digital platforms as well as actors consuming services available via these platforms, and the political means to operate a token economy instance (Sunyaev et al., 2021). There can be multiple token economy instances that use the same digital platform, and individual instances can use multiple digital platforms, such as when companies in one business ecosystem transfer money through the independent but interconnected online banking platforms of different banks to other business ecosystems. The actors and means enabling interoperability between digital platforms are also part of token economy instances.

Today’s digital asset ownership management is usually mediated by central actors, such as banks and notaries, which provide digital platforms to other actors (e.g., for online banking). One of the major tasks of central actors in asset ownership management is the prevention of fraud, which includes the manipulation of account balances and double-spending. Double-spending refers to using the same tokens in multiple transactions (Karame et al., 2012; Nakamoto, 2008). For example, actor A owns USD 100, represented as a number in online banking. A transfers ownership of that USD 100 via an online banking transaction, using "USD 100" as a token, to actor B. After the transaction, A must not be able to transfer the same USD 100 to another actor, C. Otherwise, the USD 100 would have been double-spent, and B and C would each own the same asset. Token economy instances that mainly rely on central actors represent centralized instances.

In centralized token economy instances, central actors usually enable interoperability with other central actors so that tokens can be transferred between them across digital platforms. To this end, central actors agree on technical and political standards (e.g., as proposed by the Society for Worldwide Interbank Financial Telecommunication; short: SWIFT). By using standards, actors can easily interact with other actors, independent of the digital platforms used, increasing flexibility in business relations and actors’ ability to reach other actors (e.g., to transfer assets for products; Panurach, 1996) and enabling large network effects (Scott et al., 2017).

A strong reliance on central actors, however, can lead to technical and political drawbacks. Technically, asset ownership management often relies on digital platforms controlled by central actors (e.g., in terms of maintenance and security). Such centralized digital platforms can be prone to vulnerabilities regarding data integrity because only the central actors controlling a platform have control over the stored data and can be able to tamper with it because the processes executed via the platform cannot be verified by other actors. Politically, the central actors can accumulate decision rights for the governing of provided digital platforms, dependencies on the central actors can be increased, and all individual actors must trust in the honest and reliable behaviors of the central actors (Chen et al., 2020). For example, the decisions regarding the specifications of application programming interfaces (APIs) offered for interactions with digital platforms are made by the central actors providing the platforms, which can limit the flexibility in asset ownership management for actors using the digital platform. Moreover, actors must trust that the central actor will not stop providing services on a digital platform or increase service fees.

Decentralizing token economy instances can address drawbacks associated with the involvement of central actors in asset ownership management by decreasing dependencies on central actors and their digital platforms. Instead, various actors jointly operate a digital platform and share the associated responsibilities, such as for platform maintenance. In this chapter, we focus on two perspectives on the decentralization of token economy instances: technical and political. Technical decentralization refers to the "degree that increases and decreases with the number of distributed, interconnected nodes that operate independently without a central authority" (Sunyaev et al., 2021, p. 3). Political decentralization refers to "the degree of equal distribution of permissions and responsibilities across all agents [actors] that independently act according to their individual incentives" (Sunyaev et al., 2021, p. 4).

Decentralizing token economy instances can enable direct transactions between actors without mediation (e.g., by banks; Beck, 2018), improve cost efficiency (Catalini, 2017), and prevent performance bottlenecks. Moreover, the equal and independent engagement of actors in the advancement of token economy instances can be increased (e.g., Chen et al., 2020), for example, by allowing actors to propose new asset representations through tokens to increase flexibility in managing asset ownership.

To decentralize token economy instances, multiple actors should be able to participate in decision-making for the crucial tasks in asset ownership management that are currently performed by central actors. In summary, the main challenges to be addressed in decentralized token economy instances are as follows:

  1. 1.

    Prevention of the double-spending of tokens.

  2. 2.

    Storage of account balances and transactions in a tamper-resistant way.

  3. 3.

    Coordination of actors to reach agreements.

Decentralized Token Economy Instances That Are Based on Distributed Ledger Technology

To decentralize digital platforms for asset ownership management in token economy instances, distributed ledger technology (DLT) can be used. DLT allows for the automation of crucial tasks of the central actors involved in centralized token economy instances (e.g., the prevention of double-spending and the manipulation of balances; Sunyaev et al., 2021) and makes these task executions verifiable for any actor with access to the used distributed ledger. For example, each actor with access to the distributed ledger can verify that transactions have been correctly processed and detect fraudulent transactions (e.g., in double-spending attempts) which shifts the trust of actors from a central actor to a set of actors that jointly govern and operate the digital platform and the ledger.

A DLT system comprises a network of computing devices (i.e., nodes), where nodes are usually controlled by various actors. Nodes jointly operate a replicated distributed database (i.e., a distributed ledger; Sunyaev, 2020). Each node maintains a local replication of the ledger, which stores a set of transactions between actors via the DLT system, and executes the same DLT protocol. A consensus mechanism is used to achieve consistency across all versions of a ledger stored by individual nodes. Many consensus mechanisms used in DLT (e.g., Nakamoto Consensus in Bitcoin) are Byzantine fault tolerant (Lamport et al., 1982), as they resolve double-spending and prevent retroactive manipulations of asset ownership by storing transactions in a tamper-resistant way, which resembles the tasks of central actors.

In DLT-based token economy instances, tokens can be created and managed in two principal ways: first, via the DLT protocol; second, via smart contracts. Tokens created via the DLT protocol are native tokens and are often used in DLT systems to incentivize nodes to contribute computational resources to the operation of a DLT system. For example, nodes in the Bitcoin network can receive newly created tokens as rewards for participating in the consensus mechanism process (Nakamoto, 2008). Using smart contracts, actors can implement custom business logic to create and manage tokens representing arbitrary assets on top of DLT protocols. Smart contracts are software programs that are deployed to a distributed ledger and can be called via transactions (Kannengießer et al., 2021). Tokens created and managed via smart contracts can be acquired by using native tokens of the respective distributed ledger. Smart contracts increase flexibility in token economy instances by enabling the development of customized tokens and logic for asset ownership management (e.g., conditional payments). Several smart contracts offer functionalities for buying customized tokens in exchange for native tokens. Actors transfer native tokens to the smart contract by issuing a transaction to the DLT system. The transaction needs to call a specified function of the target smart contract. After processing the transaction, the smart contract keeps the received native tokens and updates the balance of custom tokens associated with the actor, who transferred the native tokens, in its persistent storage. For example, CryptoKitties is an application based on an Ethereum smart contract that creates customized tokens representing collectables, called cats. Cats can be bought via the CryptoKitties smart contract and are paid for in Ether. The CryptoKitties smart contract retains the tokens and assigns ownership of the purchased cat tokens to the actor who paid for them. The flexible specification, creation, and management of DLT-based tokens allow multiple decentralized token economy instances to coexist on the same DLT system. However, the formation of decentralized token economy instances comprising different DLT systems is still a challenge, for example, due to a lack of technical standards for DLT protocols and the uncertain applicability of prior governance mechanisms in the decentralized connection of decentralized systems.

There are a variety of DLT-based token economy instances (e.g., in decentralized finance) where actors can benefit from the customizability of terms for automated payments, for example, in decentralized crowdfunding and offerings for fractional shares. To provide such services, business ecosystems pose individual technical requirements on DLT protocols (e.g., energy-efficient transaction processing).

While requirements for DLT protocols strongly vary between business ecosystems (e.g., large scalability and high transaction throughput is often required for IoT use cases; Lücking et al., 2021), trade-offs between DLT characteristics prevent DLT systems from simultaneously meeting all these requirements. Those trade-offs that cause an improvement in one characteristic (e.g., availability) can lead to the decline in another (e.g., consistency; Kannengießer, Lins, et al., 2020). To meet the various technical requirements of business ecosystems, despite the trade-offs between DLT characteristics, numerous specialized DLT protocols have been developed, such as Quorum for connecting banks for international payments and VeChain for tracking and tracing in supply chain management. Specialized DLT protocols use individual consensus mechanisms, data structures (e.g., blocks including transactions or only transactions), and protocols for communication between nodes and have different smart contract capabilities regarding expressiveness and capabilities for interacting with information systems external to a DLT system (Kannengießer et al., 2021). As token economy instances use DLT protocols or even combinations of DLT protocols suitable to the requirements specific to the business ecosystems, the technical heterogeneity across DLT systems used in token economy instances increases, which complicates the connection of DLT systems (e.g., because individual APIs must be considered), thus hindering asset ownership management across token economy instances. As long as actors using one DLT system cannot transact with actors using another one, network effects and flexibility in business relations can hardly increase beyond individual DLT systems (Sunyaev et al., 2021; Zhou & Zhu, 2006). To overcome these drawbacks and enable actors using different DLT systems to interact with each other in token economy instances, asset ownership management across DLT systems is required.

Cross-ledger interoperability (CLI) offers the technical capabilities to connect isolated DLT systems and overcome drawbacks, such as limited network effects and flexibility in business relations. CLI can enable the following three principal functionalities (Kannengießer, Pfister, et al., 2020; Lacity, 2020): cross-ledger token transfer, cross-ledger token exchange, and cross-ledger smart contract execution. Cross-ledger token transfers comprise unidirectional transactions that transfer tokens from one DLT system to another. Cross-ledger token exchanges require at least two dependent token transfers, one on each of the relevant DLT systems, to exchange tokens between actors. Tokens are only exchanged between two actors A and B if both actors own accounts on both DLT systems and agree on making a specific number of tokens on their distinct DLT systems accessible to their corresponding exchange partner. Cross-ledger smart contract execution refers to the execution of a smart contract on DLT system B via a transaction issued to DLT system A, but the transaction does not necessarily transfer tokens. Smart contract execution across DLT systems, moreover, allows actors to execute business logic in targeted DLT systems (e.g., to receive tokens created by smart contracts).

CLI is achieved through CLI protocols that are executed in CLI systems (e.g., BTC Relay, Fusion, and Kusama). CLI systems are designed to secure cross-ledger asset ownership management (e.g., by preventing double-spending) and to coordinate interactions between actors of different DLT systems. CLI systems can be centralized (e.g., managed by central actors) or decentralized (e.g., managed by a set of actors), which affects the degree of the decentralization of token economy instances incorporating different DLT systems. In a cross-ledger token economy instance, for example, a CLI system provided by a central actor can recentralize the interactions of actors from one DLT system with another one, thus reintroducing drawbacks of centralized token economy instances, such as decreased availability, censorship resistance, and fraud resistance. However, a too high degree of political decentralization (e.g., caused by the engagement of too many actors into the governance of a CLI system) can slow down decision-making, whereas the delegation of decision rights to a central actor can lead to the neglect of other actors’ interests. To enable DLT-based token economy instances in which actors can use different DLT systems while preserving the benefits of decentralization (e.g., the verifiability of transactions by each actor), approaches to the technical connection of DLT systems as well as the governance of CLI systems and connected DLT systems must be incorporated by actors. Only with appropriate governance can the technical and political decentralization of token economy instances that encompass different DLT systems be reconciled.

The rest of this chapter explains principal approaches to technically connect and politically manage token economy instances comprising multiple DLT systems. In the next section, it is explained how DLT-based token economy instances can interact via CLI by presenting patterns of CLI systems. For each pattern, it is described how the degrees of the technical decentralization of connected DLT systems can be affected. “Political Decentralization in Token Economy Instances That Comprise Different Distributed Ledger Technology Systems” section elucidates political decentralization of token economy instances comprising multiple DLT systems in the context of decentralized governance. In “Drawing Conclusions from the Technical and Political Perspectives on Centralization and Decentralization of CLI Systems” section, certain ways to balance the centralization and decentralization of token economy instances comprising different DLT systems to synergize the benefits of centralized (e.g., fast decision-making; Chen et al., 2020) and decentralized systems (e.g., direct transactions between actors; Beck, 2018) are discussed.

Technical Decentralization in Token Economy Instances That Comprise Different Distributed Ledger Technology Systems

Various CLI protocols have been proposed (e.g., atomic cross-chain swap and XCLAIM; Herlihy, 2018; Zamyatin et al., 2019) and implemented as CLI systems, such as BTCRelay and Kusama. CLI systems comprise both actors and technical components, which have different designs to provide CLI functionalities (i.e., token transfer, token exchange, and smart contract execution). These designs strongly impact CLI systems’ degrees of technical decentralization because they specify the actors and nodes involved in operating a CLI system and how DLT systems communicate (i.e., direct or indirect, see Fig. 3.1; Sunyaev et al., 2021). DLT systems are directly connected by CLI systems when nodes of different DLT systems can communicate with one another without mediators. In indirect connections, nodes in DLT systems are not able to directly communicate with each other but communicate via mediators, such as notaries (see N in Fig. 3.1). CLI systems enabling indirect communication between DLT systems can technically centralize the connection between DLT systems and a CLI system, which can reintroduce drawbacks of centralized token economy instances (e.g., the dependence on central actors for asset ownership management across digital platforms).

Fig. 3.1
figure 1

Overview of methods for communication between nodes (adapted from Sunyaev et al., 2021)

Full size image

The following sections describe that different typologies of the communication between DLT systems via CLI systems exist and how these typologies can affect the corresponding degree of technical decentralization of token economy instances, which comprise different DLT systems.

Cross-Ledger Interoperability Patterns and Their Degrees of Technical Decentralization

Cross-ledger token transfers usually require that the tokens to be transferred are not accessible to actors in a source DLT system once a corresponding number of tokens in a target distributed ledger has become accessible to them. If the tokens in the source DLT system remain accessible after new tokens have been created in the target distributed ledger, tokens referring to the same value could then be spent in both DLT systems, allowing for cross-ledger double-spending.

To prevent cross-ledger double-spending, the atomicity of CLI functionalities must be guaranteed (Herlihy, 2018). CLI functionalities are usually executed based on sequences of transactions in DLT systems that are involved in cross-ledger asset ownership management. Atomicity in CLI functionalities refers to the capability of a CLI protocol to guarantee that either all transactions required for a CLI functionality are successfully processed in all relevant DLT systems or that no transaction takes place (Herlihy, 2018). If a CLI protocol does not guarantee atomicity, asset ownership management using that protocol can become prone to theft and cross-ledger double-spending.

To achieve atomicity of CLI functionalities, transactions required in CLI functionalities must be verified in all DLT systems that exchange tokens with one another. Such verifications prove whether transactions have been successfully processed in a DLT system or not. If a verification fails, the asset exchange is aborted. CLI systems can require actors to verify their transactions themselves through direct communication or employ a central actor, who verifies transactions on behalf of the actors exchanging tokens across DLT systems, for indirect communication.

Among a variety of CLI system designs three principal patterns of CLI systems have emerged (Kannengießer, Pfister, et al., 2020): the manual asset exchange (MAE) pattern, the notary pattern, and the sidechain pattern. In the following section, these patterns are explained, and their individual degrees of technical decentralization are discussed. In the descriptions of the CLI patterns, the steps for cross-ledger interactions illustrated in Fig. 3.2 are referenced to illustrate the basic functioning of each pattern.

Fig. 3.2
figure 2

A schematic overview of CLI patterns and their protocols

Full size image

Manual Asset Exchange Pattern

The MAE pattern enables cross-ledger token exchanges and can be applied manually by at least two actors without software artifacts, except for the involved DLT systems and optional tools for the communication between actors needed, for example, to agree on the number of exchanged tokens (Buterin, 2016; Kannengießer, Pfister, et al., 2020). After the actors have agreed on exchanging tokens, two principal actions are executed: token locking and token provision. First, exchange partners lock their tokens in their respective source-distributed ledger. Tokens are locked to actors when an access control mechanism prevents these actors from accessing the tokens. In token provision, the tokens are unlocked by the exchange partners in their respective target distributed ledger (e.g., by using a secret).

For locking and unlocking tokens, the MAE pattern often applies the atomic cross-chain swap protocol, which is based on hashed timelock contracts (HTLCs). HTLCs are smart contracts that allow for payments that are conditional on a hashlock and a timelock. The hashlock stores a hash value hs, computed by a hash function h from a secret value s. The hashlock grants access to tokens after receiving \( \hat{s} \), when \( h(s)=h\left(\hat{s}\right) \) applies. A timelock has a value t, which specifies the maximum time during which tokens are locked. When t elapses, locked tokens are then automatically returned to sender. To unlock tokens locked in an HTLC, a transaction must be sent to the HTLC and execute its hashlock function with an argument \( \hat{s} \), with \( h(s)=h\left(\hat{s}\right) \) within t (Herlihy, 2018). The probability for an attacker to find an \( \hat{s} \) with \( \hat{s}\ne s \) and \( h(s)=h\left(\hat{s}\right) \) within t must be negligible to achieve a high level of security for an HTLC.

The following example illustrates the functioning of an MAE pattern that uses the atomic cross-chain swap protocol based on HTLCs (Buterin, 2016): In Step I.1, Alice asks Bob to exchange her tokens from DLT system A with his tokens from DLT system B. Bob agrees on the exchange in Step I.2. Alice creates s and then computes hs. In Step I.3, Alice deploys her HTLC to DLT system A, with the hash value hs and a timelock t1, and locks the number of tokens she wants to exchange by using the HTLC. In Step I.4, Alice shares hs with Bob. After Bob has verified that Alice’s HTLC has been deployed and the tokens are locked, Bob deploys an HTLC in DLT system B, where the hashlock also uses \( {h}_s \), but with a timelock t2 < tr; tr corresponds to the time remaining for the timelock t1. Bob locks the tokens to be exchanged with Alice’s tokens by using his HTLC (Step I.4). Alice knows s and can claim the tokens locked in Bob’s HTLC before t2 elapses (Step I.5). After t2 has elapsed, Bob can face two situations. In the first situation, Alice claimed the tokens from Bob’s HTLC using s, thus disclosing s to Bob. Using s, Bob can claim the tokens from Alice’s HTLC before t1 elapses (Step I.6). In this case, both transactions are completed. In the second situation, Alice does not claim the tokens that are locked in Bob’s HTLC, and the HTLC transfers the locked tokens back to Bob after t2. Because Bob does not know the secret value s, he cannot claim the tokens from Alice’s HTLC, and they are also returned to her after t1 elapses. In this case, neither of the transactions is completed.

Assuming that both actors act rationally, the HTLC-based atomic cross-chain swap protocol guarantees that either both transactions in the token exchange are successfully executed or that neither are (Herlihy, 2018). Atomicity can only be violated when actors act irrationally, for example, when Alice shares s with Bob without claiming her tokens, and Bob claims the tokens from Alice’s HTLC. Alice then loses ownership of her own tokens to Bob on ledger A, while Bob keeps the ownership of his tokens on ledger B.

MAEs exhibit a high degree of technical decentralization in token exchange because no central actor is required, and actors can communicate directly. Exchange partners are found in manifold ways, for example, through decentralized exchanges. However, the MAE pattern is only applicable if actors from different DLT systems agree on tokens to be exchanged. Using the MAE pattern, cross-ledger token exchanges are the only CLI functionality that can be provided to actors (Koens & Poll, 2019).

Notary Pattern

CLI systems associated with the notary pattern can enable token exchanges, token transfers, and smart contract executions across DLT systems (Koens & Poll, 2019) and can automate certain processes in CLI systems that apply the MAE pattern (e.g., transaction verification). Multiple DLT systems are connected via a mediator, called a notary, which passes on information (e.g., for transaction verification) about one distributed ledger to another (Buterin, 2016). In this way, notaries can coordinate manual processes (e.g., finding an exchange partner and transaction verifications) performed in MAE-based CLI systems to a certain degree. Notaries can be centralized (i.e., a single central actor, as in Binance) or decentralized (i.e., a set of notaries that collaborate in a decentralized manner, as in the Interledger Protocol; Deng et al., 2018).

Notary-based CLI systems execute cross-ledger token transfers from DLT system A to DLT system B in two steps: token locking and token provision. In token locking, a transaction is sent to lock tokens in A and ensure that these tokens cannot be spent again (Step II.1). The tokens can either be locked indefinitely or can be unlocked in future cross-ledger token exchanges. For token exchanges, Notary-based CLI systems can apply the atomic cross-chain swap protocol, as in MAE, but can also automate the manual actions (e.g., order matching and transaction verification). After the tokens are locked, the token provision on B can be requested (Step II.2). To prevent cross-ledger double-spending, the transaction for token locking must be confirmed in distributed ledger A before the corresponding tokens on B are provided (Step II.3). In token provision, either new tokens (e.g., native tokens or tokens created by a smart contract) representing the tokens locked in A are created in DLT system B (Back et al., 2014), or tokens previously locked in B are unlocked and made accessible to the respective actor (as in MAE-based CLI systems). The notary then verifies transactions in both DLT systems and notifies nodes in B that the tokens in A have been reliably locked (Step II.4). Then, the corresponding tokens are provided in B (Steps II.5 and II.6).

A notary-based CLI system is easily customizable (e.g., compared to sidechains); it can be used to connect most DLT systems. Therefore, the notary pattern offers large flexibility to achieve CLI. However, the notary pattern relies on indirect communication and introduces the notary as a potential single point of failure. Actors depend on the notary for cross-ledger interactions because they must rely on the timeliness and correctness of the employed notary’s notifications. Therefore, the degree of technical decentralization decreases, and central actors can emerge, as in current centralized token economy instances.

Sidechain Pattern

CLI systems that implement the sidechain pattern can enable token exchanges, token transfers, and smart contract executions across DLT systems in an automated yet decentralized way (Koens & Poll, 2019). In the sidechain pattern, there are two DLT systems, where one or both can play the role of a sidechain (Back et al., 2014; Buterin, 2016). Sidechains are DLT systems in which a smart contract is used to verify that transactions are stored in a distributed ledger. For verification, a smart contract usually uses the block headers of a target ledger (Back et al., 2014). Transaction verifications are cryptographically secured and do not require trust in central actors. After successful transaction verification, the intended CLI functionality is performed on a sidechain (e.g., transferring tokens to a specific actor’s address). Two exemplary CLI systems associated with the sidechain pattern are BTC Relay (Buterin, 2016) and Cosmos (Kwon & Buchman, 2016).

Like in the notary pattern, tokens are transferred between DLT systems A and B in two steps: token locking and token provision. In token locking (Step III.1), tokens are locked in A. Then, the provision of corresponding tokens is requested in B (Step III.2). Tokens are provided by creating tokens for one-way asset transfers or unlocking tokens (Steps III.4 and III.5). Instead of having a notary vouch that token locking has been completed in A, B can verify the transaction for token locking with a mechanism, such as simple payment verification (SPV; Step III.3), implemented in a smart contract (Back et al., 2014). If only one of the multiple DLT systems has smart contract capabilities sufficient to verify transactions, then only that DLT system can become a sidechain. That sidechain is called one-way pegged (Back et al., 2014). If multiple DLT systems have the capability to verify transactions in other distributed ledgers, bidirectional transaction verifications are possible between these ledgers. Each of the distributed ledgers can become a sidechain. Both are considered two-way pegged sidechains.

An example of a one-way pegged sidechain is BTC Relay, where only Bitcoins can be used to pay for Ethereum tokens but not vice versa. BTC Relay uses the Ethereum blockchain as a sidechain and implements a mechanism to verify transactions on the Bitcoin blockchain using an Ethereum smart contract (BTC Relay, 2018). The Ethereum blockchain can play the role of a sidechain for the Bitcoin blockchain. For transaction verifications, the BTC Relay smart contract stores the current block headers of the Bitcoin blockchain. To this end, the latest Bitcoin block headers are issued to the BTC Relay contract by nodes, called relayers. Relayers can be set up by any actor with access to the Ethereum and Bitcoin blockchains. Relayers do not need to be trusted like notaries because the correctness of data they issue to the BTC Relay smart contract can be cryptographically verified (Buterin, 2016). In this way, transactions in the Bitcoin blockchain can be verified by smart contracts in the Ethereum sidechain via the BTC Relay contract.

Sidechains exhibit a high degree of decentralization because transactions in another distributed ledger are verified without a central actor. Instead, nodes of sidechains directly communicate with nodes of other DLT systems (e.g., Cosmos) or via various relayers (Buterin, 2016). Sidechains use the built-in lightweight verification mechanisms of DLT systems, executed by smart contracts deployed to the distributed ledger, and the execution directly on-chain enables sidechains to largely automate CLI functionalities. Despite the potential to largely automate CLI functionalities in a decentralized way, CLI systems applying the sidechain pattern pose technical requirements on DLT systems, limiting flexibility in the application of the sidechain pattern compared to the MAE pattern and the notary pattern. For example, DLT systems must support specific smart contract capabilities to execute verification mechanisms. DLT systems that do not meet these requirements cannot be fully integrated into a network of decentralized token economy instance by using the sidechain pattern.

Dependencies Between Technical Decentralization and Security and Performance Characteristics

In the following section, dependencies between DLT properties (e.g., performance and security) and the degree of technical decentralization of token economy instances based on multiple DLT systems are illustrated in the example of cross-ledger token transfers. In isolated DLT systems, trade-offs between DLT properties, such as security and performance, can impact the degree of technical decentralization of a DLT system (Kannengießer, Lins, et al., 2020). In public-permissionless DLT systems (e.g., Bitcoin and Ethereum), any node can join or leave a DLT system and can participate in the consensus mechanism. If a large number of independent nodes participate in a DLT system, the DLT system can achieve a high degree of decentralization, which is desirable in terms of security (Gojka et al., 2021; Kannengießer, Lins, et al., 2020). To achieve a high degree of technical decentralization, all nodes in a DLT system should be able to directly communicate with each other and to participate in consensus finding with equal influence.

Consensus mechanisms can achieve two types of finality: immediate or probabilistic. Finality is reached when a transaction is included in the distributed ledger and cannot be altered or reversed (e.g., by excluding the transaction from the main branch of the distributed ledger). Most consensus mechanisms with immediate finality, such as Practical Byzantine Fault Tolerance (PBFT; Castro & Liskov, 1999), cannot scale to a large number of nodes due to the increasing communication complexity. This limited scalability can decrease the possible degree of decentralization of DLT systems because only a limited subset of nodes in a DLT system can be considered in consensus finding (Kannengießer, Lins, et al., 2020). Consensus mechanisms that allow for a high degree of decentralization (e.g., Nakamoto consensus in Bitcoin) mostly relax consistency assumptions to allow for the consideration of more nodes in consensus finding. These consensus mechanisms often achieve probabilistic finality, which is why it can remain uncertain whether a transaction issued to the DLT system will eventually be stored in the distributed ledger (Nakamoto, 2008). Over time, inclusion of transactions becomes more likely to be confirmed by all nodes in a DLT system so that the transaction will remain in the ledger (Kannengießer, Lins, et al., 2020).

The type of finality affects the number of nodes that can be included in a consensus mechanism, and thereby, the degree of technical decentralization in a DLT system. In addition to the degree of technical decentralization, the type of finality also influences the atomicity and processing time of cross-ledger operations. To guarantee atomicity in cross-ledger transactions, CLI systems require actors to initially send a transaction to lock tokens in a DLT system A and then wait until that transaction is confirmed. Next, the corresponding tokens are created or unlocked in a target DLT system B. In DLT systems that implement consensus mechanisms with probabilistic finality, a reasonable time (i.e., confirmation period) must pass to ensure that transactions will not be excluded from the main branch before the corresponding tokens can be created or unlocked securely on B to prevent cross-ledger double-spending (Back et al., 2014). For example, a confirmation period of one to two days is recommended for cross-ledger transactions from the Bitcoin blockchain through the probabilistic Nakamoto consensus (Back et al., 2014). In contrast, consensus mechanisms allowing for total finality do not require such a confirmation period, and tokens can be created almost instantly or unlocked on B without the risk of cross-ledger double-spending. The finality type (i.e., immediate or probabilistic finality) affects the processing time of cross-ledger token interactions. Thus, design decisions, such as the choice of consensus mechanisms, can influence the security (e.g., preventing cross-ledger double spending) and performance (e.g., processing time) of CLI.

DLT protocols and CLI protocols represent technical core components for token economy instances that comprise multiple DLT systems. The protocols must be cautiously selected and configured to suit token economy instances’ individual requirements (e.g., regarding confidentiality, confirmation latency, and throughput). To better understand how DLT systems and CLI systems are governed by actors (e.g., to specify requirements), the following section discusses the political perspective on decentralization.

Political Decentralization in Token Economy Instances That Comprise Different Distributed Ledger Technology Systems

Political decentralization refers to the coordination of actors in business ecosystems and how actors govern digital platforms. Among various governance types (e.g., corporate governance or environmental governance), this chapter focuses on IT governance. IT governance is a "framework for decision rights and accountabilities to encourage desirable behavior" among actors (Weill, 2004, p. 3) and describes a set of policies and rules for decision-making that supports IT management.

IT governance comprises three principal dimensions: decision rights, accountabilities, and incentives (Beck et al., 2018). Decision rights incorporate two kinds of rights (Beck et al., 2018; Fama & Jensen, 1983): decision management rights and decision control rights. Decision management rights encompass actors’ rights to make proposals (e.g., for updates) and implement decisions (e.g., implementation of updates; Fama & Jensen, 1983). Decision control rights refer to the rights required to participate in decision-making regarding the implementation of proposals of actors with decision management rights and how to measure and monitor decision outcomes (Fama & Jensen, 1983). Decision management rights and decision control rights can be assigned independently to different actors in a token economy instance. In token economy instances using the Bitcoin system, for example, decision management rights regarding the integration of software updates in the Bitcoin protocol are assigned to a small group of actors (e.g., core developers; De Filippi & Loveluck, 2016). Additionally, the majority of improvement proposals are made by a few actors, although any actor within token economy instances using the Bitcoin system has the decision management rights to make proposals (Azouvi et al., 2019). Decision control rights are assigned to actors who control the nodes of DLT systems who can vote on proposals and independently decide whether to update their nodes or not (Arruñada & Garicano, 2018).

Decision rights can strongly affect the degree of political decentralization in a token economy instance (Beck et al., 2018; King, 1983). In a token economy instance with a low degree of political decentralization, decision rights are concentrated among a few actors. Thus, permissions and responsibilities regarding decision-making are distributed unequally across actors in such instances and two-level hierarchies can emerge through the unequal distribution of decision rights. In token economy instances with high degrees of political decentralization, decision rights are distributed among many actors, assigning permissions and responsibilities more equitably.

Accountability refers to whether actors are required to justify their decisions and suffer corresponding consequences (Beck et al., 2018). For example, if nodes include an invalid transaction in their ledger, they must forego their rewards. In the presence of a set of rewards (e.g., financial bonuses) and penalties (e.g., compensations of damages) that is applied to decision outcomes, the assignment of accountabilities to actors can make them incorporate the consequences of their decisions into their decision-making processes, thereby incentivizing actors to align their interests with the goals of a token economy instance.

Incentives comprise a set of rewards and penalties that are put in place to encourage actors to align their interests with a particular goal and to act toward attaining that goal (Beck et al., 2018). For example, a bank can be penalized for manipulating actor balances by revoking its licenses. While in centralized token economy instances the central actors can often be held accountable by authorities that are external to a token economy instance (e.g., by courts), holding actors accountable in a decentralized token economy instance can be more difficult if actors’ real-world identities are unknown. Encouraging desirable behaviors of actors in decentralized token economy instances means ensuring accountability (e.g., by signing of transactions) and designing incentives (e.g., monetary rewards) that must be enforced within a token economy instance.

Usually, multiple governance mechanisms are put in place to coordinate a token economy instance. Governance mechanisms are the means (e.g., controls, guidelines, and policies) to manage a token economy instance (e.g., the assignment of decision rights to actors) and comprise a set of rules and procedures that are applied by actors to make decisions. For instance, elections are governance mechanisms in democracies. Through elections, decision rights are assigned to the actors elected by most actors. The decision rights are only assigned for a predefined time (i.e., the duration of an election period) and are redistributed by means of reoccurring elections. The actors can be held accountable for their decisions by courts and by the population (e.g., through reelections). An election is an example of a governance mechanism that can reduce the degree of political decentralization by transferring decision-making rights from many actors (i.e., a voting population) to a few actors (i.e., board members). The prospect of reelection also serves as an incentive for actors to perform desirable behaviors. Analogous to the governance mechanisms used in a society, a variety of governance mechanisms are applied in token economy instances to ensure their seamless operations. For example, token economy instances employ consensus mechanisms, which, similar to elections, assign decision rights to include transactions in a distributed ledger to different actors.

Governance in Token Economy Instances That Are Based on Distributed Ledger Technology

In the following, common governance mechanisms employed in DLT-based token economy instances and the principal phases token economy instances move through are described. Subsequently, the implications of the respective governance mechanisms for the degree of political decentralization among token economy instances that comprise multiple DLT systems connected by CLI systems will be discussed.

Token economy instances move through two principal phases, across which their degree of political decentralization can increase: the creational phase and the operational phase. The creational phase refers to the design and implementation of a digital platform for a targeted token economy instance and the acquisition of actors to participate in the respective business ecosystem. Moreover, initial decision rights are assigned to actors, and governance mechanisms are specified. At the end of its creational phase, a business ecosystem has specified an initial governance system (including governance mechanisms, processes, and involved actors) for a token economy instance and has created a functioning digital platform for managing asset ownership in the operational phase. The operational phase comprises everyday operations in token economy instances (e.g., validating and verifying transactions between actors) and decisions regarding the development of a digital platform and the business ecosystem, including the associated processes. Corresponding to the dynamics in business ecosystems (e.g., actors that join or leave the system), governance mechanisms for a token economy instance can change in the operational phase to adapt to a varying number of actors. In a token economy instance with only a few actors, decisions regarding changes in the DLT system can be discussed by actors in person until agreements are reached. With an increasing number of actors in a token economy instance, in-person discussions can become too cumbersome, and governance mechanisms can be changed to be supported by a digital platform. The digital support of governance mechanisms can facilitate the involvement of a larger number of actors in governance processes, compared to purely manual execution, because processes, such as voting procedures, can be automated.

Decision-making in governance mechanisms of DLT-based token economy instances is often performed through voting. In the Bitcoin system, for example, updates of the digital platform are based on votes by actors in DLT systems (Hsieh et al., 2017). Thereby, Bitcoin system can reach a high degree of political decentralization because the required decision control rights to participate in voting are assigned to all actors in the Bitcoin network (Hsieh et al., 2017). To allow voting among only a few actors, the requirements for certain decision control rights can be specified and directly assigned to specific actors using governance tokens (Jensen et al., 2021), or indirectly assigned via technical (e.g., a computational contribution to the DLT system) or economic capabilities (e.g., the number tokens owned by an actor; Hsieh et al., 2017).

In addition to increasing the number of actors involved in decision-making, digital governance mechanisms can automate the execution of governance processes (De Filippi & Loveluck, 2016). Especially, governance processes for recurring decisions in the operational phase lend themselves to automation (e.g., finding a consensus on the transactions to be included in a distributed ledger). If actors manually operate a distributed ledger (e.g., by taking notes), transactions must be validated and verified by any actor, and consensus finding can take a very long time because actors need to manually agree on each transaction. DLT-based token economy instances automate transaction validation and verification as well as consensus finding for transactions by using a consensus mechanism. Each actor operates a node to process transactions on their behalf. The Nakamoto consensus mechanism (i.e., the consensus mechanism used in the Bitcoin blockchain), for example, assigns decision management rights to propose a new block for the distributed ledger to an actor, who is randomly selected as a leader through a leader election process (Nakamoto, 2008). The leader proposes a block to be included in the distributed ledger. The leader is held accountable if invalid transactions are included in the block and will receive a reward if most nodes agree on storing the block (Nakamoto, 2008). In this way, actors are incentivized to make their nodes propose blocks that are likely to be accepted by other nodes. Decision control rights remain with all the actors controlling nodes in the Bitcoin network because they will not accept blocks containing invalid transactions (Nakamoto, 2008).

Cross-ledger governance is needed to coordinate the design decisions associated with CLI systems. These design decisions affect how CLI systems and DLT systems are connected, for example, to enable transaction processing for cross-ledger asset ownership transfers (Sunyaev et al., 2021). The mechanisms for cross-ledger governance are specified in the creational phase. CLI systems with a high degree of political decentralization in cross-ledger governance (e.g., in Kusama, Cosmos, and Polkadot) often use voting mechanisms for governance. For example, Kusama is a CLI system that has multiple voting mechanisms, which are implemented to distribute decision rights to actors in the CLI system. As in the Bitcoin community, actors in the Kusama system can propose and vote on improvement proposals. Actors vote by locking their tokens on a distributed ledger. The votes are weighted by the number of tokens locked and the time for which actors lock their tokens (Wood, 2019). In this way, actors can increase their voting power for proposals by increasing either the number of tokens locked or the time for which their tokens are locked. Beyond voting on improvement proposals, on-chain institutions (i.e., institutions composed of members with accounts on-chain) are also created, consisting of members that are elected by token holders and assigned additional decision rights (e.g., proposing emergency proposals; Wood, 2019). Establishing the governance mechanisms for CLI systems may produce additional difficulties compared to the governance mechanisms for token economy instances comprising a single DLT system due to the dependencies between connected CLI systems and a lack of technical standards. For example, not all connected DLT systems support on-chain voting mechanisms. In particular, technical incompatibility can pose a challenge for connecting already existing DLT systems. Additionally, in the creational phase of CLI systems, only a few actors of token economy instances may envision the connections between the relevant DLT systems. The identification of the set of actors that should be involved in governing a CLI system can be challenging in the creational phase.

Cross-ledger governance is an emerging research topic, and there are only a few concepts that are already used by actors in productive CLI systems (e.g., in Kusama or Polkadot). However, the impact of governance mechanisms on the degrees of political decentralization of token economy instances comprising a single DLT system allows us to draw analogies to the impact of governance mechanisms on instances comprising multiple DLT systems.

Political Decentralization of Token Economy Instances and Cross-Ledger Interoperability

Governance mechanisms can be applied by actors to assign the decision rights required for governance processes to few or many actors, leading to a correspondingly low or high degree of political decentralization in these processes. For example, decision rights can be concentrated among the core developers of a digital platform, causing a low degree of political decentralization. In contrast, assigning decision rights equally to all actors, and thus achieving a high degree of decentralization, prevents an abuse of power by central actors. Moreover, in token economy instances with a higher degree of political decentralization, decisions that maximize overall welfare become more likely than decisions that favor only a few actors (Chen et al., 2020).

While a high degree of political decentralization is desirable, governance mechanisms involving many actors are associated with increased coordination efforts and longer discussions (Arruñada & Garicano, 2018; Chen et al., 2020). The involvement of multiple actors in decision-making reduces even the likelihood of reaching agreements (Chen et al., 2020), which can cause stagnancy or a separation of token economy instances (De Filippi & Loveluck, 2016). Stagnancy can occur if no compromise can be found to which all actors agree and can be especially harmful when token economy instances need to respond quickly to environmental changes (e.g., changes in laws or regulations) or emergencies (e.g., a discovery of major bugs). An example of stagnancy is the Bitcoin community’s debate on the proposal for increasing the block size limit, when the community could not reach an agreement for a long time (De Filippi & Loveluck, 2016; Hsieh et al., 2017). A separation of token economy instances can occur when disputes cannot be resolved. For example, after an unknown actor stole approximately USD 50 million in Ether (Zhao et al., 2017) from the decentralized autonomous organization (DAO) by exploiting smart contract vulnerabilities, the actors controlling nodes in the Ethereum network could not reach an agreement on whether to reverse the transaction history to undo the exploit (DuPont, 2017). Finally, a part of the Ethereum community reversed the transactions stored on their nodes, while a minority refused to do so. The community then separated into the current Ethereum that reversed the transactions and the Ethereum Classic communities, which did not reverse the transactions (DuPont, 2017).

In the creational phase of token economy instances, requirements must be refined and implemented frequently (e.g., when vulnerabilities in a codebase are discovered; Beck et al., 2018). To decrease the risk for stagnancy or separation, decision rights are often concentrated among a few actors to allow for faster decision-making (e.g., in the Bitcoin and Ethereum communities; De Filippi & Loveluck, 2016; Azouvi et al., 2019).

Connecting DLT systems via CLI builds dependencies between actors of token economy instances. For example, prior to updating a DLT protocol that is part of a token economy instance comprising multiple DLT protocols, actors of that DLT protocol must consider the compatibility of connected DLT protocols and the relevant CLI systems. If compatibility cannot be achieved using an existing CLI system, that CLI system must be refined accordingly, involving the actors of all connected DLT systems and, potentially, the actors that operate the CLI system. Therefore, CLI can complicate decision-making between actors. To better understand the dependencies introduced by CLI, the following section discusses how to find a balance between centralization and decentralization from both the technical and political perspectives.

Drawing Conclusions from the Technical and Political Perspectives on Centralization and Decentralization of CLI Systems

The introduction of CLI comes with additional dependencies between the technical and political degrees of decentralization. Like isolated token economy instances using a single DLT system, CLI systems move through two principal phases (i.e., creational and operational), and each phase is accompanied by individual challenges that are influenced by the dependencies shared by the technical and political perspectives on CLI systems (see Table 3.1). In the creational phase of CLI systems, often only a few actors envision the connection of DLT systems. These actors must identify the set of actors that should be involved in governing the CLI system to be used. The number of actors to be involved can become very large because DLT systems are operated by a multitude of actors who may be affected by a CLI system. To consider the large number of actors in governance mechanisms, a digital support of these mechanisms is desirable. However, a digital support of governance mechanisms for the introduction of CLI systems is challenging. Since CLI does not exist prior to the introduction of a CLI system, actors must either use software applications deployed in one of the DLT systems to be connected, requiring the actors of all DLT systems to have access to that DLT system; use external digital platforms (e.g., a DLT system accessible to all relevant actors), where either no or all actors will have equal decision rights; or employ a central actor who manages the introduction of a CLI system on behalf of all the actors involved (e.g., banks in centralized token economy instances). All the named options have drawbacks regarding the equal consideration of actors because governance must first be defined to achieve the inclusion of all actors. Defining governance in a decentralized way is difficult to automate when actors are scattered across different DLT and CLI systems because of a lack of technical standards. Deciding on technical standards for a variety of decentralized systems (e.g., DLT and CLI systems) can involve a large number of actors from different communities. Automation is desirable to enable this large number of actors to participate in the definition of standards in a decentralized way. While technical standards are necessary to enable digital support of governance mechanisms, a definition of governance mechanisms is necessary to create technical standards. Mutual dependencies between the definition of governance mechanisms and the presence of technical standards pose a major challenge for CLI governance.

Table 3.1 Benefits and challenges of different degrees of technical and political decentralization
Full size table

Governance mechanisms are designed and automated during the creational phase to coordinate decisions through technical protocols during the operational phase. To act and participate independently despite automation, the corresponding decision rights (e.g., deciding which cross-ledger transaction to pass on) must be assigned to nodes. The assignment of decision rights to actors through automated governance mechanisms influences the degree of technical decentralization in CLI and connected DLT systems. For example, DLT systems typically execute consensus mechanisms to agree on whether transactions will be included in a distributed ledger. To agree on transactions that will be included, a consensus mechanism redistributes decision rights to make a proposal (e.g., for a block) to one actor through a specified process (e.g., a leader election process). Similarly, CLI systems must specify governance mechanisms for tasks, such as transaction verification, for other distributed ledgers.

When balancing centralization and decentralization in token economy instances comprising multiple DLT systems, the dependencies arising in the creational and operational phases should be considered. Both the technical and political perspectives on decentralization show that decentralization favors transparency and an engagement of actors or nodes in decision-making, at the cost of performance in token economy instances that use different DLT systems. Moreover, achieving a high degree of decentralization becomes possible by utilizing technology to automate those governance mechanisms that can be executed by the underlying CLI and DLT systems. However, actors should not decentralize token economy instances comprising multiple DLT systems at all costs because additional governance overhead can be associated with decentralization, which may exceed the benefits obtained from decentralization. Finding the optimal balance between technical and political centralization and decentralization is mainly determined by the degree to which governance should be automated. For automation, actors should first be aware of the degree to which they want to be involved in governance processes within a system because technical decentralization largely entails automating these governance processes by mapping them to a technical system. By providing these insights, this chapter supports actors by specifying governance processes which balance centralization and decentralization, from a political perspective and from a technical perspective.