A proposal for a layer-2 CBDC on a rollup

Abstract

This paper presents a proposal for introducing a central bank digital currency (CBDC) within a permissionless blockchain environment, specifically utilizing a layer 2 rollup. Several factors make exploring a CBDC on a blockchain worthwhile, including the potential demand for public money on blockchains and leveraging blockchain fundamentals for programmable payments. While the issuance of CBDC on a layer 1 blockchain may be a straightforward approach, it comes with drawbacks such as dependencies on network rules and limited privacy. Instead, I propose a design where an intermediated CBDC is issued on layer 2 through a zk-rollup architecture by licensed financial intermediaries who also provide tokenized deposits on layer 1. This paper delves into the technical specifications, economic considerations, as well as the advantages and limitations of this proposed design.

1 Introduction

In recent years, central banks have been exploring the issuance of central bank digital currencies (CBDC), a form of digital central bank money. Numerous countries are engaged in research, pilot projects, or have already implemented CBDC in some form.¹ The impetus for this exploration stems in part from the emergence of blockchain technology and cryptocurrencies. The development of smart contract-enabled blockchains like Ethereum has catalyzed the growth of decentralized finance (DeFi) applications, presenting potential alternatives to conventional financial systems.

Currently, decentralized permissionless blockchains only support assets from decentralized protocols or private entities. This raises the question whether a public form of currency should be made accessible in these networks, and if so, how it could be implemented. For instance, a recent report by the European Parliament’s Committee on Economic and Monetary Affairs (2024) on the legislative process of the digital euro suggested that “[...] conditional payments in Digital Euros may also be carried out on permissionless distributed ledgers where until now only privately issued assets like crypto-assets or stable coins are available as a means of payment. [...] the Digital Euro would be made available as a token to be referenced on these chains.” Furthermore, Guo et al. (2024) state that “given some of the clear advantages offered by public DLTs, central banks may want to transition their CBDCs to public DLTs in the future.”

In this paper, I present a novel approach to make a CBDC accessible on a permissionless blockchain, leveraging state-of-the-art blockchain technology advancements. My proposal outlines a framework where an intermediated CBDC is provided by licensed financial intermediaries operating on layer 2 rollups. This design offers several advantages to the issuing central bank in comparison to alternative blockchain-related architectures, as I discuss below. However, it is crucial to emphasize that I do not claim that my proposal is unconditionally the optimal solution. Depending on the central bank’s objectives, there may be other, potentially non-blockchain-related, alternatives more suitable for CBDC issuance. Instead, my aim is to present a blockchain-centric solution that may align more closely with a central bank’s objectives compared to other architectures on a permissionless blockchain.

Having said that, there are also distinct advantages to issuing a CBDC on a blockchain. The technological and cryptographic fundamentals inherent to blockchains allow for innovative use cases, such as programmable payments, composability or solvency proofs. Furthermore, there is no need for the development of complex and expensive new infrastructure since the building blocks already exist in other blockchain applications.

A straightforward approach to issuing a CBDC on a permissionless blockchain could involve creating a token using an ERC-20 contract.² While this approach offers advantages in terms of compatibility and composability, it also presents several drawbacks. For instance, the central bank would be required to adhere to the rules of the network and would be subject to any changes to those rules. Additionally, ensuring the privacy of CBDC holders with respect to the public can be challenging. Transaction fees can be substantial and the finality of transactions can be slow, making this approach unsuitable for many real-world use cases.

Instead, I propose a design in which a CBDC is not issued directly on the layer 1 (L1) blockchain but on a layer 2 (L2), specifically on a rollup. A rollup is a layer 2 scaling solution where transactions are settled on the underlying blockchain network, but the transaction execution is outsourced off-chain. This approach addresses the challenges mentioned above. For instance, the dependencies on the rules of the underlying blockchain network are reduced and different transaction validity rules can be designed to introduce solutions for privacy or offline payments. Additionally, authenticating CBDC transfers does not need to rely on private-public key encryption as it is standard on most blockchains. Instead, another mechanism that might be easier to handle for non tech-savvy people could be used. Furthermore, this proposal allows for “trusted instant finality”, where a transaction can be confirmed instantly, with only the settlement on the blockchain occurring with a lag. This feature is particularly important for real-world applications. Finally, ensuring compliance with KYC and AML requirements becomes straightforward, as the rollup can be designed as a permissioned system.

The proposed design also offers advantages when compared to a sidechain setup. In a rollup, transactions are settled on the underlying blockchain, resulting in several benefits. Firstly, a rollup inherits the security of the blockchain itself, contrasting with sidechains that often require higher trust assumptions. Secondly, users have the ability to always withdraw their funds from the rollup to the underlying blockchain, provided this feature is incorporated into the rollup’s code. Detailed information about this can be found in Sect. 3.6. Additionally, the blockchain community is actively engaged in researching and developing rollup solutions. Notably, the largest smart-contract enabling blockchain Ethereum maintains a roadmap with a rollup-centric focus.³ Consequently, there exists substantial potential for leveraging synergies in this regard.

My proposal, discussed in Sect. 3, describes an intermediated CBDC. This mirrors the existing two-tiered financial system and involves a partnership between the central bank and licensed private institutions responsible for intermediating CBDC to the public. These licensed institutions, denoted as intermediaries, offer tokenized deposits on the layer 1 blockchain that are technologically similar to stablecoins and economically similar to bank deposits. To obtain CBDC, which exclusively exists on layer 2, users can open a tokenized deposit account with an intermediary and then acquire CBDC. The fact that the providers of tokenized deposits are licensed institutions should also contribute to stabilizing the peg between central bank money and private money on the blockchain, thus ensuring the singleness of money (Garratt & Shin, 2023).

In Sect. 4, I delve into several important topics that I do not cover in the technical explanations, such as central bank accounts for all, the design of layer 2 accounts, privacy considerations, offline payments, and some economic considerations. In Sect. 5, I discuss the advantages and drawbacks of my proposal.

To the best of my knowledge, this paper is the first to propose how an intermediated CBDC can be implemented on a permissionless blockchain through a rollup. The Reserve Bank of Australia (2023) analyzes tokenized FX settlement involving a CBDC and a rollup architecture. Gogol et al. (2024) discuss a multi-layer blockchain architecture including rollups in the context of cross-border CBDC trading through automated market makers. However, both articles focus on the trading and settlement of CBDC, whereas my proposal centers on the intermediation of a CBDC on a permissionless blockchain.

Chaum et al. (2021) explore the introduction of a privacy-sensitive retail CBDC. Their approach is based on eCash (Chaum, 1983; Chaum et al., 1990) and is not directly related to blockchain technology. In contrast, my proposal presents a design within a permissionless blockchain environment. Other works, such as Bank of Israel (2024) and Project Sela (2023), examine a two-tiered architecture for CBDC implementation. However, none of these works examine a rollup architecture.

Overall, the literature on CBDC design is growing, with several central banks conducting pilot projects or research on CBDCs. The BIS Innovation Hubs, in collaboration with many central banks, are conducting various CBDC design projects. For instance Mariana (2023), Dunbar (2022), Helvetia (2022), Jura (2021) or mBridge (2022) fall into the category of wholesale CBDC projects, some of which use distributed ledger technology. Furthermore, there are retail CBDC projects such as Rosalind (2023) or Icebreaker (2023). Moreover, some countries have CBDC projects that are either in a pilot state, such as China’s e-CNY (2021) or India’s e-Rupee (2023), or already in operation, like the Bahama’s Dollar (2019) or the Nigeria’s eNaira (2021). Norges Bank and Nahmii work on a sandbox project that also includes layer-2 solutions (Jacobo, 2022). Besides government institutions, other actors also work on the topic such as Swift (2024), who demonstrate the use of CBDCs for digital trade, tokenized asset networks and payments, or ConsenSys, who proposed a CBDC on Ethereum (Bouchaud et al., 2020). Finally, scholars have proposed specific CBDC designs such as Gross et al. (2022). Guo et al. (2024) offer a comprehensive review of various distributed ledger technologies suitable for implementing a CBDC and discuss their respective requirements, benefits, and drawbacks.

2 Background

A blockchain⁴ is a distributed digital ledger that consists of a growing sequence of blocks that are cryptographically linked. Many nodes hold a copy of the ledger and can validate whether all information included in the blockchain follows a set of predefined rules. Each block contains diverse data, including a cryptographic hash of the preceding block and transaction details. Users’ asset balances are represented by a mapping from account owners to balances which is called the state and is stored in a Merkle tree.⁵ The state root is included in each block.⁶

When users initiate a transaction, the state tree is updated to reflect the modified account balances. Subsequently, the new state root, along with the transaction data, is added to the next block in the blockchain. This transaction data encompasses various details, including the recipient, the amount, sender authentication, and a (call) data field capable of encoding arbitrary data.

The data field can be utilized for creating and engaging with smart contracts, which are computer programs deployed on the blockchain.⁷ Deploying a smart contract involves generating a transaction with an empty recipient field and encoding the contract’s logic within the data field. When deployed, the contract receives an address and can hold assets. To interact with the smart contract, a user creates a transaction that addresses the smart contract and specifies in the transaction’s data field which functions defined in the contract’s code should be executed. Smart contracts have facilitated the development of numerous decentralized applications and platforms, for instance within decentralized finance (DeFi) applications.

As the number of applications operating on a blockchain network and the volume of transactions sent over it rise, the blockchain trilemma emerges as a significant challenge. Coined by Vitalik Buterin, this term encapsulates the dilemma faced by blockchain networks in balancing decentralization, security, and scalability concurrently. While one way to enhance scalability is to increase the hardware requirements for nodes verifying the blockchain, this approach risks restricting participation for certain nodes and undermines decentralization. Nevertheless, some blockchains like Solana opt for heightened throughput and sacrifice decentralization to some degree. Another example involves establishing sidechains with bridges secured by n-of-N admin keys, a concept that increases scalability but harms security.

In line with the blockchain trilemma, many blockchain networks impose restrictions on the quantity of data that can be included into the blockchain per block. To mitigate the problem described in the trilemma, there has been active research and development aimed at increasing blockchain scalability without sacrificing either decentralization or security. One scaling solution is to rely on layer 2 designs such as payment channels.⁸

A more recent advancement in layer 2 solutions is the concept of rollups. Instead of transmitting transactions directly to the layer 1 network (such as Ethereum), a network participant known as a coordinator or sequencer batches (or rolls up) transactions within a layer 2 rollup environment. Once a sufficient number of transactions are amassed, a batch of transactions is settled on layer 1. Notably, only a compressed version of the transaction data is recorded on layer 1, leading to substantial savings in layer 1 block space compared to individually including all transactions on layer 1.

Fig. 1

Rollup

The implementation of a rollup is facilitated through smart contracts, as conceptually depicted in Fig. 1.⁹ ❶ Deployment of a rollup is initiated by creating a smart contract on layer 1, referred to as the rollup smart contract (RSC).¹⁰ ❷ The data field of the transaction creating the smart contract contains (i) the computer code that defines the rollup’s logic and (ii) the initial state. Similar to layer 1, the layer 2 state is represented by a Merkle tree, encompassing the accounts of users like Alice, Bob, Carol, and Dan, each with layer 2 accounts holding some Ether (ETH) for illustrative purposes.¹¹ Once this initial transaction is included in a block on layer 1, the rollup is deployed.

❸ To initiate a layer 2 transfer, Alice and Dan transmit their transaction data to the rollup sequencer instead of sending it directly to the layer 1 validators. Upon receiving these transactions, the sequencer updates the balances in the state tree and calculates the new state root. ❹ Subsequently, the sequencer creates a new transaction, which is forwarded to the layer 1 validators and addresses the RSC. This transaction’s data field comprises (a) the old state root, (b) the new state root, and (c) the compressed form of the transactions.

Moreover, there exists a mechanism on layer 1 to validate the transactions and state changes in the batch. Currently, two distinct methods are employed: fraud proofs for optimistic rollups and zero-knowledge proofs for zk-rollups, which I focus on in my proposal.¹² In zk-rollups, the sequencer generates a mathematical proof that attests to the validity of all transactions within the batch, embedding this proof into the layer 1 transaction. The RSC is designed to verify this proof and confirm the accuracy of the new state root. Consequently, all network participants can have confidence in the validity of a state change if it is approved by the RSC.

Zk-rollups offer scalability advantages in several ways. First, the zk-proof scales with the amount of input data, meaning that the cost per transaction decreases as more transactions are included in a batch. Second, only a compressed version of the layer 2 transactions needs to be recorded on layer 1, including compressed sender and recipient addresses and transaction amounts. As the validity of transactions (i.e., signatures) is proven by the zero-knowledge proof, this information is not needed. Consequently, a single transaction consumes approximately 80–90% less L1 block space when included in a rollup’s transaction batch compared to a regular L1 transaction (Brown, 2021; Buterin, 2021). To further reduce costs, it is possible to only post state differences to layer 1 rather than individual transactions.

Lastly, note that Fig. 1 simplifies some aspects compared to a practical implementation. For instance, it exclusively depicts rollup transactions within the layer 1 blocks, whereas regular layer 1 transactions can also be included in the same blocks. Additionally, transaction batches are not necessarily included in every block. Instead, the sequencer has the flexibility to delay batch propagation until a significant number of transactions have accumulated, potentially reducing costs.

3 Intermediated CBDC

I now introduce the main proposal. Users do not directly interact with the central bank. Instead, the central bank collaborates with government-licensed financial intermediaries, similar to banks. These intermediaries hold layer 2 CBDC accounts with the central bank and intermediate CBDC to the general public. This aims to replicate the private-public partnership model that is prevalent in the existing two-tiered financial system. All CBDC-related activities, such as deposits, transfers, and withdrawals, must be conducted through these intermediaries.

A key question arises regarding the exchange of layer 1 assets into L2 CBDC. It is unlikely that the central bank would accept any layer 1 asset for exchange, as this would introduce substantial exchange rate and counterparty risks. Instead, the intermediaries offer tokenized deposits (illustrated by

) on layer 1 that possess technological similarities to stablecoins and economic similarities to bank deposits. Only these deposits are eligible for exchange to CBDC. I denote these tokenized deposits as digital US-Dollar or DUSD. Although each intermediary provides a distinct type of tokenized deposits, similar to how banks’ deposits are not equivalent, I will refer to all of them as DUSD for simplicity.

Fig. 2

Intermediated CBDC

The central bank and intermediaries operate their own rollups, as depicted in Fig. 2.¹³ Consequently, rather than the central bank maintaining accounts for the public, it is the intermediaries who manage users’ L2 CBDC accounts and balances. When users hold DUSD on layer 1 and wish to acquire CBDC, they can transfer some money from their tokenized deposits to the intermediary’s rollup smart contract (RSC) and subsequently receive CBDC on the corresponding rollup.

Furthermore, the central bank maintains a ledger of the intermediaries’ CBDC holdings, similar to its current management of banks’ reserve accounts. Therefore, the CBDC held by users within the intermediaries’ rollups is fully backed by central bank money, whereas the tokenized deposits on L1 may not necessarily have central bank money as backing. The ledger of the intermediaries’ CBDC holdings is stored through a L2 state tree. Occasionally, the state root is recorded on layer 1 in the central bank’s RSC. It is worth noting that the central bank rollup is not strictly required in this design. An off-chain accounting and messaging system between the intermediaries and the central bank would suffice.

Finally, I want to emphasize that regular users do not necessarily need to understand the technical intricacies of L1 or L2 accounts or the underlying blockchain infrastructure. Instead, users should grasp the economic significance of the two forms of currency: CBDC being fully backed by central bank reserves, and DUSD representing a tokenized deposit with some susceptibility to counterparty risk. The user interface should enable individuals to easily manage both a DUSD and a CBDC account, facilitating smooth transitions between these two currency types.

3.1 Licensed financial intermediaries

The licensed intermediaries provide tokenized deposits on layer 1. Whether these tokenized deposits can be held by any (pseudonymous) blockchain user is a design choice that depends, amongst other factors, on regulatory considerations. This aspect carries implications for their usability within DeFi protocols. However, delving into this matter is outside the scope of this paper.¹⁴

Figure 3a presents a representative balance sheet of a recently established intermediary, assuming it possesses an initial reserve balance with the central bank. If there is a demand for the intermediary’s tokenized deposits, the balance sheet expands, as demonstrated in Fig. 3b. For illustrative purposes, the intermediary receives ETH in exchange for newly minted DUSD, which is priced at $1\frac{DUSD}{ETH}$.

Fig. 3

Balance sheet of newly established intermediary

Regarding the custody of the tokenized deposits, there are two potential options. The first option is for intermediaries to handle custody, which can be more suitable for less tech-savvy individuals and offers a user experience akin to traditional bank deposits. The second option is for individuals to maintain custody of their assets. In Fig. 2, this is represented by the

account type.

The intermediaries have obtained licenses to intermediate CBDC to the general public within a rollup architecture. Individuals who desire to hold CBDC must engage with the intermediary and undergo Know-Your-Customer (KYC) and Anti-Money Laundering (AML) verifications. Upon successful completion, they can establish an L2 CBDC account with the intermediary. These accounts are necessary for transferring CBDC or conducting withdrawals to Layer 1. Further technical details regarding L2 accounts are discussed in Sect. 4.2.

Fig. 4

Users exchange DUSD for CBDC

Once users successfully complete the required checks, they gain permission to exchange the tokenized deposits issued by the intermediary on L1 for L2 CBDC at par. The specific technical concepts related to this process are explained in greater detail in Sect. 3.2. To comprehend the economic implications, I provide a representative balance sheet for both the intermediary and the central bank in Fig. 4a.

For illustrative purposes, assume that there exist three intermediaries offering tokenized deposits. For each, users exchange 40 DUSD for CBDC. Consequently, the intermediary records a CBDC liability of $40 on its balance sheet and credits the users’ L2 accounts with $40 worth of CBDC. These L2 accounts are managed within the intermediaries’ L2 state trees, as depicted in Fig. 5 for intermediary 1.

However, intermediaries cannot independently create CBDC and are legally obligated to maintain a corresponding CBDC asset position with the central bank. Therefore, they request the central bank to credit $40 of CBDC to their L2 CBDC account. The central bank has several options to address this request. On one hand, it could mint new CBDC. But this would result in the central bank losing control over the size of its balance sheet.

Instead, when intermediaries request new CBDC from the central bank, they are required to provide another form of central bank money. In the example depicted in Fig. 4b, the intermediary has a reserve account that the central bank debits by $40. Simultaneously, the intermediary establishes a CBDC asset position of the same value. Considering that there are three intermediaries, the central bank deducts a total of $120 from the reserve accounts and credits $120 to the CBDC accounts. This ensures that the central bank’s balance sheet size is unaffected and only its composition changes. The balances of the intermediaries are stored within the central bank’s L2 state tree, as shown in Fig. 5.

Fig. 5

Layer 2 state trees of central bank and intermediary 1

Moreover, you may have observed that the intermediary’s liability position in DUSD has not decreased, as it would be the case for deposits if deposit holders crowded out to a CBDC. Instead, the intermediary adds a new asset position in DUSD equivalent to the amount of CBDC intermediated. The reasons behind this lie in the technical design, which will be discussed in Sect. 3.2.

Note that it is not essential for the economic functioning of this design that CBDC issued by the intermediaries is backed by this novel form of central bank money. Alternatively, it could be backed by reserves, which would align with the concept of granting stablecoin providers access to the Federal Reserve’s master accounts. However, there are other rationales for choosing this approach. For instance, the central bank might decide to implement different monetary policies for the two types of monies, making the differentiation between account types relevant. Furthermore, operating an L2 system itself and publishing the state root of the L2 state tree on the base chain enables other blockchain-related functionalities, such as intermediaries cryptographically proving their solvency without revealing their assets.

Lastly, I address two additional considerations. The mechanism described here requires the central bank to adjust the composition of its balance sheet for each exchange of DUSD for CBDC. However, this approach may not be optimal. Alternatively, intermediaries could acquire CBDC in advance, allowing the central bank to make only occasional adjustments to the balance sheet. Finally, if intermediaries lack sufficient reserves to obtain new CBDC, they would need to rely on conventional instruments such as interbank lending markets or seek assistance through the central bank’s discount window.

3.2 Users deposit and acquire CBDC

I now describe the process of acquiring CBDC when owning a layer 1 asset in more detail. In this example, Carol possesses some ETH and wants to convert it into CBDC. However, she cannot perform this conversion directly and must involve a licensed intermediary. To initiate the process, Carol purchases DUSD from intermediary 1 on a L1 exchange. This is illustrated in Figs. 6a and 6b where Carol exchanges 5 ETH for 5 DUSD at a price of $1\frac{DUSD}{ETH}$. When Carol executes the exchange, the intermediary mints new DUSD, resulting in the expansion of the intermediary’s balance sheet.¹⁵

In order for Carol to convert her DUSD into CBDC, she must fulfill the intermediary’s Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements. Once her validation is successfully completed, Carol becomes eligible to create a L2 CBDC account. Additionally, the intermediary adds Carol’s layer 1 address to the whitelist within the L1 RSC. This whitelist inclusion enables Carol to transfer funds between the base chain and layer 2 through deposits and withdrawals.¹⁶

Fig. 6

User acquires CBDC

The technical details are illustrated in Fig. 7. ❶ After receiving DUSD, Carol creates a transaction with her layer 1 account that addresses the RSC of intermediary 1. It contains the amount of DUSD deposited and the L2 address to be credited. She propagates the transaction to the layer 1 validators who will eventually include it in a block. Note that Carol is only able to perform this action due to her prior whitelisting in the RSC by the intermediary.

After the transaction is successfully included in the blockchain, the DUSD is transferred to the intermediary’s rollup smart contract account (RSCA). Consequently, it appears as an asset on the intermediary’s balance sheet, as depicted in Fig. 6c. The intermediary holds the DUSD within the RSCA to facilitate any potential withdrawals. This will be further discussed in Sect. 3.5.

❷ To track deposit occurrences, both the intermediary and the central bank monitor the blockchain. After observing Carol’s transaction, the central bank proceeds to debit the intermediary’s reserve account while crediting the CBDC account. It simultaneously updates the L2 state tree to reflect the increased balance of intermediary 1. Concurrently, the intermediary credits Carol’s L2 account with $5 CBDC and likewise updates its L2 state tree accordingly.

Fig. 7

Deposit on layer 1

❸ Subsequently, the central bank and the intermediary create a transaction on layer 1 that addresses the RSC. Within the data field, the transaction includes the old and new rollup state roots, along with a proof validating the state change and the validity of Carol’s deposit. ❹ These transactions are then propagated to the L1 validators and are eventually included into a block. The RSC verifies the validity of the state change and proceeds to update the state root, reflecting the updated state tree that now includes Carol’s deposit.

It is crucial to emphasize that if the intermediary fails to update Carol’s L2 CBDC balance, she would not be able to use or withdraw the funds, since they are effectively locked within the RSCA. To avoid this risk, a pending transaction state can be implemented, enabling the cancellation of the deposit as long as the state tree has not been updated on the base chain. Moreover, I here only show one deposit for illustrative purposes. However, in a practical implementation, deposits would be accumulated to make the system more efficient.

Lastly, it is not essential for the system’s functioning that the central bank monitors the blockchain itself. Instead, the intermediaries can relay information on the aggregate deposit amounts to the central bank. While this approach involves a trust assumption, it might be deemed reasonable due to the intermediaries’ licensing.

3.3 Intra-intermediary CBDC transfers

In the proposed design, similar to the traditional banking system, there is a significant conceptual difference depending on whether a transfer occurs within or between intermediaries. I first explore the case of an intra-intermediary transfer from Dan to Bob involving $5 CBDC, which is illustrated in Fig. 8. In this scenario, the central bank’s involvement is not required since the intermediary’s overall CBDC balances remain unchanged.

Fig. 8

CBDC transactions

❶ To initiate a CBDC transfer, Dan sends a message to the intermediary using his L2 account. It includes the amount to be transferred and the recipient’s account details. The intermediary verifies the message’s validity and sends an instant confirmation to Dan. The confirmation guarantees that the transaction will be included in L1. This introduces a trust assumption since the transaction is not yet included in L1, but it provides what I refer to as “trusted instant finality”.¹⁷ Fast finality is essential for many real-world applications.

❷ The intermediary proceeds to update the layer 2 state tree and calculates the new state root. Subsequently, it creates an L1 transaction addressed to the RSC that includes (i) the old state root, (ii) the new state root, (iii) Dan’s transfer in compressed form and (iv) a zero-knowledge proof validating Dan’s transfer. ❸ The L1 transaction is propagated to the L1 network and eventually included in a block. The RSC verifies the validity of the state change and upon successful validation, updates the rollup state on the blockchain.

To illustrate how the system works in the real world, consider an example where Dan purchases groceries from Bob’s shop worth $5. The process could be as follows: (a) Dan opens the CBDC application on his phone and scans a QR code that represents Bob’s address and the amount to be paid. (b) The application creates and authenticates a message containing the transaction information and sends it to the intermediary. (c) The intermediary checks the validity of the transaction. If it is valid, the intermediary sends a confirmation to both the sender (Dan) and the receiver (Bob). (d) After confirmation, the transfer is completed and recorded in the rollup state tree. With some time delay, the transaction is included in a transaction batch on layer 1.

3.4 Inter-intermediary CBDC transfers

CBDC transfers between intermediaries are more complex than intra-intermediary transfers. Economically, they are similar to inter-bank transfers in the traditional banking system. The design discussed here involves the exchange of centralized L2 messages among the various entities involved. While this introduces a trust assumption, the system is simpler and more efficient. Also more blockchain-native approaches could be considered, but this falls outside the scope of this paper.¹⁸

Fig. 9

Transfer between intermediaries—state trees

To illustrate an inter-intermediary transfer, suppose that Eve and Frank hold $30 and $10 of CBDC with intermediary 2, as shown in Fig. 9a. Eve decides to send $5 of CBDC to Dan, who has an account with intermediary 1. To initiate the transfer, Eve sends a message to intermediary 2 containing the transfer instruction. Subsequently, intermediary 2 debits $5 from Eve’s account and forwards the transfer message to intermediary 1 and the central bank. Intermediary 1 then credits Dan’s account with $5 of CBDC. The central bank adjusts the accounts of both intermediaries by debiting $5 of CBDC from intermediary 2 and crediting the same amount to intermediary 1. Throughout this process, all three parties adjust their respective state trees and eventually update the state root in the RSC on the base chain. The RSC can verify the validity of the state updates since Eve signed the transfer instruction.

In contrast to inter-bank transfers in the traditional banking system, the proposed design introduces an additional challenge. This challenge pertains to the DUSD holdings within the intermediary’s RSCA, which matches the total value of intermediated CBDC. If CBDC transfers occur on layer 2, the DUSD holdings within the RSCA will no longer align with the intermediated CBDC amount. To address this issue, I introduce a centralized mechanism, although it is worth noting that a decentralized implementation is also theoretically possible.

The mechanism works as follows. Simultaneously to updating the rollup state root on layer 1, intermediary 2 sends $5 DUSD from its RSCA to its tokenized deposit smart contract and burns these tokens which results in a shortened balance sheet. At this point, intermediary 2 has a total of $35 CBDC outstanding in the rollup whereas the RSCA holds $35 DUSD as well. In contrast, when intermediary 1 receives the transfer message, its L2 CBDC account with the central bank shows a balance of $50, but only $45 DUSD is locked in its RSCA. To reconcile this discrepancy, intermediary 1 mints $5 of DUSD and transfers it to the RSCA, thereby expanding its balance sheet. This is visually depicted in Fig. 10.

Fig. 10

Transfer and effect on DUSD holdings

3.5 Withdrawal to L1

To illustrate an example of a withdrawal, suppose Dan wishes to convert $10 of L2 CBDC into $10 of L1 DUSD. The technical details of this process are illustrated in Fig. 11. ❶ Dan initiates the withdrawal procedure by submitting a request from his L2 account to the intermediary. This request includes the withdrawal amount and specifies the L1 address where the funds should be transferred on the base chain.

Fig. 11

CBDC withdrawal

❷ The intermediary proceeds to update the L2 state tree by deducting $10 of CBDC from Dan’s L2 account. In addition, it creates two L1 transactions. The first transaction triggers the RSC to update its state root including the adjusted balances, as seen previously. The second transaction triggers the RSC to transfer 10 DUSD from the RSCA to Dan’s L1 account. Furthermore, the intermediary notifies the central bank of the withdrawal, prompting the debiting of $10 from the intermediary’s CBDC account. The central bank then updates its own L2 state tree and creates a transaction to update the rollup state on layer 1 accordingly.

❸ All transactions are propagated to the layer 1 validators who include them in a block. The RSC verifies the transactions’ validity and executes them, i.e., the state root is updated and 10 DUSD are transferred to Dan’s L1 account. It is worth noting that there might be a time delay between the submission of the withdrawal request on L2 and the actual settlement of the transfer on layer 1.

Figure 12 illustrates the balance sheets associated with this withdrawal request. Since Dan withdraws $10 of CBDC, the intermediary’s CBDC position decreases by $10. The DUSD asset position is also reduced by $10 as 10 DUSD is transferred from the RSCA to Dan’s address. Note that even after the withdrawal, the total intermediated CBDC amount of $40 remains fully backed by the DUSD holdings in the RSCA. Furthermore, the central bank debits the intermediary’s CBDC account and credits its reserve account with $10.¹⁹ Finally, Dan’s CBDC balance is reduced by $10, while his DUSD position increases by the same amount.

Fig. 12

CBDC withdrawal balance sheets

3.6 Forced withdrawals to L1

In what I discussed above, a withdrawal required the cooperation of the intermediary because it triggered the payout on L1. However, blockchain technology enables withdrawals to L1 under any circumstance, even if intermediaries censor a regular withdrawal request. This requires a more complex process in which a withdrawal is not immediately possible, but only executed after a time lock period. I discuss conceptually how this works and illustrate an example in Fig. 13. Whether this feature is implemented or not is a design choice.

Fig. 13

Forced withdrawals

Suppose Dan sends a withdrawal request on L2 as described in Sect. 3.5. The intermediary has not served this withdrawal request which leads Dan to use the forced withdrawal feature. ❶ To do so, he creates a transaction on L1 addressing the RSC. The transaction’s data field contains (a) code that calls the forced withdrawal function, (b) the address of the account to be credited on L1 and (c) a proof that Dan is the owner of an account on L2 with a corresponding balance. To understand how the proof works, remember that the RSC on L1 stores the state root of the L2 state tree that is built from all accounts and balances holding CBDC on L2. Dan can prove to the smart contract that (i) the state tree corresponding to the current state root contains an account on L2 with a respective balance and (ii) he is the rightful owner of this account.

To gain a better understanding of how this works, suppose the account on L2 is secured by private-public key encryption and Dan holds the private key corresponding to the public key that represents his account address. In this case, Dan needs to prove two things to the RSC: (i) there exists a public key (i.e., account address) in the current L2 state tree (i.e., proof-of-inclusion) and (ii) he holds the private key to this public key. To verify Dan’s proof, the RSC uses the stored state root and performs a standard private-public key verification.

Next, Dan propagates the transaction to the L1 network, where validators eventually include it in a block. However, the withdrawal cannot be processed immediately. To understand why, suppose for now that the intermediary sends a new transaction batch to L1 and updates the state root in each block. When Dan creates his transaction, the proof he provides corresponds to the last state root he is aware of. However, if in the same block there is also a state update by the intermediary, Dan’s proof becomes invalid because the smart contract now stores a new state root. On the other hand, if Dan could use an old state root to authorize his withdrawal, he could cheat using his assets on L2 and then use the old state root with the old, higher balance to withdraw a higher amount on L1. Thus, additional safety measures are necessary.

❷ Instead of immediately processing the withdrawal, Dan’s transaction triggers the RSC to initiate a time lock period. During this period, the intermediary can still serve Dan’s withdrawal request and send state updates to the RSC. If the intermediary meets the request within the time lock period, the time lock is canceled, and the protocol continues to operate normally. ❸ If the withdrawal request is not met during the time lock period, Dan creates a new transaction addressing the RSC. The transaction contains a freeze instruction in its data field, which freezes the RSC such that the intermediary can no longer update the state root stored by the RSC. ❹ Dan then creates a final transaction that triggers the payout on L1. Since the state root is no longer updated, he can provide a proper proof that corresponds to the correct state root.

This mechanism is always feasible because intermediaries ensure the backing of L2 CBDC holdings with corresponding DUSD balances in the RSC account. Additionally, since the central bank validates the blockchain, it would also become aware of any forced withdrawal and can adjust the balance of the intermediary’s CBDC account accordingly.

4 Extensions

There are several additional noteworthy features that have yet to be addressed. These include central bank accounts for all, account types, privacy considerations, offline payments, and the integration of decentralized finance applications. Each of these topics will be discussed below.

4.1 Central bank accounts for all

In the intermediated CBDC design detailed in Sect. 3, users lack the ability to directly interact with the central bank. This design aims to replicate the existing private-public partnership model prevalent in the financial system. However, the central bank could allow users to hold CBDC directly with the central bank within the central bank’s rollup.

It remains reasonable to propose that users could exclusively obtain L2 CBDC in exchange for tokenized deposits rather than any arbitrary layer 1 asset. From an economic perspective, this raises a noteworthy concern. For instance, envision a scenario where an intermediary generates an arbitrary, unbacked amount of tokenized deposits that users acquire in exchange for other crypto assets. If the central bank credits CBDC on layer 2 upon receiving a transfer of DUSD on layer 1, it would effectively create new central bank money and expand its balance sheet. Consequently, this could lead to the central bank losing control over the size of its balance sheet, a scenario that may not align with the central bank’s objectives.²⁰ However, if intermediaries are licensed and subject to regulatory oversight, this concern might be negligible.

4.2 L2 accounts and account abstraction

Accounts and access to assets on a blockchain normally relies on private-public key encryption. However, this type of encryption has some drawbacks. If a user loses the private key, there is no way to restore access to the account and the assets within. Moreover, if malicious actors manage to steal a private key, they gain access to the account’s assets.

Since this standard is fundamental to the protocol of a blockchain, it is challenging to modify these rules. In contrast, layer 2 accounts, which are part of this proposal, offer much greater flexibility in their design. This flexibility is often associated with the concept of account abstraction (see e.g., Niset, 2022; Buterin et al., 2021; Nair and Song, 2023). In this approach, a user’s account is transformed into a smart contract capable of defining its own execution and authorization logic. This opens up the possibility of using alternative transaction authorization methods instead of relying solely on private-public key cryptography and enables various new features.

For instance, a user can specify that in the event of private key loss, one or several trusted third parties can restore access to the account. Additionally, it enables the implementation of other functionalities such as whitelisting specific addresses or setting limits on daily transfers, which can be directly embedded within the logic of the account.

An alternative authorization logic for an L2 account, instead of relying solely on private-public key encryption, could be to associate it with an underlying account that adheres to KYC requirements. The government could determine which types of underlying accounts are permissible, such as a government-issued digital identity, a regulated bank account, or an account linked to a registered phone number. By employing cryptographic techniques, a pseudonymous L2 account can be generated from the underlying account. The pseudonym serves as the account address that is used to send and receive transfers on layer 2. To validate a transaction, a user must provide proof of access to the underlying account by utilizing the cryptographic link between the underlying and the L2 account. What is more, this approach simplifies the recovery process of the L2 account through the underlying account and allows for a wider range of privacy solutions, as described in Sect. 4.3 below.

4.3 Privacy

When it comes to privacy, it makes sense to distinguish between network privacy and privacy to the intermediary or central bank. In terms of network privacy, users will share information in a similar manner as they currently do when engaging on a permissionless blockchain. Because users are pseudonymous, it is not easy to determine their real identities, although it is theoretically possible. This holds true even when users possess CBDC. The settlement of L2 CBDC transactions within the L1 rollup smart contract maintains pseudonymity rather than revealing real identities.

Also the residual risk of private identity exposure through L2 CBDC transfers can be further reduced. Rather than publishing individual transactions on L1, the intermediary can only propagate state changes, thereby obfuscating who transacted with whom. Alternatively, the risk can be completely eliminated by refraining from settling transaction data on L1 altogether and exclusively updating the state root, as discussed in Sect. 4.6. However, implementing this approach would prevent users from computing the L2 state trees and complicate forced withdrawals.

When it comes to identity revelation with respect to intermediaries and the central bank, there are several options to consider. The baseline approach entails users registering with their actual identities, allowing intermediaries to establish a mapping between each L2 account and a specific identity.

Another option involves designing a system where intermediaries are unable to link a pseudonym to a real identity. Assuming that some registration process is still required, in this setup users have to be registered elsewhere, such as through a government e-ID. By utilizing a zero-knowledge proof, the user can demonstrate possession of the government e-ID and open an L2 CBDC account with the intermediary without disclosing the real identity. Furthermore, privacy can be conditioned on different parameters implemented in the system. For example, users who adhere to transfer limits are allowed to remain anonymous.

4.4 Offline payments

For the sake of payment system resiliency, the ability to facilitate offline payments would be desirable. In the L2 architecture, one potential solution is to leverage trusted execution environments (TEEs) present in smart phones and other digital devices to address the issue of double spending (see e.g., Christodorescu et al., 2020, Visa). TEEs offer a secure environment for storing sensitive material, including keys, and are exceedingly difficult to compromise without relying on the hardware producer (see e.g., Wu, 2016).

To perform an offline transfer in the event of a network outage, one approach is to establish a connection between the payer and payee devices using Near Field Technology (NFT). In this scenario, the payer utilizes a TEE-protected wallet to create and sign the transaction, including a unique nonce to prevent double spending. The TEE ensures the security and integrity of the signature and the nonce, making it impossible to modify. The payer then transmits the transaction to the payee’s device who stores the transaction information. Once the network connectivity is restored, the devices can transmit the transaction details to the central bank, who validates the transaction and adjusts the states accordingly.

It is important to note that in these offline transaction solutions, the wallet and the associated funds need to be stored locally on the user’s device. However, this approach presents potential challenges, particularly in terms of the risk of loss or damage to the device (see e.g., Kahn, Oordt and Zhu, 2021; Minwalla et al., 2023; Polaris, 2023).

4.5 DeFi

The proposed design is limited to handling deposits, withdrawals, and basic payment transactions. However, it is technically feasible to expand the design to incorporate additional use cases. These could include features like programmable money to facilitate self-executing payments or enable interactions and transactions among Internet of Things devices. Additionally, it could support decentralized finance (DeFi) applications such as borrowing and lending directly with central bank money. To achieve this, it is necessary to enable smart contract compatibility within the layer 2 environment.

As the intermediaries are subject to regulation, the government can restrict the types of smart contracts and DeFi applications it permits to be operated on the CBDC L2 environment. Consequently, it can establish requirements such as adherence to auditing standards or compliance with specific regulations for the implementation of these protocols.

Implementing DeFi applications on a rollup would be relatively straightforward, given that it is already established by existing rollups. However, composability could suffer if each intermediary offers DeFi applications on its own rollup. Enhancing efficiency and composability could be facilitated by having DeFi applications on a unified CBDC rollup, potentially provided by the central bank.

4.6 Validium

A drawback of the previously discussed rollup design is that all transaction data is posted on the underlying chain, which has implications for both privacy and the cost of posting data on layer 1. As an alternative approach, the intermediaries could opt for a validium design, wherein transaction data is not made available on the underlying chain. Instead, only zero-knowledge proofs accompanied by state updates would be posted. As a consequence, actors who track the underlying blockchain are unable to deduce any information about the users who transfer CBDC on layer 2. This, in turn, ensures the privacy of CBDC users with respect to the network.

However, this design choice comes with certain trade-offs. For instance, it becomes infeasible for an observer of the underlying blockchain to reconstruct the layer 2 state tree which makes forced withdrawals challenging, unless the intermediaries provide the necessary data off-chain.

4.7 Scalability

For simplicity, the proposal outlined in Sect. 3 only illustrates individual transactions. However, in practice, the goal is to accumulate multiple transactions and transmit them as a batch to L1. As explained in Sect. 2, there are significant cost advantages to batching transactions on L2 and then settling them collectively on L1, compared to executing each transaction individually on layer 1.²¹ For example, on the Ethereum network, executing a transaction through layer 2 is currently much cheaper than on layer 1 (see https://l2fees.info/). Furthermore, transaction batches can be posted infrequently to reduce costs and accumulate more transactions over time.

Additionally, efforts are underway in the Ethereum community to lower the costs associated with rollups settling transactions on layer 1. Proto-Danksharding, recently introduced via EIP-4844,²² enables the posting of data on the blockchain through blobs, which is cheaper compared to posting data through calldata. The total number of blobs that can be included per block is limited and a blob fee market exists. Additionally, blob data is pruned after approximately 2 weeks to maintain reasonable hardware requirements for validators. Furthermore, the Ethereum network aims to further decrease costs for rollups through concepts such as Danksharding.²³

4.8 Economic considerations

In terms of economic considerations, I would like to address two topics: gas fees and disintermediation risks. First, both intermediaries and the central bank (if it operates its own rollup) are required to pay transaction fees on layer 1 to settle the layer 2 transactions. They have the option to either pass these costs on to consumers or subsidize the payment system through alternative revenues. How this is implemented is determined by the payment system providers and other involved parties, similar to current practices in traditional payment systems.

Second, there is a common concern among economists regarding the potential disruption to banks a CBDC might trigger.²⁴ This raises questions about how intermediaries might be affected in my CBDC proposal. There are two cases to consider here: whether the CBDC described in the proposal crowds out traditional non-blockchain bank deposits and the effect it has on tokenized deposits on the blockchain.

Overall, there is a possibility that a CBDC could prompt some individuals to shift from deposits to CBDC, potentially reducing credit availability. This effect might be more significant during times of financial turmoil, when both traditional and tokenized deposits (DUSD) could shift to CBDC. However, since my proposal centers around an intermediated CBDC, any negative impacts could be mitigated because users would still interact with a financial intermediary.

When considering the impact on traditional deposits, a central bank may contemplate the idea of issuing a CBDC within a blockchain framework only if broader adoption and the prevalence of DeFi applications are already evident. In this scenario, banks might already be facing growing competition from these innovative technologies, potentially overshadowing any additional competition posed by the CBDC.

Furthermore, the proposed design introduces a novel business model for financial intermediaries within permissionless blockchains. They have the capability to issue tokenized deposits and serve as providers of intermediated CBDC. Consequently, this presents potential new opportunities for financial intermediaries.

Lastly, it is conceivable that the disruption to banks may be heterogeneous. Given the technological expertise required to operate these systems, it is possible that initially, only a few specialized entities would offer tokenized deposits and intermediated CBDC.

5 Discussion and conclusion

In this paper, I delve into the implementation of a Central Bank Digital Currency (CBDC) within a permissionless blockchain environment, employing a layer 2 rollup design. I do not claim that issuing a CBDC on a permissionless blockchain is unconditionally the best approach to issue a CBDC. Instead, I argue that my proposal offers a solution that could align with a central bank’s objectives if implementing a CBDC within a permissionless blockchain context is desired.

A straightforward method for implementing a CBDC on the blockchain involves creating a stablecoin-like CBDC directly on a layer 1 blockchain. This could be achieved, for instance, by utilizing an ERC-20 token contract to ensure compatibility and composability. However, this approach also carries several drawbacks when compared to the proposal of a layer 2 rollup CBDC. In a direct implementation, the CBDC would be subject to the rules of the underlying blockchain network, limiting the central bank’s flexibility and agility. For instance, the blockchain network’s private-public key authentication mechanism used for user custody could be improved upon. Furthermore, the potential for users to send funds to the wrong addresses would be a significant problem if a CBDC was implemented directly on the layer 1 blockchain. For public money with a potential for mass adoption, especially for non-tech-savvy users, this would be a serious concern. However, these issues can be mitigated with a layer 2 design, where a different account type with a distinct authentication mechanism can be established. Furthermore, a rollup design provides greater flexibility for privacy or offline payments than a direct implementation.

Compared to a layer 1 solution, a CBDC implemented on a rollup offers what I refer to as trusted instant finality. On layer 1, users rely on validators to include their transactions in a block and it takes some time to be confirmed. This process is not optimal for everyday use cases that necessitate prompt confirmations. In contrast, with a CBDC rollup, users submit their transactions to the intermediaries, which can provide an instant confirmation. During the period before the transaction is included in a transaction batch on the blockchain, the user places trust in the intermediaries that the transaction will be included.

Additionally, a layer 2 rollup design offers the potential to always withdraw funds to the underlying layer through “forced withdrawals”. Assets that exist in non-decentralized systems can theoretically be frozen, except for cash. Whether forced withdrawals are permitted would be a design choice. Moreover, ensuring compliance with KYC and AML requirements becomes straightforward, as the rollup can be designed as a permissioned system. Lastly, transaction costs per transaction are lower in a rollup design compared to a direct implementation, as transactions can be settled in batches on the underlying blockchain.

Furthermore, there are compelling reasons to consider providing a CBDC on a blockchain. The potential programmability of a CBDC enables a wide range of intriguing use cases and the inherent cryptographic principles of blockchains allows for applications such as proofs of solvency without disclosing the precise asset positions. Furthermore, the necessary tools for building such an infrastructure have already been developed by the blockchain research community in recent years, eliminating the need to create an entirely new and complex system from scratch.

There are also caveats to consider regarding my proposal. Even though the central bank manages a layer 2, its operations still rely on the proper functioning of the underlying blockchain for crucial aspects such as inclusion of the transaction batches or updates of the state root. In the unlikely event that the consensus mechanism of the underlying blockchain fails, the intermediaries could “close down” the smart contract on layer 1 while maintaining control over the layer 2 state tree. In this scenario, withdrawals could still be facilitated off-chain by burning CBDC and providing an alternative form of government money, such as cash or reserves. Similarly, if the underlying chain were to experience a fork, the central bank would have the discretion to determine which chain it continues to operate on and could opt to halt operations on the other chain.

Furthermore, ensuring the security of the rollup smart contract on layer 1 is crucial to prevent any potential loss or theft of funds. Therefore, conducting thorough audits of the smart contracts is of utmost importance. Additionally, employing multiple externally owned accounts to protect the smart contracts is recommended. Moreover, it is essential to recognize that in the retail CBDC design, the central bank would serve as an onboarding institution to the world of cryptocurrencies. Users would have the ability to deposit funds on layer 2 and withdraw them to the underlying layer 1. However, whether or not this functionality is permitted is a design decision to be made by the central bank based on its objectives. Lastly, the central bank needs to hold a certain amount of native layer 1 currency to cover transaction fees when posting transactions on the base chain. The transaction fees could be either subsidized by the central bank or imposed on the users themselves, depending on policy considerations.

To conclude, I have explored in this paper how a CBDC can be implemented in a rollup layer 2 architecture. I discussed the technical details as well as the benefits and limitations of this design. Moving forward, an intriguing next step would involve creating a proof-of-concept to validate the proposed design and develop a prototype. This can be achieved by making specific design choices and leveraging existing infrastructure, which would facilitate the practical implementation of the central bank digital currency.