A Digital Currency Architecture for Privacy and Owner-Custodianship

We propose an approach to digital currency that would allow people without banking relationships to transact electronically and privately, including both internet purchases and point-of-sale purchases that are required to be cashless. Our proposal introduces a government-backed, privately-operated digital currency infrastructure to ensure that every transaction is registered by a bank or money services business, and it relies upon non-custodial wallets backed by privacy-enhancing technology such as blind signatures or zero-knowledge proofs to ensure that transaction counterparties are not revealed. We also propose an approach to digital currency that would allow for more efficient and transparent clearing, settlement, and management of systemic risk. We argue that our system can preserve the salient features of cash, including privacy, owner-custodianship, fungibility, and accessibility, while also preserving fractional reserve banking and the existing two-tiered banking system. We also show that it is possible to introduce regulation of digital currency transactions involving non-custodial wallets while still allowing non-custodial wallets that protect the privacy of end-users.


Introduction
IMF research by Tommaso Mancini-Griffoli and others identified a tension in the potential design features of a central bank digital currency (CBDC) [1], which we recast and sharpen here as a trilemma involving scalability, control, and privacy, of which not all three can be fully achieved at the same time in the context of private ownership and use of money. Bank accounts have near-perfect scalability and control at the expense of privacy. Cash has privacy and a measure of control that limits its scalability. It is difficult to imagine a system with perfect control because it would result in real ownership being meaningless and because there will always be some malfeasance in use. The same is true with perfect privacy because there will always be software bugs, timing attacks, and limits to operational security outside the payment mechanism, whereas perfect scalability would not offer any benefit for transaction sizes that are unsafe to automate.
Mancini-Griffoli and his co-authors argue that anonymity is a salient feature of cash, that privacy of transactions is essential, and that the specific design features of CBDC could have a significant impact on financial integrity [1]. Our proposal provides a solution with the flexibility to accommodate the widely-acknowledged requirements and goals of CBDC and which is more akin to cash. Specifically, it delivers a measure of control by restricting peer-to-peer transactions. However, it does not offer the near-total degree of control that seems to be taken as a requirement in some designs [2], and instead its retail applications are exposed to a corresponding limitation to their scalability, but not one that cannot be overcome by introducing additional control, in limited contexts, outside the operating plane of the ledger.
Our system provides a model for modulating the degree of control, allowing government actors to finely tune their choice of trade-offs in the trilemma. For example, it might require that certain (or all) businesses cannot accept payments larger than a certain size without collecting or reporting additional information that limits privacy, or it might require that some individuals or non-financial businesses have a larger or smaller cap on the volume of their withdrawals into non-custodial wallets. To draw an In the context of CBDC, non-custodial wallets offer a direct economic relationship, but not a direct technical relationship, between retail CBDC users and the central bank. By this we mean that CBDC tokens would constitute a liability of the central bank. We do not mean to suggest that retail CBDC users would have accounts with the central bank or that they would interface with the central bank directly.
Our proposal frames CBDC as a distinct financial instrument but one that nonetheless shares many features with cash, including being fully collateralised and not providing for the ability to lend or rehypothecate. Moreover, we are not proposing a subordinate role for bank notes, nor for bank deposits. On the contrary, we understand all three instruments to have merit and value to households and firms within an economy and can be used to complement one another and increase the overall welfare of individuals and firms through the adoption of CBDC [13]. An example of the inherent difficulties within proposals that argue for the abolition of cash is that the increase in its use is predominantly situated within lower socioeconomic segments of a community, and using CBDC to drive out cash would adversely impact those households and firms.

Privacy by Design
Our starting point is that retail CBDC users should have the right to privacy from the state. Law enforcement can ask custodians to carry out legitimate law-enforcement capabilities. However, it is too easy to assume that all of the information about a transaction should be available to law enforcement (or others) for their perusal upon request, and it has become an accepted practice for governments to leverage relationships between individuals and private-sector businesses to extract such information about their transactions.
Fortunately, it is possible to regulate financial transactions without collecting data that could be used to profile the behaviour of individual persons. The architectural features of our proposal ensure privacy for its transactions; our design seeks to be private by design and by default. We do not envision privacy as something that can be bolted on to a fully-traceable system (for example, with "anonymity vouchers" [14,15]) or that can depend upon the security or protection offered by some third party. Conversely, the features that apply on a case-by-case basis, such as limits to the size of withdrawals to anonymous destinations or limits to the size of remittances into accounts from private sources, that are external to the core architecture and can be managed by policy.
Were a CBDC designed not to provide certain qualities of privacy, some users would remain avidly dedicated to the use of cash [16]. Our proposal, described in Section 2, disrupts this notion and shows how a measure of true anonymity can be maintained. A CBDC could support replacing private sector assets into risk free assets to address the safe asset shortage, particularly given that although bank deposits are broadly insured up to some amount, they continue to exhibit credit and residual liquidity risks. Moreover, there is demand for semi-anonymous means of payment [17], as well as for a variety of instruments capable of being used for payment, and due to heterogeneity in the preferences of households the use of a CBDC has immediate social value [13], both of which are direct consequences of our proposal.
In May 2020, Yves Mersch, Vice-Chair of the Supervisory Board and Member of the Executive Board of the European Central Bank, acknowledged the importance and significance of preserving privacy, suggesting that an attempt to reduce the privacy of payments would "inevitably raise social, political and legal issues" [18]. This is important for three reasons. First, no digital currency, token-based or otherwise, would guarantee complete anonymity: consider the potential for timing attacks, software bugs, and other limitations to operational security. Even bank notes do not achieve perfect anonymity: their serial numbers offer a possibility wherein individual notes can be tracked or marked, although to our knowledge such methods for surveillance are imperfect and seldom used. Nevertheless, we must consider the implications of systems that attempt to force users into payment systems with different anonymity properties and trade-offs in general. Second, we have an opportunity to demonstrate a system that can achieve and deliver a measure of true privacy, in contrast to problematic assumptions such as the idea that the system must accommodate exceptional access or that privacy is not the starting point but rather something that should be protected by an authority [19]. Such a system, an example of which we describe in Section 2, would constitute an improvement over both the various government-backed digital currency systems that have been proposed to date (which are institutionally supportable but not private) as well as the various "outside solutions" involving permissionless ledgers that are used in cryptocurrencies such as Zcash and Monero (which are private but not institutionally supportable). Third, it demonstrates that privacy is sufficiently important that we should not rush headlong into creating infrastructure, or allowing infrastructure to be created, that might forcibly undermine it. In contrast to data protection, which is about preventing unauthorised use of data following its collection, privacy is about preventing individuals (and in some cases businesses) from revealing information about their (legitimate) habits and behaviours in the first instance. Data protection is no substitute for privacy by design [9]. As an architectural property, therefore, privacy is a fundamental design feature that cannot be "granted" or "guaranteed" by some authority.
In principle, it should be possible to accommodate privacy by design with a regulatory approach that intrinsically protects the rights of retail CBDC users. 2 To avoid infringing upon essential privacy and human rights, specific measures must be taken to ensure: ∎ that non-custodial wallets must not be expected to carry persistent identifying information such as a unique identifier or address that would be associated with multiple transactions, ∎ that non-custodial wallets must not be expected to reveal information, including keys or addresses associated with previous or subsequent transactions, that can be used to identify their bearers, owners, or sources of funds, ∎ that the obligation to identify the counterparties to a transaction can only be imposed at the time of a transaction, and ∎ that the process for providing information to the requesting banks or money services businesses for the purposes of recordkeeping or reporting must not involve the non-custodial wallet itself and would be carried out only with the consent of both counterparties.
It can only be possible for ordinary users of non-custodial wallets to have confidence that their routine activities will not be profiled if the relevant thresholds are sufficiently high and circumstances are sufficiently rare for which counterparty information is requested for recordkeeping or reporting. Such requests must involve the explicit consent of the owner or bearer of the digital tokens on each separate occasion, must not be routine for ordinary persons carrying out ordinary activities, and must not require a non-custodial wallet or other personal device to reveal any information identifying its owner or bearer.

CBDC and the Banking Sector
In the same statement mentioned in Section 1.2, Mersch also stressed the importance of the role of the private sector in operating a network for payments: isintermediation would be economically inefficient and legally untenable. The EU Treaty provides for the ECB to operate in an open market economy, essentially reflecting a policy choice in favour of decentralised market decisions on the optimal allocation of resources. Historical cases of economy-wide resource allocation by central banks are hardly models of efficiency or good service. Furthermore, a retail CBDC would create a disproportionate concentration of power in the central bank." [18] A few months before Mersch's speech, Tao Zhang, Deputy Managing Director of the International Monetary Fund, also offered his opinion on the current set of proposals for CBDC, which he said "imply costs and risks to the central bank" [20]. We argue that his conclusions follow from the proposals that have been elaborated so far by central banks, which have generally involved a central ledger operated 2 The text of the remainder of this section also appears in a response to a recent consultation by the US Financial Crimes Enforcement Network [3].
by the central bank itself [21,22]. We suggest that such proposals have been designed neither to be holistic nor to complement the current model of payments, settlement, and clearing that exists today. In contrast, our approach specifically avoids the costs and risks identified by Mersch and Zhang, which we characterise more specifically in Section 2.2, and is broadly complementary to the current system.
Zhang also introduced the idea of a "synthetic CBDC" consisting of tokens issued by private-sector banks [20]. We argue that the desirable qualities that Zhang ascribes to synthetic CBDC apply to our proposed solution as well, except that our proposed solution still allows for "real" CBDC whilst the infrastructure would be operated by private-sector money services businesses (MSBs), including but not limited to banks, and for our purposes comprise both traditional commercial banks and financial institutions as well as new entities that would only have central bank reserves as their assets and whose liabilities would in turn only be deposits. This is an important distinction, and although Zhang provides no specific description of the technical features of synthetic CBDC, we assume that it would not involve a distributed ledger and that it would not be possible to have private transactions, since the private-sector banks would have visibility into the operation and ownership of their own tokens.
Nevertheless, an effective retail CBDC does not necessitate disintermediation of the banking sector. The CBDC that we envision would have more in common with physical cash than with bank deposits, and it would not substitute for bank deposits. It would not be eligible for rehypothecation and would not pay interest to its bearers, at least not in the traditional sense. We view retail CBDC principally as a technology to facilitate payments and consumer transactions. It is not simply a more scalable version of wholesale CBDC, reflecting the fact that the requirements for retail and wholesale users of money are not the same. Retail CBDC users would have the same reasons to favour bank deposits over CBDC for their long-term investments for the same reason that they favour bank deposits over cash for the same purpose; we discuss this further in Section 3.2. We also note that a central bank would not be a valid substitute for commercial banks, which we discuss further in Section 3.5.

Architectural Considerations
Another critical question is whether CBDC should be "account-based", by which we mean that users would interact with accounts representing relationships, or "token-based", by which we mean that CBDC would exist independently of any particular relationship, as coins and bank notes do. Accounts can represent relationships with a custodian or with the ledger system itself, and not all digital currency designs are the same. For example, although tokens in Bitcoin are explicitly designed to exist independently [23], tokens in Ethereum are explicitly designed to exist within accounts [24]. The two architectures are not symmetric: Although tokens in token-based systems can be held by custodians on behalf of users, such an arrangement is optional, whereas accounts are intrinsically designed to represent a persistent relationship.
We argue that our approach must be token-based, by which we mean that retail users must be able to hold tokens representing value outside of custodial relationships and that the tokens are not forcibly linked to an address or identifier that can be used to identify the user or the user's other tokens. Accounts can be used in conjunction with the token infrastructure, although we specifically disagree with the argument offered by Bordo and Levin that suggests that only accounts can pay interest and therefore all CBDC should be held in accounts [25]. In particular, it is not obvious that a CBDC system should pay interest to its bearers; we note that cash does not (see Sections 1.1 and 3.1). 3 Specifically, the trust property we seek is intrinsic to the token, in that we want retail users to trust the token itself and not some particular set of account-granting institutions or system operators. We also explicitly state: Trust cannot be manufactured and must be earned. More importantly, we do not create trust by asking for it; we create trust by showing that it is not needed. The approach that we describe in Section 2 addresses this requirement directly.
Furthermore, the CBDC proposed in our design model relies upon the DLT infrastructure for a variety of reasons outlined in Section 2. In our view, this is currently the most plausible method of implementation whereby the central bank can collaborate with private sector firms, via either public-private partnerships or other collaborative and supervisory models, to deliver a national payments infrastructure operated by the private sector. The use of DLT does not imply that households and retail members of the public must have a direct account or relationship with the central bank, as wrongly assumed by some. On the contrary, our design recognises the important role of MSBs, especially for identifying, onboarding, and registering new customers, satisfying compliance requirements, and managing their accounts (if applicable).
MSBs do not necessarily perform all of the functions of banks, such as lending credit. Moreover, in our design, we envisage full convertibility at par across CBDC, bank deposits, bank notes, and (for authorised MSBs) reserves, both to ease its introduction and to not interfere with the fungibility and general composition of the monetary base. To whatever extent this involves limitations or the introduction of frictions will be a matter of policy. Yet, in principle, at-par convertibility for cash and bank deposits as the default is a practical and design necessity. Issuing and introducing CBDC enables a new policy tool in adjusting the (dis)incentives to hold the CBDC through its various features but also to balance the possible flight from bank deposits [26], for which we do not see CBDC as a general substitute.

Our Proposal
The core of our proposed design is based upon an article by Goodell and Aste [12], which describes two approaches to facilitate institutional support for digital currency. We build upon on the second approach, institutionally-mediated private value exchange, which is designed to be operated wholly by regulated institutions and has the following design features: 1. Provides a government-issued electronic token that can be used to exchange value without the need for pairwise account reconciliation.
2. Allows transaction infrastructure (payments, settlement, and clearing) to be operated by independent, private actors 4 while allowing central banks to control monetary policy and CBDC issuance, with control over the creation and destruction of CBDC but not its distribution.
3. Protects the transaction metadata linking individual CBDC users to their transaction history by design, without relying upon trusted third parties.
4. Affords regulators visibility (but excluding counterparty information) into every transaction, allowing for analysis of systemic risks.
In this section we describe the central assumptions underlying our proposal, and we identify the benefits of distributed ledger technology (DLT) and offer support for our claim that a DLT-based architecture is necessary. Then, we describe how our proposed mechanism for digital currency works at a system level, identifying essential interfaces between the institutional and technical aspects of the architecture. We conclude by explaining how we would leverage our proposed architecture to achieve the economic stimulus objectives of State actors and to facilitate payments by individuals and businesses.

Key Assumptions
We imagine that digital currency might be issued by a central bank as "true" central bank digital currency (CBDC), although it might alternatively be issued by government, representing an obligation on a collateralised collection of State assets, such as sovereign wealth or Treasury assets. In either case, we note that in many countries (including the UK), no single party (including the central bank) has been assigned the responsibility to design, maintain, and update the rules of the process by which financial remittances are recorded and to adjudicate disputes concerning the veracity of financial remittances. We also note that responsibility to operate transaction infrastructure and supervise payment systems is different from the responsibility to create tokens and safeguard the value of State currency. In many countries, systems for payments, clearing, and settlement are a collaborative effort [29,30]. A design that externalises responsibility for the operation of a transaction infrastructure supporting digital currency is not incompatible with the operational role of a central bank in using digital currency to create money and implement monetary policy.
In particular, we question the argument that because the central bank has no obvious incentive to abuse data, therefore all users should be expected to trust it with their payments data. The idea of furnishing authorities with exceptional access to private data, including specifically the idea of dividing access to private data among multiple authorities, has been debunked [38]. In particular, an apparently disinterested actor can quickly become an interested actor when it finds itself in possession of something that is of interest to its influential neighbours. So, we might reasonably trust a central bank with monetary policy but not with transaction data.
Our approach to digital currency differs substantively from the vision proposed by several central banks [21,22]. We argue that the purpose of digital currency is to provide, in the retail context, a mechanism for electronic payment that does not rely upon accounts, and in the wholesale context, a means of settlement that is more robust and less operationally burdensome than present approaches. It is not to create a substitute for bank deposits, which would still be needed for economically important functions such as fractional reserve banking, credit creation, and deposit insurance. Neither is it a replacement for cash, which offers a variety of benefits including financial inclusion, operational robustness, and the assurance that a transaction will complete without action on the part of third parties. We imagine that in practice, digital currency would be used primarily to facilitate remittances that cannot be done using physical cash and that people would not be more likely to be paid in digital currency in the future than they would to be paid in cash today.
Nevertheless, we intend our proposed design to replicate some of the features of cash. Specifically, we seek to achieve the following properties: 1. Resistance to mass surveillance. Cash allows its bearers to transact without fear that they will be profiled on the basis of their activities. In Section 3.4, we shall explicitly demonstrate that our design is unlikely to increase the risk of fraud or AML/KYC violations relative to the current system by comparing our proposed system to cash. In fact, we suspect that it will lead to the opposite effect, given the possibility for the use of digital analysis tools in the cases of regulated activities wherein adherence to certain specific compliance rules is required and analysis over regulated institutions activities is helpful.
2. Transaction assurance. Cash allows its bearers to know that a potential transaction will succeed without depending upon a custodial or third-party relationship that might block, delay, or require verification for a transaction to take place.
3. Non-discrimination. Cash allows is bearers to know that their money is as good as everyone else's, and specifically that its value is not determined by the characteristics of the bearer.
We imagine that many, but not necessarily all, ordinary people and businesses would have bank accounts into which they would receive payments. These bank accounts would sometimes earn interest made possible by the credit creation activities of the bank. Banks would be able to exchange digital currency at par for cash or central bank reserves and would not generally hold wallets containing an equal amount of digital currency to match the size of their deposits. In the case of CBDC, banks would also be able to directly exchange the digital currency for central bank reserves. When an individual (or business) asks to withdraw digital currency, the bank would furnish it, just as it would furnish cash today. The bank might have a limited amount of digital currency on hand just as it might have a limited amount of cash on hand to satisfy such withdrawal requests, and there would be limits on the size and rate of such withdrawals just as there would be limits on the size and rate of withdrawals of cash. Once they have digital currency, individuals and businesses could use it to make purchases or other payments, as an alternative to account-based payment networks or bank transfers, and digital currency would generally be received into wallets held by regulated MSBs, just as cash would be.

Digital Money Systems
Token-Based Account-Based

Distributed Ledgers
Centralised Ledgers depends upon relationships, so anonymous transactions are not possible.
ex ante distributed consensus process; record of transactions is synchronised among participants.
validity of each transaction is determined by a particular arbiter.

Distributed Ledger Technology
Distributed Ledger Technology (DLT) offers a way to share responsibility for rulemaking among a set of peers. A distributed ledger is "a ledger that is shared across a set of DLT nodes [peers] and synchronized between the DLT nodes using a consensus mechanism" [39]. Although it is theoretically possible to build public digital currency infrastructure, even privacy-preserving digital currency infrastructure, using centralised technology [40], we argue that the salient features of a distributed ledger, including without limitation community consensus and immutability [39], are necessary for the infrastructure to succeed in practice. This should not be interpreted to mean that the infrastructure must provide for or allow peerto-peer transactions among users. This should be interpreted to mean that the system must be operated by a community, not some privileged arbiter, and that the consensus view of the truth about which transactions have taken place should reflect the agreement of this community. In particular, we rely upon DLT to marshal consensus among independent actors so that substantially all of the community must agree before a new entry is added to the ledger or before the rules governing the operation of the ledger are changed.
In the context of digital currency, DLT would provide transparency to the operation and rules of the system by restricting (at a technical level) what any single actor, including the central bank as well as government regulators, can decide unilterally. Such transparency complements and does not substitute for regulatory oversight. Next we specify who can access the ledger: ∎ Writing to the ledger. We envision that the only entities authorised to write to the ledger shall be the operators of the ledger, namely the regulated money services businesses (including but not limited to banks) and the central bank itself. The central bank shall write the entries that create or destroy CBDC, and money services businesses shall write the entries that "move" tokens within the system by signing them over from one keyholder to another. All entries would be approved via a consensus mechanism in which all entries would need to be approved by substantially all of the participants.
∎ Reading the ledger. We envision that the set of entities authorised to read the entries on the ledger shall include those who can write to the ledger, and by extension the regulators who oversee the parties that are authorised to write to the ledger. We do not anticipate that a public-facing API to read the ledger would be necessary, although a government might want to provide such a mechanism, for example to streamline public oversight of the system or to facilitate the investigation of suspicious activity. Figure 1 shows a taxonomy of digital money systems. Digital money systems include CBDC. The first question to ask is whether we need a system based on tokens rather than a system based on accounts. There are several benefits to using a token-based system, including substantially reducing the overhead associated with pairwise reconciliation and regulatory reporting. Most importantly, however, any system based upon accounts cannot offer privacy, since its design would necessarily require resolvable account identifiers that can ultimately be used to determine both counterparties to any transaction. Therefore, we must recognise that preservation of a token-based medium of exchange is necessary to the public interest, increases welfare, and maintains the critical nature of cash while providing to central banks and governments the assurance and risk assessment tools that are afforded to digital payment infrastructure platforms.
There are some important questions to ask about a token-based design, including whether we need the tokens to be issued by the central bank directly, or by other institutions ("stablecoins"), or whether the tokens can operate entirely outside the institutional milieu ("cryptocurrency"). However, let us first understand why a distributed ledger is necessary. Token-based systems can be centralised, relying upon a specific arbiter to handle disputes about the validity of each transaction (possibly with a different arbiter for different transactions), or they can be decentralised, using a distributed ledger to validate each transaction ex ante via a consensus process.
Specifically, we consider the question of who the system operators would be. In the case of CBDC, for example, although we assume that the central bank would be responsible for the design and issuance of CBDC tokens, we do not make the same assumption about the responsibility for the operation of a transaction infrastructure or payment system, which historically has generally been operated by privatesector organisations. As mentioned earlier, systems for payments, clearing, and settlement are often a collaborative effort [29,30]. Indeed, modern digital payments infrastructure based on bank deposits depends upon a variety of actors, and we imagine that digital payments infrastructure based on CBDC would do so as well. The responsibility to manage and safeguard the value of currency is not the same as the responsibility to manage and oversee transactions, and the responsibility to supervise payment systems is not the same as the responsibility to operate them. A design that externalises responsibility for the operation of a transaction infrastructure supporting CBDC is not incompatible with the operational role of a central bank in using CBDC to create money and implement monetary policy.
We also note that stablecoins introduce systemic risk. Their design relies upon a peg to some other asset, which can ultimately be undone. Users of the stablecoin, therefore, incur counterparty risk to those who are tasked with maintaining the peg. This counterparty risk implies either that the stablecoin must trade at a discount to the asset to which it is pegged, or that the peg would be underwritten by a government actor such as a central bank. In the former case, the stablecoin is not so stable. In the latter case, the stablecoin is not really different from fiat currency.
For reasons that we shall articulate in this section, we argue that a token-based solution based on distributed ledger technology is required. In our view, the benefits of distributed ledger technology broadly fall into three categories, all of which relate to the scope for errors, system compromise, and potential liability arising from exogenous or endogenous risk scenarios. We believe that each of these benefits is indispensable and that all of them are necessary for the system to succeed: 1. Eliminating the direct costs and risks associated with operating a live system with a role as master or the capacity to arbitrate. Because its database is centrally managed, a centralised ledger would necessarily rely upon some central operator that would have an operational role in the transactions. This operational role would have the following three implications. First, the central operator would carry administrative responsibility, including the responsibility to guarantee system reliability on a technical level and handle any exceptions and disputes on both a technical and human level. Second, because the central operator would be positioned to influence transactions, it would incur the cost of ensuring that transactions are carried out as expected as well as the risk of being accused of negligence or malice whether or not they are carried out as expected. Third, because the central operator unilaterally determines what is allowed and what is not, it might be accused of failing to follow the established rules.
2. Preventing unilateral action on the part of a single actor or group. Following the argument of Michael Siliski [31], the administrator of a centralised ledger could ban certain users or favour some users over others; implicitly or explicitly charge a toll to those who use the system; tamper with the official record of transactions; change the rules at any time; or cause it to stop functioning without warning.
3. Creating process transparency and accountability for system operators. Because the administrator of a centralised ledger can make unilateral decisions, there is no way for outside observers to know whether it has carried out its responsibilities directly. In particular, its management of the ledger and the means by which other parties access the ledger are under its exclusive control, and the administrator has no need to publicise its interest in changing the protocol or ask others to accept its proposed changes. With DLT, it is possible to implement sousveillance by ensuring that any changes to the rules are explicitly shared with private-sector operators.
4. Improving efficiency and service delivery through competition and scope for innovation. Vesting accountability for system operation in operators who are incentivised to perform would make it possible to achieve important service delivery objectives, ranging from adoption in the first instance to financial inclusion and non-discrimination, through private-sector incentives (e.g. supporting local banks) rather than top-down political directives.
Each of these advantages of distributed ledger technology relates to the scope for errors, system compromise, and potential liability arising from exogenous or endogenous risk factors surrounding a central authority. DLT makes it possible to assign responsibility for transactions to the MSBs themselves. Specifically, an MSB is responsible for each transaction that it writes to the ledger, and the DLT can be used to create a (potentially) immutable record binding each transaction to the corresponding MSB that submitted it, without the need for a central actor would to be responsible for individual transactions.

System Design Overview
Our design for CBDC is based on the approach described as an institutionally mediated private value exchange by Goodell and Aste [12], which we elaborate here and further build upon. This proposal uses DLT for payments, as motivated by reasons articulated in Section 2.2.
We envision a permissioned distributed ledger architecture wherein the participants would be regulated MSBs. MSBs would include banks, other financial businesses such as foreign exchange services and wire transfer services, as well as certain non-financial businesses such as post offices [29] as well.
The permissioned DLT design would support efficient consensus mechanisms such as Practical Byzantine Fault Tolerance [32], with performance that can be compared to popular payment networks. In particular, Ripple has demonstrated that its network can reliably process 1,500 transactions per second [33]. Although the popular payment network operator Visa asserts that its system can handle over 65,000 transactions per second [34], its actual throughput is not more than 1,700 transactions per second [35]. For this reason, we anticipate that it will be possible for a digital currency solution to achieve the necessary throughput requirement without additional innovation.
We assume that the only parties that could commit transactions to the ledger and participate in consensus would be MSBs, which would be regulated entities. The ledger entries would be available for all participants to see, and we imagine that certain non-participants such as regulators and law enforcement would receive updates from the MSBs that would allow them to maintain copies of the ledger directly, such that they would not need to query any particular MSB with specific requests for information. Although the ledger entries themselves would generally not contain metadata concerning the counterparties, the MSB that submitted each transaction would be known to authorities, and it is assumed that MSBs would maintain records of the transactions, including transaction size and whatever information they have about the counterparties even if it is limited, and that authorities would have access to such records.
Another important feature of our proposed architecture is privacy by design. Although we argue that data protection is no substitute for privacy (see Section 1.2), Ulrich Bindseil notes that "others will argue that a more proportionate solution would consist in a sufficient protection of electronic payments data" [28]. In the case of our proposed design, we might imagine that because the entire network is operated by regulated MSBs, some researchers might suggest creating a "master key" or other exceptional  Figure 2: Schematic representation of the system design. The ledger system is operated as a public permissioned DLT system in which participants are regulated money services businesses (MSBs). Alice withdraws digital tokens from an MSB into her non-custodial wallet in transaction T out and subsequently returns them to an MSB in transaction T in . The MSB from which the tokens are withdrawn might or might not be the same as the MSB to which the tokens are returned.
access mechanisms [36] to allow an authority to break the anonymity of retail CBDC users. The temptation to build exceptional access mechanisms should be resisted, with appreciation for the history of such arguments [37,38,19] and subsequent acknowledgement by policymakers in Europe and America [41,42], who have repeatedly cited their potential for abuse as well as their intrinsic security vulnerabilities. Ultimately, substituting data protection for privacy risks creating a dragnet for law-abiding retail CBDC users conducting legitimate activities, and it will never be possible for a data collector to prove that data have not been subject to analysis. To force people to use a system that relies on data protection is to attempt to manufacture trust, which is impossible; trust must be earned. Furthermore, criminals and those with privilege will have a variety of options, including but not limited to proxies, cryptocurrencies, and identity theft, available to them as "outside solutions" in the event that lawmakers attempt to force them into transparency.
Unlike designs that contain exceptional access mechanisms that allow authorities to trace the counterparties to every transaction and therefore do not achieve anonymity at all, our approach actually seeks to deliver true but "partial" anonymity, wherein the counterparties to a transaction can be anonymous but all transactions are subject to control at the interface with the MSB. We believe that our design is unique in that it achieves both anonymity and control by ensuring that all transactions involve a regulated actor but without giving authorities (or insiders, attackers, and so on) the ability to unmask the counterparties to transactions, either directly or via correlation attacks.
To satisfy the requirement for privacy by design, we introduce the concept of a non-custodial wallet, which is software that interacts with the ledger via an MSB that allows a retail CBDC user to unlink her CBDC tokens from any meaningful information about her identity or the identity of any previous owners of the tokens. A user would withdraw tokens from an MSB into her non-custodial wallet, and after some length of time return them to an MSB in a subsequent transaction, as shown in Figure 2. Specifically, a transaction in which a fungible token flows from a non-custodial wallet to an MSB reveals no meaningful information about the history of the token or its owner. To support non-custodial wallets with the privacy features we describe, the CBDC system must incorporate certain privacy-enhancing technology of the sort used by privacy-enabling cryptocurrencies such as Zcash and Monero. There are at least three possible approaches: 1. Stealth addresses, Pedersen commitments, and ring signatures. Stealth addresses, which obscure public keys by deriving them separately from private keys [43], deliver privacy protection to the receiver of value [47]. Pedersen commitments, which obscure the amounts transacted to anyone other than the transacting parties [44,45], remove transaction metadata from the ledger records [47]. Ring signatures, which allow signed messages to be attributable to "a set of possible signers without revealing which member actually produced the signature" [46], deliver privacy protection to the sender of value [47].
2. Zero-knowledge proofs. Zero-knowledge proofs "allow one party to prove to another party that a statement is true without revealing any information apart from the fact that the statement is true" [47] and can potentially be used to protect all of the transaction metadata [47]. Non-interactive approaches to zero-knowledge proofs such as ZK-STARKs deliver significant performance advantages over their interactive alternatives [48], and based upon their measured performance [48,49,50], we anticipate that such operations will be fast enough to suffice for point-of-sale or e-commerce transactions.
3. Blind signatures or blind ring signatures. Because our proposed architecture is not peerto-peer with respect to its users, we believe that it is also possible to combine a blind signature approach similar to the one suggested by Chaum [40]. Specifically, because we stipulate that a token withdrawn from a regulated MSB will be returned to a regulated MSB without being transacted with other non-custodial wallets first, we can specify that a user would first receive a blinded token from an MSB and later send the unblinded version of the token to the recipient's MSB. Under the assumptions made by Chaum, this can be done without revealing information that can be used to link the transaction wherein the token is withdrawn to the transaction wherein the token is returned. We further suggest that blind ring signatures [51] can be applied to shield the identity of the specific MSB from which the token is withdrawn from the transaction wherein the token is returned.
It has been argued that modern cryptographic techniques such as zero-knowledge proofs are too difficult to be understood or implemented effectively as part of public infrastructure, although this view ignores the reality that such cryptographic techniques are well-established. Additionally, there are many instances of regulation that does not specify the details of the specific technologies that are used to achieve compliance. Consider as an example the co-regulatory approach taken by the US Securities and Exchange Commission in enforcing Rule 611, wherein FINRA member firms implemented advanced technology to ensure that all marketable orders are routed to the exchange with the national best bid or offer (NBBO) [56]. We suggest that it is better not to allow prejudices about the technical sophistication of government actors to limit our ambitions for public systems. Figure 3 depicts a typical user engagement lifecycle with CBDC, which we anticipate would be a typical use case for our design. This user has a bank account and receives an ordinary payment via bank transfer into her account. Then, the user asks her bank to withdraw CBDC, which takes the form of a set of tokens that are effectively transferred to her non-custodial wallet via a set of transactions to different, unlinkable addresses that her bank publishes to the ledger. Later, the user approaches a merchant (or other service provider, either in-person or online, with a bank account that is configured to receive CBDC. Using her non-custodial wallet, the user interacts with point-of-sale software operated by the business, which brokers an interaction between her non-custodial wallet and the merchant's bank wherein the bank publishes a set of transactions to the ledger indicating a transfer of CBDC from the user's non-custodial wallet to the bank, credits the merchant's account, and informs the merchant that the transaction was processed successfully. The privacy features of the ledger design and the non-custodial wallet software ensure that the user does not reveal anything about her identity or the history of her tokens in the course of the transaction that can be used to identify her or profile her behaviour. More generally, we envision that a retail user of digital currency would receive it via one of four mechanisms:

User Engagement Lifecycle
1. Via an exchange of money from an account with an MSB into digital currency. We stipulate that an individual or business with an account with an MSB could opt to withdraw digital  currency from the account into a non-custodial wallet. Digital currency held by a retail user in the user's non-custodial wallet would be like cash. Because it is not held by an MSB, it would not be invested and it would not earn true interest. (In Section 3, we suggest a mechanism by which governments can incentivise or penalise the asset itself, but this would not be "true" interest and would not serve the same purpose.) Similarly, an individual or business with an account with an MSB could opt to deposit digital currency from a non-custodial wallet into an account, reversing the process, as shown in Figure 4.

2.
As a recipient of digital currency from an external source, received into an account with an MSB. In this case, the user would be the recipient of a digital currency payment. The sender of the payment might be known, for example if it is an account with an MSB, or it might be unknown, specifically if it is a non-custodial wallet.
3. As a recipient of digital currency from an external source, received into a noncustodial wallet. Any transaction in which a non-custodial wallet receives digital currency from an external source must be mediated by an MSB, so the key difference between this mode of receiving digital currency and a withdrawal from the user's own account is that in this case the recipient does not have (or is not using) an account with the MSB. This form of transaction is illustrated in Figure 5. We imagine that there would be certain legal requirements, such as transaction limits or a requirement for the recipient to provide positive identification documents to a human clerk, that would govern the role of the MSB in such transactions. We also imagine that this process could be particularly useful as a means to deliver government payments (for economic stimulus or for other reasons) to retail users without bank accounts, as illustrated in Figure 6.
4. Via an exchange of physical cash into digital currency. The transaction in which physical cash is converted to digital currency would be facilitated by an MSB, subject to appropriate rules, just as in the case that digital currency is received directly from an external source. For example, the MSB might be required to ask for information concerning the origin of the cash if the amount exceeds a certain threshold.
Note that retail bank accounts are not generally expected to hold CBDC on behalf of a particular user, any more than retail bank accounts would hold cash on behalf of a particular user. A bank would swap CBDC for central bank reserves from time to time, and vice-versa, with the expectation that the bank would furnish CBDC to its retail customers, subject to limits on the size and rate of withdrawals.
Note also that the messages on the ledger are published by regulated financial institutions. This is an important feature of the system design: all transactions on the ledger must be published by a regulated MSB, and because the ledger is operated entirely by regulated MSBs, private actors cannot exchange value directly between their non-custodial wallets. At the same time, the non-custodial wallets offer a layer of indirection wherein MSBs would not be able to identify the counterparties to the transactions involving non-custodial wallets. Banks might need to know their customers, but merchants generally do not. Furthermore, a merchant's bank does not need to know the merchant's customers, and a merchant's customer's bank does not need to know about the merchant or its bank at all. For instances wherein merchants really do need to know their customers, the reason is generally about the substance of the relationship rather than the mechanism of the payment, and identification of this sort should be handled outside the payment system. By providing a mechanism by which no single organisation or group would be able to build a profile of any individual's transactions in the system, the use of a distributed ledger achieves an essential non-custodial wallet MSB non-custodial wallet Figure 5: Schematic representation of a mediated transaction between consumers. Retail CBDC users wishing to transact with each other via their non-custodial wallets must transact via a regulated institution or a regulated business with an account with a regulated institution. The institution creates on-ledger transactions from the non-custodial wallet of one retail CBDC user and to the noncustodial wallet of another retail CBDC user without creating accounts for the retail CBDC users.
requirement of the design. In addition to our previously stated requirement that transactions into and out of the non-custodial wallets would be protected by mechanisms such as stealth addresses or zeroknowledge proofs to disentangle the outflows from the inflows, individuals would be expected to use their non-custodial wallets to transact with many different counterparties, interacting with the MSBs chosen by their counterparties and not with the MSBs from which their non-custodial wallets were initially funded. Figure 5 depicts the mechanism by which individuals would transact from one non-custodial wallet to another. They must first identify a regulated MSB to process the transaction onto the ledger, perhaps in exchange for a small fee. The MSB would process a set of transactions from the first non-custodial wallet to the MSB and from the MSB to the second non-custodial wallet. An MSB could provide a similar service for an individual exchanging CBDC for cash or vice-versa. Presumably, the MSB would gather whatever information is needed from its customers to satisfy compliance requirements, although we imagine that strong client identification, such as what might conform to the FATF recommendations [57], could be waived for transactions that take place in-person and are sufficiently small. In the case of small online transactions between two persons, we imagine that an attribute-backed credential indicating that either the sender or the receiver is eligible to transact might be sufficient [58]. Finally, some MSBs could provide token-mixing services for retail CBDC users who had accidentally exposed metadata about the tokens in their non-custodial wallets.
Concerning the hypothetical stimulus described in Figure 6, we note that if a government intends to make stimulus payments to a specific set of eligible individuals, 5 notwithstanding the possibility that this set might include all citizens or residents, then it could refer to each such individual using a unique taxpayer identification number. Then, the government could ask each eligible party to specify a bank account, current account, or wallet into which to deposit the funds. This approach might work in many cases, although it might not work for eligible individuals or busineses without bank accounts. To address the gap, the government could ask eligible parties to identify themselves to a qualified MSB for verification, for example a post office, that would be able to carry out the required identification procedures to determine whether the prospective recipient has the right to make a claim associated with a particular taxpayer identification number. Once this is done, the MSB could enter a transaction that delivers the digital currency to the individual's non-custodial wallet directly, avoiding the need for a bank account. We propose that each of these options could be provided to both individuals and businesses.  Figure 6: Schematic representation of a disbursement to a retail user with a non-custodial wallet. This example shows how a retail user might claim CBDC that she is eligible to receive, either directly from the central bank or from an institution such as the State treasury or a private-sector bank. The user would identify herself to a regulated MSB, which would carry out the requisite compliance checks.

Security Considerations
Since digital currencies generally rely upon the use and management of sensitive cryptographic information such as keys, we recognise that a digital currency that allows users to hold tokens outside of the protection of an account with a financial institution would also introduce responsibility on the part of users to manage the security of those tokens. Users have a range of possible options at their disposal, including encrypted devices with one-factor or two-factor authentication, third-party custodial services, single-use physical tokens as an alternative to wallet software for their general-purpose devices, and simply choosing to limit the amount of digital currency that they hold at any moment. We suggest that all of these approaches could be useful, and as with many financial decisions, the best choice would be a function of the preferences and risk profile of each individual user.
We imagine that an individual might share the private cryptographic information (e.g. a private key that can be used to initiate a transaction) associated with digital currency with another individual, thereby allowing the other individual to transact it on her behalf. We do not consider that such an exchange of information would constitute a payment, since there is nothing intrinsic to the system that would stop the first party from spending the digital currency before the second party has a chance to do so. It would be appropriate to characterise such an exchange as a "promise of payment" rather than a payment itself, similar to providing a post-dated cheque, and there is no mechanism to prevent people from making promises to each other. Once an individual or business is in possession of digital currency, the ways to dispose of the digital currency are the inverses of the methods to acquire it.

System Governance
Because privacy-enhancing technologies require vigilance [52], MSBs and the broader community must commit to maintain, audit, challenge, and improve the technology underpinning the privacy features of this design as part of an ongoing effort [12]. Such maintenance implies establishing a process for security updates as well as updates to accommodate new technology and features as needed. The transparency afforded by the use of DLT can provide the basis by which the broader community can observe and analyse the operation of the system, including any changes to its regular functioning, to ensure that transacting parties remain protected against technologically sophisticated adversaries with an interest in de-anonymising the CBDC users for the purpose of profiling them.
Ultimately, whoever controls the code that the system relies upon to operate, controls the operation of the system. By analogy, consider the role of developer communities in handling ledger-related disputes in cryptocurrency communities [53]. For this reason, a centralised developer community could certainly negate the benefit of a decentralised ledger. This implies that each independent participant in the system should establish its own rigorous procedure for accepting changes to the code, most likely including internal code review and security analysis, whether or not participants share the same code base, and it might be necessary for this process to be subject to public oversight as well. Such procedures for internal and external oversight should involve a broad security community with diverse allegiances, and in particular, care must be taken to ensure that it will be possible to make timely changes to address emerging problems 6 while protecting both users and system operators from the possibility that backdoors or other vulnerabilities might be introduced in haste. This is no simple task, although the work of the security community in free software projects such as Debian [54] demonstrate that the combination of deep oversight and timely changes is possible, and established procedures for the operation of trading networks such as the National Market System in the United States [55], demonstrate that such changes can be undertaken in a co-regulatory context, with formal proposals by regulators, as well.
From the standpoint of CBDC, platform governance and decision-making predominantly relates to authenticating and thereby allowing transactions. Our proposal, as summarised in Table 1 contends that the infrastructure would be operated by the private sector and may be exclusively operated by the private sector. We envisage that there should be no fewer than five MSBs for a pilot, and no fewer than about twenty MSBs for robust operation. The approval of transactions takes place through consensus across the infrastructure operators of the platform. However, the ability to formally become an infrastructure operator and MSB pro tanto requires the approval of the local regulator, however it is regulated. We assume in this context the central bank is responsible for overseeing clearing and settlement activities. 7

Analysis
We note that although it can accommodate CBDC, the digital currency system we propose can be generalised as a "value container" [27] that can be extended to potentially represent a plethora of different assets and their underlying infrastructure, including but not limited to central bank or government assets. For the purpose of our analysis, we focus on the use of our proposed design for CBDC and specifically retail CBDC, as a means of allowing the general public to have broad access to an public, digital form of cash.

Retail Use
We suggest that a primary benefit of CBDC is its ability to be held in non-custodial wallets by retail users. The argument that CBDC should be held only in custodial accounts actually follows from two assumptions, first that it is not possible to remunerate tokenised assets directly, and second, that the purpose of CBDC is primarily to solve a problem of efficiency, for example of transaction costs or monetary policy transmission, and nothing more. However, there are plausible mechanisms that can remunerate tokenised assets directly, and the inexorable decline in cash as a means of payment presents a problem that is manifestly deeper than monetary policy transmission. Thanks to cash, people have always had the ability to conduct financial transactions using assets that they could control completely, for which their spending habits cannot be profiled, and which are not subject to discrimination or interception by third parties. However, the decline in cash use suggests that cash infrastructue might soon become economically untenable, in which case these foundational rights face elimination by default. Therefore, CBDC can be seen, perhaps first and foremost, as an opportunity to allow retail users to continue to enjoy the benefits of accountless money in the digital age.
We ask whether CBDC is best seen as a modern form of bank deposits or as a modern form of cash. If CBDC were to be account-based and suitable for rehypothecation, then it might plausibly substitute for bank deposits in the general case, although if CBDC were to be token-based and not suitable for rehypothecation, then it would be much more cash-like. In the latter case, users would still have reasons, including interest and inflation risk, to continue to prefer bank deposits as a store of value and to use CBDC principally as a means of payment, even if both forms of money were usable for both purposes.

Impact on Liquidity
The issuance and use of CBDC could become a useful tool for central banks in managing aggregate liquidity. For example, were CBDC to be widely held and adopted for use, it could lead to a shift in aggregate liquidity, which refers to the assets being used and exchanged and which carry a liquidity premium [26]. Under certain models, a CBDC would lead to efficient exchange, particularly given that it is a low cost medium of exchange and has a stable unit of account, and particularly in the case wherein the digital currency (as we propose it) is being used in a broad range of decentralised transactions, and allows for monetary policy transmission channels on trading activity to be strengthened. The central bank would have at its disposal certain capabilities in controlling the supply and price of CBDC, including through the use of (dis)incentives to generate a higher liquidity or lower premium in CBDC and in bank deposits, subject to where investment frictions exist in a much more targeted way [26]. Moreover, CBDC can be used as intraday liquidity by its holders, whereas liquidity-absorbing instruments cannot achieve the same effect. At present, there are few short-term money market instruments that inherently combine the creditworthiness and the liquidity that a CBDC could potentially provide. CBDC, therefore, could play an important deterrent role against liquidity shocks.
One possible concern about CBDC is that individuals might run from bank deposits to CBDC during a financial crisis. Although such a run is conceivable, we argue that it is no more likely with our proposed system for CBDC than it is with cash. Specifically, we imagine that individuals would be subject to limits on their withdrawals of CBDC from their bank accounts, just as they are subject to limits on their withdrawals of cash. If a run were underway, its pace would be limited by such limits, and in principle, the government could even ask banks to impose tighter limits or to disallow withdrawals from banks entirely in the event of an emergency. Moreover, if the government chooses to guarantee bank deposits up to an amount, then the other benefits afforded by such deposits coupled with that guarantee would disincentivise such a run. In other instances the cost-benefit and risk-reward profile would require more specific analysis on a jurisdiction by jurisdiction basis. Because we recognise significant utility for bank deposits even in the presence of CBDC, we suggest that CBDC would be be complementary to deposits and that banks would play a fundamental role in the issuance and storage of CBDC tokens.

Impact on the Financial Industry
The most direct impact of our approach to digital currency on the financial industry involves risk management, on several levels. By improving the speed of settlement, digital currency can be used to facilitate liquidity risk management among financial institutions. Digital currency can also be used to address systemic risk, both explicitly, by offering regulators a view into substantially every transaction, as well as implicitly, by offering governments a tool to implement stimulus while controlling the aggregate leverage in the system.
Considering that, in general, DLT offers a promising risk-mitigation tool [61], our design relies on a DLT network operated by MSBs and other private-sector institutions rather than a centralised ledger run by a single public (or private 8 ) organisation. As such, our approach addresses a variety of risks associated with relying upon a central arbiter: (1) technical risks associated with availability, reliability, and maintenance; (2) risks associated with trust and operational transparency; and (3) financial and legal risks. Our approach also allows the private sector to operate the infrastructure for retail payments, clearing, and settlement, while allowing government regulators to oversee the system at an organisational level. Because we imagine that digital currency will complement rather than substitute for bank deposits, our approach leverages the role of commercial banks without forcibly decreasing their balance sheets. In particular, because we believe that the main purpose of CBDC tokens will be to facilitate electronic payments rather than to serve as a long-term store of value, we do not anticipate that the balance sheets of central banks will increase significantly as a result of its introduction.

Impact on Fraud and Tax Evasion
We imagine that a rigorous compliance regime will govern the behaviour of MSBs and the relationships they have with their customers. We assume that banks in particular will have requirements for strong customer identification, and other MSBs such as wire transfer firms, currency exchanges, and post offices will face a combination of transaction limitations and procedures for identification and authorisation. We assume that authorities will be able to see every transaction that takes place as well as the specific MSB that creates that transaction, and we also assume that authorities will have access to the records that the MSBs are required to maintain concerning the transactions they facilitate.
Nevertheless, because our system allows a measure of true anonymity, it does not provide a way to reveal the identities of both counterparties to authorities. In particular, even if authorities have all of the records, some transactions will have non-custodial wallets as a counterparty, just as some cash transactions have anonymous counterparties. Although authorities might know all of the retail users and their history of digital currency withdrawals, they will not be able to link a non-custodial wallet to a specific retail user. Recall that retail users will be able to withdraw digital currency from an MSB in the same manner that they would withdraw cash from a bank or ATM, with similar limits and restrictions. Retail users would be able to spend digital currency the same way that they would be able to spend cash, making purchases with vendors who are also subject to limits and restrictions as well as profiling by their financial institutions, and who know that their receipt of tokens will be monitored by authorities. Authorities would know who had recently withdrawn digital currency into a non-custodial wallet just as they would know who had recently withdrawn cash, and they would also know who had recently received digital currency from a non-custodial wallet. However, it would not be possible to use the digital currency to link a specific recipient of cash to a specific counterparty that had made a withdrawal. We argue that this property of cash is necessary and fundamental to protect retail users from profiling and manipulation by adversaries and other powerful interests including private sector participants. Furthermore, revealing mutual counterparty information for every transaction would divert the onus of fraud detection to law enforcement agencies, effectively increasing their burden, while well-motivated criminals would still be able to use proxies or compromised accounts to achieve their objectives, even if every transaction were fully transparent.
To manage fraud, our system design takes a different approach that is oriented toward control mechanisms and transaction analytics rather than counterparty profiling. Because every transaction involves a regulated financial intermediary that would presumably be bound by AML/KYC regulations, there is a clear path to investigating every transaction effectively. Authorities would be positioned to ensure that holders of accounts that take payments from non-custodial wallets adhere to certain rules and restrictions, including but not limited to tax monitoring. The records from such accounts, combined with the auditable ledger entries generated by the DLT system, could enable real-time collection of data concerning taxable income that could support reconciliation and compliance efforts. Because all of the retail payments involving digital currency would ultimately use the same ledger, identification of anomalous behaviour, such as a merchant supplying an invalid destination account for remittances from non-custodial wallets, would be more straightforward than in the current system, and real-time automated compliance would be more readily achievable. Such detection could even be done in real-time not only by authorities but also by customers, thus reducing the likelihood that it would occur in the first instance.
It is worth considering whether safely storing large amounts of physical cash would be more or less costly than storing large amounts of digital currency. In principle, digital currency can be stored cheaply online, although the attack surface of online systems might have important weaknesses, and the longevity of offline digital media has limits. Note that security safes are generally priced as a function of the value, not the storage cost, of what is inside. In addition, the use of vintages can explicitly penalise the accumulation of large stashes of digital currency in a manner that is hard to replicate with physical cash.
It is also worth considering whether criminal organisations might exchange private keys rather than entering transactions on the ledger as a way to avoid interacting with MSBs. Our view is that sharing a private key is equivalent to sharing the ability to spend money that can only be spent once, effectively constituting a promise, otherwise as transferring posession in the case of a non-custodial wallet. Criminals can exchange promises by a variety of private or offline methods even in the absence of a privacyrespecting payment system. At one level, it is impossible to monitor or restrict such exchanges of promises, but at another level, exchanges of this sort would require a high degree of a priori trust to succeed, and we submit that transitive trust relationships would generally degrade rapidly across successive transactions. Meanwhile, attempts to spend the same token twice can be easily detected, and potentially investigated, by authorities at the time of the transaction. In our view, the utility derived from the privacy preserving nature of a payment infrastructure warrants a trade-off, however, the tradeoff is substantially limited given the added capability available to law enforcement and the mechanisms that may be instituted, coupled with the fact that would there to be nefarious actors and activities, those activities could take place in a variety of ways and media, and they are not more effectively enabled by our system. Table 1 offers a comparison of the main design features. The features of our design that contrast with many of the prevailing CBDC design proposals include, but are not limited to, the following:

Comparison to Alternative Approaches
1. Retail users can hold digital assets outside accounts. Most of the existing proposals assume that digital assets would be always held by intermediaries. In contrast, our proposal empowers retail users with the ability to truly control the assets they hold and choose custodians, when applicable, on their own terms.

2.
No central bank accounts for individuals and non-financial businesses. In our view, requiring central bank accounts would introduce new costs, weaknesses, and security vulnerabilities. It would result in the central bank taking responsibility for actions commonly performed by the private sector in many countries, and it would negate the benefits of using tokens rather than accounts. A team led by Jesús Fernández-Villaverde observed that many proponents of CBDC such as Bordo and Levin [25] assume that central banks would disintermediate commercial intermediaries and that in many cases this possibility is touted as a benefit of CBDC [64]. However, their analysis formalises a trade-off between avoiding bank runs and delivering optimal allocation of capital [64], underscoring a key role of commercial banks in bearing risk that, in our view, should not be undermined.

3.
A purpose-built domestic, retail payment system. The requirement to support cross-border or wholesale payments is intentionally not included in our design. Our proposal is designed specifically to meet the requirements for a domestic, retail payment system, which we believe differ significantly from the requirements for a cross-border or wholesale payment system.

4.
True, verifiable privacy for retail users. Data protection is not the same as privacy, and our proposal does not rely upon third-party trust or data protection for their transaction metadata. Some proposals include "anonymity vouchers" that would be usable for a limited time in accountsbased digital currency systems [14,15]. We do not believe that such approaches would be effective, not only because of the dangers associated with reducing the anonymity set to specific intervals but Goodell, Al-Nakib, Tasca

5.
No new digital identity systems. Our system does not require any special identity systems beyond those that are already used by MSBs and private-sector banks. In particular, it does not require a system-wide identity infrastructure of any kind, and it also explicitly allows individuals to make payments from their non-custodial wallets without revealing their identities.

6.
No new real-time operational infrastructure managed by central authorities. Our proposed system can be operated exclusively by private, independent actors without relying upon a central actor to operate any specific part of the infrastructure. The distributed ledger makes it possible to assign responsibility for most transactions to the MSBs, not the central bank. An MSB is responsible for each transaction that it writes to the ledger, and the DLT can be used to create a (potentially) immutable record binding every transaction to the corresponding MSB that submitted it. We understand that the central bank is not responsible for individual transactions.

Recommendations
We believe that all the models proposed so far for CBDC fail to meet important design criteria that have been summarised in Table 1. In particular, we show that other concurrent CBDC design proposals omit certain design features that have an impact on critical areas of welfare-generating characteristics, as well as governance and financial implications. The proposal that we have articulated addresses these essential requirements directly and does not compromise.
The following design features make our model unique. First, our proposal uses a DLT-based settlement system that is overseen by State actors but operated entirely by private, independent actors. Second, it aims to enhance the welfare and safety of users by employing privacy by design without compromising the core risk analysis capacity in which policymakers would find value.
In all cases, it is critical to separate the regulatory requirements for identification (the 'policy') from the underlying protocols and technology that facilitate payments (the 'mechanism'). Such separation must be seen as a requirement for non-custodial wallets. The mechanism by which custodial retail electronic payments are implemented enables surveillance as an artifact of the custodial relationship. For owners of money to truly use it freely, they must have a means of using money outside custodial relationships and without the risk of profiling. To impose requirements upon non-custodial wallets that essentially proscribe such uses would only serve to ensure that digital money is never truly owned, as its users would be forced to accept a more limited set of rights. 9