# A Digital Currency Architecture for Privacy and Owner-Custodianship
## 3 Our Proposal
### Non-Custodial Wallets  
Another important feature of our proposed architecture is _privacy by design_. Although we argue that data protection is no substitute for privacy (see Section 2.3.2), [PERSON] notes that \"others will argue that a more proportionate solution would consist in a sufficient protection of electronic payments data\" [50]. 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 access mechanism [51] 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 [27; 44; 52] and subsequent acknowledgement by policymakers in Europe and America [53; 54], 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. The ledger system is operated as a _public permissioned DLT system_ in which participants are regulated MSBs. [PERSON] 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. 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 privacy-enhancing technology of the sort we described in Section 2.3.3. If we choose to use ZKP or a combination of stealth addresses, Pedersen commitments, and ring signatures, then it might be possible to avoid requiring receiving MSBs to immediately return the (spent) tokens that they receive to the issuer. However, blind signatures might offer some benefit in the form of computational efficiency, and the fact that we have stipulated the involvement of an MSB in every transaction, they could be appropriate for our use case.