Systematization of Knowledge: The Design Space of Digital Payment Systems with Potential for CBDC

Systematization of Kno wledge: The Design Space of Digital P a ymen t Systems with P oten tial for CBDC Judith Senn University of Innsbruck judith.senn@uibk.ac.at Aljosha Judma yer University of Vienna aljosha.judmayer@univie.ac.at Nic holas Stifter SBA R ese ar ch nstifter@sba-research.org Rainer Böhme University of Innsbruck rainer.boehme@uibk.ac.at Abstract Cen tral Bank Digital Currencies (CBDCs) are prop osed as a public resp onse to the uptak e of priv ately run digital pa yments, with the digital euro, under developmen t by the Europ ean Cen tral Bank (ECB), serving as a prominent example. This momen tum pro vides a unique opp ortunit y to fundamen tally rethink the future of money , and, assuming wide adoption, to establish paymen t systems that oﬀer strong cryptographic securit y and priv acy guaran- tees from the start. While the cen tral banks in c harge are inv estigating priv acy-enhancing tec hnologies (PET s), they often conclude that PET s are immature or insuﬃciently scalable. Moreo ver, these eﬀorts tend to examine primitives in isolation, oﬀering little insight in to how a system using these PET s w ould scale. This systematisation of knowledge, therefore, provides a structured, top-down technical analysis of 36 paymen t system designs of complete system prop osals that can inform CBDC designs or w ere explicitly prop osed for this application. W e iden tify recurring design patterns, tec hnical trade-oﬀs, and implementation challenges. Concluding, we highligh t research gaps, including oﬄine paymen ts and p ost-quan tum security . 1 In tro duction Money is vital for the econom y . With the rise of online pa yments, it is increasingly handled b y priv ate ﬁrms. Cen tral banks hav e become alert to this trend, as sho wn b y their reaction to F aceb ook’s initiativ e to launch Libra [ 1 ]. Pa yment reven ues account for ab out 2 percent of gross domestic pro duct in the US, 3 p ercen t in Asia, and 1 p ercen t in the EU, largely driven by fees [ 2 ]. The gro wing dominance of the priv ate sector also implies lost seigniorage and limited monetary policy options [ 3 ]. This is reinforced b y the decline of cash [ 4 ], and the expanding p opularit y of cryptocurrencies and stablecoins [ 5 ]. In resp onse, cen tral banks ha ve started to explore how the public sector can issue money in digital form [ 6 , 7 ], leading to numerous initiativ es to researc h or pilot Central Bank Digital Currencies (CBDCs) [ 8 ]. T o do so, some central banks ha ve hired cryptographers and formed tech teams. How ever, it is not easy for them to ramp up their technological exp ertise to match that in their core domains of ﬁnance and economics, where their staﬀ are often at the forefront of research. The design of a retail paymen t system in volv es three ob jectiv es that are inherently in ten- sion with one another: priv acy , compliance, and p erformance. Priv acy is essen tial b ecause pay- men t data can reveal sensitiv e personal information [ 9 , 10 ]. A t the same time, priv acy cannot b e unconditional, since this would facilitate misuse such as money laundering [ 11 ]. This mak es tec hnical supp ort for compliance essential. A dding to the challenge is the need for scalability , as a retail CBDC ma y need to process h undreds of thousands of transactions per second with lo w latency [ 12 , 13 ]. Existing digital paymen t systems prioritise reliability , scalability , and compliance. 1 T echnical priv acy protections are rare [ 14 , 15 ]. Introducing a new digital retail paymen t system giv es cen tral banks the opp ortunit y to reshap e digital money with stronger security and priv acy guaran tees. A chieving this, how ever, is far from easy . T o address these c hallenges, several central bank studies [ 16 – 20 ] as w ell as academic works [ 21 ] surv ey Priv acy Enhancing T ec hnologies (PET s) as p oten tial building blo cks for a CBDC. While these studies oﬀer v aluable insights, the b ottom-up approach is problematic b ecause PET s cannot b e comp osed arbitrarily . As a result, these studies pro vide limited understanding of how systems incorp orating PET s would perform and scale. This calls for a top-down persp ectiv e that com- pares complete system proposals. Some authors hav e made progress in this direction. Nardelli et al. [ 22 ] presen t a broad comparison, but they analyse priv acy without taking p erformance into accoun t. Chatzigiannis et al. [ 23 ] emphasise compliance and priv acy , but do not prop ose a com- prehensiv e framew ork. Other w orks discuss economic implications of priv acy [ 24 , 25 ] or general priv acy–compliance trade-oﬀs [ 26 , 27 ]. All of these works are worth reading and hav e inspired our systematisation. T o the b est of our knowledge, the present w ork is the most comprehensive tec hnical top-down study . W e analyse a large set of systems, with a consistent taxonomy and an emphasis on designs with p oten tial for CBDC. Our main contributions are as follo ws: • W e dev elop a framew ork to compare system arc hitecture choices, priv acy , compliance, p erfor- mance, and other tec hnical features with implications for the user exp erience (such as oﬄine functionalit y), capturing 28 prop erties, including assumptions and undesired prop erties. • W e compare 36 paymen t system designs, cov ering several decades of research, from coin- based systems to distributed ledgers. Our categorisation allows us to compare these v astly diﬀeren t designs, reaching from Chaumian e-cash, ov er selected crypto currencies, to recent CBDC prop osals. • W e reduce complexit y by mapping the design space in to four c haracteristic patterns and discuss characteristic features of each. • W e highlight underexplored areas and op en challenges, such as p ost-quan tum security and b enc hmarking metho ds reﬂecting real-world transaction b ehaviour. Although the title of this work refers to digital pa ymen t systems with p otential for CBDC, our pap er selection is not limited to explicit CBDC prop osals. W e delib erately adopt a broader scop e for tw o reasons. First, making informed decisions ab out the design of a CBDC requires an under- standing of what is technically possible. Muc h of the recen t progress in digital paymen ts has b een made in the crypto currency space. Second, there is no sharp tec hnical b oundary b et ween CBDCs and crypto currencies. Neither term has a univ ersally accepted technical deﬁnition. Although both supp ort digital paymen ts, they are t ypically based on very diﬀerent trust assumptions: CBDCs assume a central authority at least for issuance, while most crypto currencies aim to circumv en t an y authority . These assumptions inﬂuence the resulting system designs. How ever, they are in- suﬃcien t to create a clear distinction b etw een the t wo. Whic h design is most suitable for building a CBDC ultimately dep ends on the relev an t p olicy ob jectives. This paper is organised as follows: Section 2 sets the stage with a brief elab oration on the concept of money . Section 3 in tro duces the framework for comparing paymen t designs. Section 4 presen ts the results of our analysis in t wo tables and outlines four design patterns. Section 5 discusses selected prop erties of the design patterns. Section 6 concludes. The exact metho dology for pap er selection is detailed in App endix A . F or context, we assume that readers are familiar with the current banking system [ 28 ] and ha ve basic knowledge of Bitcoin [ 29 ] and Chaumian e-cash [ 30 ]. 2 2 What is Money? What is a Pa ymen t? There is no univ ersal agreement on the deﬁnition of money , even amongst economists: “ few issues in e c onomics have gener ate d such he ate d deb ates as the natur e of money and its r ole in the e c on- omy. ” [ 31 , p. 1]. Money is the distribution of v alue combined with so cial conv en tions that enable its exc hange for go ods and services [ 2 ]. The success of money depends on public trust. In the case of central bank money , this trust relates to the central bank’s capacit y to act in the public in terest [ 32 ]. Economists tend to deﬁne money b y the functions it fulﬁls: unit of account, means of pa yment, and store of v alue [ 33 ]. Closer to the mindset of computer scien tists is Kocherlak ota’s famous argumen t that money is memory [ 34 ], more precisely an imp erfe ct representation of records of all past transactions. The latter p ersp ectiv es will guide our discussion. One function of money is to serve as a means of pa yment. T o pay , the sender must authorise the paymen t, and it m ust be ensured that only they can do so. The recipient, in turn, m ust b e able to validate the correctness of the paymen t. Otherwise, they cannot rely on the so cial con ven tion that the v alue can b e exchanged in the future. In this wa y , money combines individual (authorisation) and so cial (v alidation) interests. F or cash, ownership of a banknote authorises the holder to sp end it, and v alidation o ccurs by insp ecting the physical prop erties of the banknote that mak e it diﬃcult to repro duce. In the case of digital money , this logic m ust b e mapp ed to memory , i. e., information preserved o ver time. The sender holds priv ate information (e.g., secret keys) that enable them to authorise pa yments. W e refer to information held b y these parties as lo c al information . In practice, users can outsource lo cal information to trusted intermediaries who can interact with the paymen t system on their behalf. By con trast, the information required to v alidate transactions is referred to as glob al information . It ma y include records of previous transactions, the distribution of v alue in the system, as well as public keys. Global information is essen tial for detecting and preven ting the same units from b eing sp en t more than once (double-sp ending). This ensures that digital money cannot b e easily copied. W e deﬁne a system op er ator as an entit y resp onsible for maintaining the global information. Op erators can b e distributed and may include central banks, commercial banks, other paymen t service providers, or miners. Global information ma y be public (as in a ledger) or restricted to privileged op erators. In con ven tional online banking, lo cal information consists of a user’s authen tication credentials and account identiﬁers, while global information is kept b y banks in the form of accoun t balances and transaction records. In Bitcoin, lo cal information is represented b y priv ate keys, and global information is maintained in a distributed ledger recording unspent transaction outputs (UTXOs). In Chaumian e-cash, local information takes the form of anonymous tok ens signed by the issuer, whereas the database of sp en t tokens used to detect double-sp ending represen ts the global information. The system state is deﬁned b y the com bination of all lo cal and global information. It may not b e fully observ able by any single party . V alue transfers imply up dates of the system state. System architectures diﬀer in how they represent v alue in the system state. They also diﬀer how state information is distributed lo cally and globally . All this has implications on p erformance, the ac hiev able level of priv acy , options to enforce compliance, and usability . Illustrating this in a diagram, every digital paymen t system inv olv es lo cal information used to authorise pa yments and global information used to v alidate them (see Fig. 1 a). Lo cal information m ust be distributed among users, eac h holding the information required to authorise their o wn funds. Global information can be distributed among m ultiple op erators, suc h as commercial banks maintaining diﬀeren t user accoun ts (see Fig. 1 b). Moreo ver, global information is often replicated to ensure robustness against crashes and data loss (see Fig. 1 c). Ho wev er, one important asp ect of paymen ts remains to be discussed. A pa yment requires communication b et ween the sender and the recipient, as well as b et w een the users and the system op erators, and among the op erators themselves (see Fig. 1 d). The priv acy of all these comm unication channels, as well as the communication patterns, must b e considered when ev aluating a system. A ccording to Kahn, money is not only memory , but also priv acy [ 35 ]. He argues that the v alue of money may lie in its imperfect memory – in other words, in the presence of priv acy , understo od 3 (a) Lo cal information Global information (b) (c) (d) S R (e) S R Figure 1: Stepwise illustration of core concepts: (a) lo cal and global information; (b) distribution of local and global information; (c) replication of global information; (d) comm unication netw orks b et w een users, betw een users and op erators, and inter-operator comm unication; (e) anon ymous comm unication channels to ensure priv acy against observ ers of the netw ork traﬃc. as missing information. T o o m uch information in a paymen t system might not only lead to general harms such as chilling eﬀects, censorship, and suppression, but also sp eciﬁc economic consequences. It could enable price discrimination [ 36 , 37 ]. Additionally , a lac k of priv acy may cause money to lose its fungibilit y , as diﬀeren t funds may carry diﬀerent asso ciated information. In the w orst case, money migh t even cease to function as an accurate unit of account [ 38 ]. If every paymen t in volv es a bundle of v alue and information, whose exact v alue is diﬃcult to determine, it b ecomes imp ossible to meas ure the v alue of the go ods being exc hanged. Finally , since paymen ts are a fundamen tal component of all digital economic in teractions in our society , the priv acy provided b y the paymen t infrastructure eﬀectively b ounds the level of priv acy that can b e ac hieved. In other words, if paymen ts lack priv acy , an y interaction inv olving paymen ts will, to o. Suc h a lac k of priv acy in paymen ts risks desensitising so ciet y , normalising surveillance, and low ering expectations of priv acy in other areas of life. Moreov er, from a data minimisation persp ectiv e [ 39 ], it is also desirable to only pro cess and store the minimal information required for pa yment pro cessing to reduce the impact of data breaches. F or all these reasons, public retail pa yment systems should safeguard priv acy . T ec hnically , this requires tw o steps: First, the communication ﬂows in the netw ork must b e anonymised. It is not suﬃcien t to hide the sender and recipient identiﬁers if their communication remains visible (see Fig. 1 e). Second, the amoun t of p oten tially compromising global information must b e minimised. Through the lens of priv acy , it is instructiv e to distinguish tw o wa ys of representing global in- formation. The system may record what can b e sp en t ( p ositive information ) or what has already b een spent and thus must not b e sp en t again ( ne gative information ). An example of p ositiv e information is accoun t balances that are up dated with eac h transaction, implying that the trans- action graph is observ able. In con trast, negativ e information can take the form of nulliﬁers stored whenev er a v alue is sp en t, preven ting double-sp ending (e .g., Chaumian e-cash [ 40 ]). In this case, the transaction graph—except for pathological cases—remains hidden, but the list of nulliﬁers gro ws indeﬁnitely . Reducing global information to the p oin t where the transaction graph can no longer b e reconstructed often means relying on negative information. 1 1 Exceptions exist, e.g. transactions in zkLedger [ 41 ] up date all p ositiv e global information via Pedersen com- mitments and zk-proofs. 4 3 T ec hnical Design Categories In this section, we describ e the framework that deﬁnes the lens through whic h we compare the pa yment designs prop osed in the literature and the columns of our comparison tables 2 and 3 . W e can broadly classify the categories into system ar chite ctur e (Section 3.1 ), assumptions and trust (Section 3.2 ), privacy (Section 3.3 ), c omplianc e (Section 3.4 ), p erformanc e (Section 3.5 ), and te chnic al fe atur es with implic ations for the user exp erienc e (Section 3.6 ). W e discuss the classes and their categories in this order, noting that some forward references are unav oidable as many prop erties are interdependent. 3.1 System Architecture In this category , we capture the main design choices. Since terms such as ac c ount mo del , UTXO mo del , and token are often used am biguously and inconsistently in the literature, w e in tro duce no vel criteria for system comparison. 2 In Section 3.1.1 , w e revisit our classiﬁcation of global information into p ositiv e and negativ e information. Section 3.1.2 discusses how the integrit y of this global information is ensured, while Section 3.1.3 examines who can access or observe it. W e then address the communication required to p erform a paymen t (Section 3.1.4 ) and, ﬁnally , the distributed systems asp ects of the design (Section 3.1.5 ). 3.1.1 Information In Section 2 we introduced the terms lo c al information , needed to authorise a paymen t, and glob al information , required to v alidate it. Recall that w e can further classify global information into: 1. Positive information , whic h allo ws the system to verify the existence of v alue. If v alue is sp en t, the corresp onding entry of p ositive information must b e up dated or deleted. 2. Ne gative information , whic h allows the system to detect the non-existence of v alue. If v alue is sp en t, negative information m ust b e added. Negativ e information is not up dated or deleted. P ositive information can b e more compact, but comparing diﬀerences b et ween states ma y reveal the transaction graph, i. e., who has paid whom. Negativ e information do es not reveal the trans- action graph, but has the downside that the amoun t of global information gro ws forever. Systems can combine b oth types of global information. 3.1.2 In tegrity of Global Information Man y systems distribute the global information across sev eral en tities and infrastructures. As information propagates through the netw ork at diﬀeren t sp eeds and across v arying distances, transien t faults can cause entities to hold inconsisten t views of the global information. Suc h discrepancies can enable double-sp ending attacks , where an adv ersary exploits stale or inconsistent system states to deceive a victim into accepting a transaction that later prov es inv alid [ 49 ]. T o mitigate these inconsistencies, systems diﬀer in ho w they co ordinate and, in particular, order transactions across entities. W e distinguish: 1. T otal or der (TO), where all op erators r e ach agr e ement on the same order of transactions, i.e., they are linearised in to a consisten t log. This requires relying on a centralised system op erator or distributed computing primitives such as c onsensus [ 50 ] or atomic br o adc ast / total or der br o adc ast [ 51 ]. W e do not distinguish whether the agreemen t on a total order is reached deterministically or even tually , and whether the mechanism is supp orted with incentiv es. 3 2 The notions of tokens and accounts are highly ov erloaded and hav e b een deﬁned in diﬀerent wa ys. F or example, a working pap er of a central bank [ 42 ] classiﬁes Bitcoin as account-based in order to p osition e-cash as token-based. By contrast, the cryptocurrency community distinguishes betw een UTXO and account models [ 43 – 45 ], while referring to accounts managed b y smart contracts as “tokens” [ 46 , 47 ]. The confusion increases further when hardware tokens as authen tication devices are included in the discussion. In card paymen t systems, “tokenization” has yet another meaning, namely the practice of hiding account identiﬁers from merchan ts [ 48 ]. 3 W e refer the reader to [ 52 , 53 ] for further details on consensus. 5 2. No total or der (NTO), where the ordering requiremen t for transactions is relaxed and do es not require a global total ordering. 4 In this setting, double-sp en t funds—whether due to error or malicious inten t—b ecome unsp endable [ 55 ]. Under the assumption that participants prefer not to lose funds, this is an incentiv e mechanism that discourages double-sp ending. T otal order can provide strong consistency guaran tees and prev ent double-spending; how ev er, it generally incurs comm unication and computational ov erhead. Recent w orks [ 54 , 56 ] propose a delaye d total or der approach, where agreemen t is perio dically inv oked after an epo c h. This com bines the throughput of NTO with the stronger guarantees of TO, ensuring that no funds are p ermanen tly lost. F or example, PEReDi [ 57 ] follows this approac h b y in voking Byzantine agreemen t when a user requests an ab ort. In T able 2 , this is denoted with o cc. TO. Indep enden t of the total order prop ert y , global information can b e shar de d horizontally to impro ve p erformance. Sharding in tro duces additional integrit y requiremen ts and can increase proto col complexity . F urther discussion is provided in App endix E . 3.1.3 Visibilit y of Global Information and History Systems diﬀer in how widely the state is shared and whether historical states are retained. W e distinguish: 1. Private ( ¿ ) refers to a distributed database in whic h only op erators ha ve read access to individual records and can up date them as sp eciﬁed in the previous subsection. Not all op erators may hav e access to all records. Historical records are not required for the op eration, and it remains at the discretion of the op erators to delete them. 2. Private, app end-only ( ¿ + ) refers to the sp ecial case of a database distributed b et ween the op erators, where transactions can b e app ended, but existing records are never mo diﬁed. App end only databases are often called “ledgers” 5 . There is no exp ectation that historical records are deleted. 3. Public (  ) means that any one can receive all state up dates. Since deletion of information cannot b e enforced for an op en set of participan ts, this implies that the history of all trans- actions is public, but not necessarily in plaintext. F rom a visibility persp ectiv e, we assume that public global information is implicitly app end-only . 3.1.4 Comm unication Comm unication is a fundamental asp ect of any pa yment system. Diﬀerent use cases may fav our diﬀeren t communication relations. While sender and recipient may interact at the p oin t of sale, this is impractical for asynchronous paymen ts, such as inv oices. W e represent communication types using triangular icons, where the b ottom-left no de denotes the sender, the b ottom-righ t the recipient, and the top the op erator. Lines b et ween no des imply that comm unication on this relation is necessary to pro cess a pa yment. Lines b et w een nodes indicate mandatory comm unication links; dashed lines indicate deferrable comm unication (b). Icons (c) and (d) illustrate distributed operators, with (d) requiring in ter-op erator comm unication. In these cases, direct communication with the recipient is not required to up date the global information. Nevertheless, the recipient m ust access the global information in order to obtain the up dated state. (a) (b) (c) (d) Examples of these communication types are provided in App endix B . 4 This is in particular applicable to asset transfer, whic h facilitates concurrent processing. See [ 54 ] for cases where total order is required. 5 In the literature, ledgers are often implicitly assumed to be app end-only . W e hereby explicitly imply ledgers to be app end-only . 6 3.1.5 Net work and Distributed System Mo del P aymen t systems are inherently distributed. Comm unication dela ys and comp onen t failures can compromise the integrit y of global information, which makes it essential to understand the envi- ronmen t in which the paymen t system op erates as intended, referred to as the distribute d system mo del . This mo del sp eciﬁes the assumed properties of the communication net work and the failure b eha viour of system comp onen ts and entities (see Section 3.2.4 ). When designing and reasoning ab out distributed systems, abstractions and simpliﬁcations are necessary to mo del their components and the real-w orld en vironment in whic h they op erate. These abstractions help fo cus on the core problems that require formal solutions [ 58 ]. F or instance, a pa yment system design may assume reliable comm unication c hannels or allow users to behav e arbitrarily . These assumptions determine which fundamental distributed computing problems are solv able and which are not. It is therefore essential that pap ers deﬁne their system mo del. Many prop osed designs omit or insuﬃciently describ e their system mo del, whic h can cause discrepancies b et w een design and implementation and lead to vulnerabilities or loss of desired prop erties. F or this reason, we record for each design the level of detail provided ab out the distribute d system mo del : # indicates no description, G # a basic mo del, and a detailed one. Second, we analyse the netw ork mo del for each of the paymen t designs. First, we determine whic h mo del of synchron y the inter-operator communication assumes. 1. Synchr onous (S): There is a kno wn upp er b ound for the netw ork delay that alwa ys holds. 2. Partial ly synchr onous (PS): Assumption of a global stabilisation time (GST), after whic h message delays remain b ounded [ 59 ]. 3. Asynchr onous (A): There can b e unbounded delay b et ween sending and receiving a message. F urther, w e ev aluate whether an y of the comm unications necessary for a pa yment require anonymous communication to preserve the lev el of priv acy promised b y the design. Here w e distinguish: (a) anon ymous communication betw een the users (sender and the recipien t) is neces- sary , (b) anonymous communication b et ween users and op erators is necessary , or (c) anonymous comm unication b etw een b oth the users themselves and b etw een users and op erators is necessary . (a) (b) (c) 3.2 Assumptions and T rust No practical system can b e secure against all conceiv able adv ersaries. Meaningful security guaran- tees require clearly stated assumptions deﬁning the conditions under which they hold [ 60 , Chap- ter 1.4]. Man y paymen t systems rely on a broad range of assumptions. These include mathematical and sp eciﬁcally cryptographic assumptions, deﬁning which computations are infeasible, such as the discrete logarithm or Diﬃe–Hellman assumptions. Systems may also rely on physical assumptions that reﬂect ph ysical limitations, such as the non-existence of a practical quantum computer or sp eciﬁc hardw are limitations. Beha vioural assumptions sp ecify how parties, suc h as op erators and users, are exp ected to act. Commonly , this includes a subset of op erators required to b e honest and follo w the proto col. Relying on strong assumptions can simplify or even render a design p ossible; how ever ensuring that these guaran tees hold can b e diﬃcult to achiev e in practice. In order to relax the assumptions, additional measures can b e employ ed. F or example, Byzan tine fault tolerance allows weak ening honest y assumptions, such that a bounded subset of op erators ma y b eha v e arbitrarily . While these measures can allo w a system to operate in more hostile en vironments, they ma y negativ ely impact other prop erties, mainly p erformance. W e therefore compare pa yment designs b y the assumptions they rely on. Sp eciﬁcally , we selected assumptions that impact p erformance. First, we discuss reliance on a truste d setup (Sec- tion 3.2.2 ), which may impro ve p erformance since man y eﬃcient zero-knowledge proof systems dep end on it. Next, w e examine truste d har dwar e (Section 3.2.3 ), which can improv e p erformance 7 b y replacing cryptographic op erations. Finally , we analyse b eha vioural assumptions related to system op eration (Section 3.2.4 ), issuance (Section 3.2.5 ), and priv acy rev o cation (Section 3.2.6 ). Stronger behavioural assumptions can improv e eﬃciency , while mechanisms to tolerate misbe- ha viour may reduce it. 3.2.1 Securit y Pro of and T yp e of Evidence This category indicates whether a pap er oﬀers a securit y pro of for at least one claimed prop erty of the pa yment system. The mark designates that a proof is present, but it does not mean that we hav e veriﬁed it. W e further record the pr o of p ar adigm by classifying the type of evidence presen ted: 1. Pr o of sketch , a weak form of evidence that requires further analysis; 2. Pr o of-of-c onc ept ( PoC ) , demonstrating functional asp ects of the design 6 ; 3. A deploye d system has been tested in the real-world. It pro vides empirical evidence of functionalit y and some securit y assurance. 4. Game and simulation b ase d pr o ofs , t ypically encompassing selected asp ects of the design; and 5. Universal c omp osability ( UC ) arguments sho wing that the prop osed design can b e deriv ed from an ideal functionality in sev eral steps that are indistinguishable for the adversary [ 62 ]. 7 Pro viding a proof means that the authors ha v e made eﬀorts to design the system according to clearly deﬁned securit y goals, such as realising an ideal functionality . Ho wev er, it do es not neces- sarily translate into real-world assurance of a system’s ov erall securit y . This disconnect has spark ed an ongoing debate within the securit y comm unity ab out the role and limits of formal proofs in practice [ 64 ]. None of the designs reviewed here employ machine-v eriﬁable pro ofs—despite cryp- tographic library developers increasingly promoting them as a means of improving assurance and auditabilit y [ 65 ]. This highlights that there is still a long w ay to go for paymen t proto cols to enjo y the same scrutiny as other core internet proto cols, suc h as T ransport La yer Security (TLS) [ 66 – 70 ]. 3.2.2 T rusted Setup A truste d setup refers to a cryptographic setup phase required for secure op eration. It typically in volv es generating public parameters from priv ate random inputs that must b e deleted afterw ards. This solely refers to the setup phase and does not make any statement about trusted parties in volv ed in the op eration of the paymen t system. An example for a trusted setup is Zcash [ 71 ]. Its zk-SNARKs require a one-time setup to compute public parameters ( pp ) from conﬁden tial inputs. If these inputs are not deleted, the holder could forge pro ofs. In Zcash, this would allo w undetectable creation of money . Zcash mitigates this risk through multi-part y computation (MPC) protocols [ 72 – 74 ] that succeed if at least one of sev eral parties is honest and deletes their input. MPC protocols oﬀer a well-established tec hnique to distribute trust at the exp ense of higher pro cedural complexity . 8 If a design relies on a trusted setup, we mark it with , and with # otherwise. W e classify only private c oin setup s [ 75 ] as trusted. Public c oin 9 setups, such as those in P edersen commit- men ts [ 77 ], rely on public randomness (e. g., a random b eacon) and do not require secret inputs. Bet ween otherwise equiv alent systems, the one without a trusted setup is preferable. 6 A pro of-of-concept typically veriﬁes the capabilities and op erations a design provides (functional prop erties), while omitting most non-functional prop erties, such as security , privacy , or reliability [ 61 ]. 7 This type of evidence includes multi-protocol UC [ 45 ] and approaches inspired by UC [ 63 ]. 8 See W ang et al. [ 75 ] for an ov erview of trusted setup proto cols and recent so-called “ceremonies.” 9 Also referred to as tr anspar ent setups [ 76 ]. 8 3.2.3 T rusted Hardw are Some designs dep end on secure elements, suc h as tamp er-resistan t smart cards [ 78 ], Hardw are Securit y Mo dules (HSMs) [ 79 ], T rusted Platform Mo dules (TPMs) [ 80 , 81 ], or T rusted Execution En vironments (TEEs) [ 82 ]. The security of these truste d har dwar e (TH) comp onen ts dep ends not only on the hardware’s own tamp er-resistance, but also on the behaviour of the manufacturer and the supply chain. W e collect whether trusted hardw are is required or not # . Systems that require trusted hardw are but hav e a fallback mechanism to detect circumv en tion of the trusted hardw are are mark ed with G # . F or example, Pa yOﬀ [ 83 ] enables the retrosp ectiv e detection of double-sp ending during the deferred settlement of oﬄine paymen ts. 3.2.4 T rust in the Op erator The op er ator of a paymen t system is resp onsible for maintaining the state of the global informa- tion. This inv olv es verifying paymen t requests and up dating the global information accordingly , although parts of the op eration can b e delegated to other parties. Since the op erator ultimately decides the global state, it has ﬁnal authority ov er the distribution of v alue in a paymen t system. That is wh y assumptions on the b eha viour of the op erator are essen tial when designing a paymen t system. Man y designs introduce mechanisms to reduce the level of trust required in the operator. This can b e achiev ed by (i) b y distributing the con trol o ver the operation, (ii) by increasing the tolerance against (arbitrary) faults, or (iii) by ensuring that the actions of the op erator(s) are auditable. In some systems, the op erator’s role is distinct from that of the issuer , or from entities resp on- sible for compliance and priv acy revocation. The same three approaches to reduce trust apply to these roles as well, and the icons introduced b elow are used consistently across roles. T able 1: T wo dimensions of trust in the op erator(s) F ault tolerance Distribution None Crash Byzan tine Cen tralised F ederated Decen tralised Distribution of Con trol. Control can b e distributed to reduce reliance on a single trusted part y . W e distinguish: 1. Centr alise d : a single trusted entit y has ﬁnal authority (T able 1 , row 1); 2. F e der ate d : a ﬁxed set of known op erators collectively gov ern state up dates (row 2); 3. De c entr alise d : all participan ts ha ve equal privileges, and there is no distinction b etw een users and op erators (row 3). F ault T olerance. Distribution alone do es not ensure resilience against failures. W e distinguish: 1. Cr ash fault toler anc e : the system keeps operating correctly even if a bounded subset of op erators b ecomes unav ailable (T able 1 , column 2); 2. Byzantine fault toler anc e : the system keeps op erating correctly even if a b ounded subset of op erators acts arbitrarily , which includes inten tionally malicious actions (column 3). 10 10 In this pap er, as w ell as in the literature, the terms malicious and c orrupt are used interc hangeably . 9 F ault tolerance increases resilience by ensuring correct system op eration despite absent or sub- v ersive op erators. This can b e relev ant for currency areas such as the eurozone, where national cen tral banks may act as op erators, but not all of them are entirely free from p olitical inﬂuence. A single, centralised op erator cannot be fault toleran t itself; ho w ever, some components of th e system may still b e, as demonstrated in Pro ject Hamilton [ 84 ]. Auditabilit y of System Integrit y . Auditability , in this context, refers to the capabilit y to v erify that the system op erates according to the predeﬁned rules. This includes ensuring that no v alid transactions are omitted without justiﬁcation. Dep ending on the type of actors who can audit the system, we distinguish whether any p arty can v erify the correct op eration ( 4 ) or whether only the system op er ator(s) can verify the correct op eration ( Ó ). Although auditability do es not guaran tee correct operation, it reduces the necessary trust, since p oten tial misb eha viour can b e detected. 3.2.5 T rust in the Issuer While in most cases the operator(s) are also resp onsible for issuing currency units, it is also p ossible to assign the role of issuing new currency units to a dedicated part y , the issuer . The issuer con trols the creation of v alue within the system and thus determines the o verall supply . This role naturally aligns with a central bank in the context of a CBDC. The level of trust in the issuer can b e reduced using the same principles describ ed for the op erator in Section 3.2.4 . W e again use the icons from T able 1 to represent the distribution of control and fault tolerance. F or issuance, auditability refers to the ability to verify new issuance of v alue and to observe the total supply . This improv es transparency and preven ts unnoticed inﬂation. Auditing can b e p erformed b y the public ( 4 ), the system op erator(s) ( Ó ), or a dedicated entit y ( Û ). 3.2.6 T rust in the Priv acy Revocation Priv acy is an imp ortan t asp ect of any CBDC and the resp ectiv e properties will b e describ ed in Section 3.3 . Some systems allow user priv acy to b e revok ed in the even t of suspicious b eha viour. W e refer to the en tity resp onsible for this pro cess as the privacy r evo c ation authority . T rust in this authority can b e reduced using the same principles applied to the op erator and the issuer. W e again use the icons from T able 1 to indicate the distribution of con trol and fault tolerance. Auditabilit y of priv acy revocation refers to the ability to detect when a user’s priv acy has b een rev oked. It helps to hold the authority accoun table and detect disproportionate surv eillance. With  we indicate that the aﬀected user can detect this action. Note that priv acy revocation in resp onse to double-sp ending is not considered here, as such revocation can b e necessary to keep the integrit y of the system state. F or designs that do not oﬀer an y priv acy revocation, this column is left empty . 3.3 Priv acy Priv acy is a cen tral concern in the design of a pa yment system. Laws suc h as the GDPR [ 39 ] in Europ e regulate the collection, pro cessing and transfer of personal data, which includes pa y- men t records. While priv acy is a fundamental right that protects individuals from unw arranted surv eillance, it also limits the ability to detect and prosecute fraud, illicit paymen ts, and money laundering. T o balance these opp osing needs, paymen t system designs ha ve historically prop osed v arying degrees of priv acy . It is con venien t to measure the priv acy prop erties of a paymen t system by standardised notions. F or example, Auer et al. [ 10 ] distinguish b et ween anonymity (e. g., some one receives 100 € from someb o dy ), pseudonymity (e. g., pseudon ym A receiv es 100 € from pseudonym B ), and c onﬁdential- ity (e. g., Alice receiv es a transaction from Bob), or combinations thereof. While these notions are intuitiv e for a general audience, they are insuﬃcient to fully assess priv acy b ecause it is not a prop ert y of a single transaction in isolation. As information accumulates o ver time, a set of 10 transactions which initially app ears anonymous can later b ecome pseudonymous. The link abilit y of Monero’s ring signatures is an example of this [ 85 ]. T o address information accumulation, w e follo w Pﬁtzmann and Hansen’s [ 86 ] terminology and adapt it to paymen ts. The strongest priv acy notion is unlink abilit y . In [ 86 , p. 12], it is deﬁned as: “ Unlinkability of two or mor e items of inter est (IOIs) fr om an attacker’s p ersp e ctive me ans that within the system, the attacker c annot suﬃciently distinguish whether these IOIs ar e r elate d or not. ” F or our purp oses, w e take transactions and real-world user iden tities (short: iden tities) as the items of in terest and deﬁne unlink ability in the context of pa yments as follo ws: Unlink abilit y of tw o or more tr ansactions or identities means that an attack er cannot determine whether these tr ansactions or identities are related. 11 Unlink abilit y ma y not b e achiev able due to constraints in the logic of pa ymen ts. Imagine a system with tw o wallets, one of whic h is empt y . The empty w allet can never b e the sender of a transaction. Moreov er, as paymen t systems up date state sequentially , temp oral relations cannot alw ays be hidden. Therefore, we use notions of partial unlink ability to capture the nuances of existing designs. 3.3.1 Iden tity Priv acy A system oﬀers identity privacy if—except for pathological cases—observ ation of the system do es not reveal signiﬁcant information ab out the relation b et ween a real-world identit y and any party in volv ed in a transaction. If this priv acy prop ert y is met for b oth the sender and the recipient, w e denote it by . If this prop ert y is fulﬁlled only for the sender, w e denote it by G # , and if only for the rec ipien t, b y H # . Otherwise, w e denote it b y # . The sp ecial case in which identit y priv acy is ensured for the sender, while for the recipient it is guaran teed only in the case of an oﬄine pa yment, is denoted by H # G # . This corresp onds to the identit y priv acy in a world where bank transfers and cash co exist. Identit y priv acy corresp onds to a notion of pseudonymit y oﬀered by crypto currencies that do not identify parties but reveal the transaction graph, such as Bitcoin and Ethereum. 3.3.2 V alue Priv acy A system oﬀers value privacy 12 if—except for pathological cases—observ ation of the system do es not rev eal signiﬁcan t information ab out the relation betw een the transaction v alues of any tw o transactions (e. g., whether the v alue of transaction A is the same, higher, or lo wer than the v alue of transaction B ). If this prop erty is met, we denote it by . If the v alue of the transaction is not disclosed, but transactions can b e set into a relation based on their v alues, w e denote it as G # . Otherwise, we denote it by # . 3.3.3 User Unlink abilit y A system oﬀers user unlinkability if it cannot b e determined—except for pathological cases— whether the same user is in volv ed in t wo or more transactions as sender or recipien t. If the anon ymity set is the entire set of priv acy-preserving transactions, then this priv acy property is met, and w e denote it by . If unlink ability holds only within a subset of parties inv olved in the transaction, w e refer to it as user subset unlinkability and denote it as G # . Otherwise, we denote it by # . Some paymen t designs sp ecify user unlink ability as the desired level of priv acy , as linking transactions can reveal paymen t patterns and, if a user is deanonymised once, many of their transactions ma y b e linked. How ev er, this level of priv acy mak es compliance c hecks more c hallenging. 11 See [ 87 , 88 ] for formal treatmen ts of unlink ability . 12 Other terms in the literature capturing v alue priv acy are tr ansaction privacy , c onﬁdentiality , or transaction amount obfusc ation . 11 3.3.4 Sender Anon ymity Before, we hav e introduced the concept of iden tity priv acy . This can be ac hieved in t wo wa ys. First, users may hav e long-term iden tiﬁers that are not linked to their real-world identit y . Second, senders remain unknown by cryptographic means, such as in Chaumian e-cash [ 30 ]. T o distinguish these cases, w e in tro duce the notion of sender anonymity . A system provides sender anonymit y if the sender cannot b e determined. If this prop ert y holds, we denote it by . If the sender cannot b e determined within a deﬁned subset, we denote it by G # . If no sender anonymit y is provided, we denote it by # . This is a weak er form of user unlink abilit y . In the literature, sender anonymit y is also referred to as unlink ability [ 89 ]. Their terminology collides with ours. While theoretically p ossible, we do not consider recipien t anonymit y as a category . All systems that oﬀer user unlink ability also pro vide recipient anon ymity , making the distinction unnecessary . 3.3.5 A dversary T o ev aluate whether an y of these priv acy properties hold, w e consider a computationally b ounded adv ersary , sp eciﬁcally a probabilistic p olynomial-time (PPT) adversary , capable of corrupting an y part y except the sender, the recipient, and the authorit y resp onsible for priv acy revocation (if this role exists). Collusion is allow ed up to a num b er smaller than the threshold required for collab orativ e deanon ymisation [ 90 ], whic h w e consider a feature rather than a w eakness. If a design supp orts multiple priv acy levels, we map the strongest p ossible. 3.4 Compliance Ev ery pa yment system m ust comply with the law. The applicable laws and contractual obliga- tions for paymen t system providers are v ast, v ary b et ween jurisdictions, and b ecome even more complicated when paymen ts cross b orders [ 91 ]. While several designs make eﬀorts to enable com- pliance, their features are justiﬁed with abstract assumptions ab out what the law might require. The justiﬁcation often refers to the AML (Anti-Money Laundering) and CFT (Coun tering the Financing of T errorism) regulations implemented in ternationally after the 9/11 attac ks [ 92 ]. The KYC (Kno w Y our Customer) principle is a common measure to supp ort eﬀective AML and CFT b y holding banks resp onsible for having identiﬁers of account holders. The triple of AML, CFT, and KYC is presumably the greatest common denominator across jurisdictions, but b y no means complete. F or example, the regulations of consumer protection, data protection, fraud prev ention, tax enforcement and ﬁnancial stabilit y v ary b y country or economic area, and aﬀect the paymen t system. F or the purp ose of this systematisation, w e distinguish whether the compliance measures apply to the user or the op erator. In this subsection, we fo cus entirely on the approac hes tak en to ensure user compliance. Other mechanisms address operator-related compliance, such as the distribution of con trol, which reduces the pow er of malicious operators, and auditability , whic h enables misb eha viour to b e detected (see Section 3.2.4 ). Priv acy measures can also protect users from op erators and ensure that p ersonal data is handled lawfully (Section 3.3 ). W e further distinguish broadly betw een tw o main approaches to limit undesired b eha viour: (1) detecting non-compliance after the fact in order to create a credible threat of sanction (see Section 3.4.1 ), and (2) preven ting non-compliance through constraints built in to the system (see Section 3.4.2 ). Fig. 2 visualises the feasibilit y of the t wo compliance approac hes as a function of system features. Branches ending at unregulated without passing the detect-and-sanction b o x are not desirable, and p ose a risk of widespread misuse. In some systems, diﬀerent components ma y follow distinct approac hes; for example, Chaumian e-cash implements detect-and-sanction for recipien ts but imp oses no compliance requirements on senders. Consequen tly , it is insuﬃcient to classify a system by a single compliance type. 12 KYC cen tral onboarding? user- indep enden t constrain ts? no unregulated no priv acy? y es detect-and- sanction no rev o cable? y es y es Sybil pro of ? no no user- dep enden t constrain ts? y es no prev ent non- compliance y es y es Figure 2: Compliance approaches for digital paymen t systems based on central onboarding, Sybil resistance, limits, and priv acy . The dotted arrow indicates that b oth approac hes can b e combined. The dashed arrow indicates a weak er form of preven ting non-compliance. 3.4.1 Detection of Non-Complian t Users The detect-and-sanction approach relies on retrosp ectiv e transaction analysis and escalation through legal pro cesses. T o function eﬀectively , it requires a cen tral onboarding, either without priv acy (KYC) or with revocable priv acy to enable reliable user identiﬁcation. A credible threat of sanc- tion may deter abuse. Priv acy-preserving systems can include a mechanism for privacy r evo c ation , where priv acy can b e lifted for the purp ose of detecting non-compliance (e.g. PEReDi [ 57 ], Pa y- Oﬀ [ 83 ]). That is wh y we assess whether a system allows the revocation of user priv acy . W e distinguish b et w een if revocation is possible, # if it is not, DS if it o ccurs only in cases of double-sp ending, and U if the priv acy of honest users may b e uninten tionally revok ed as a side eﬀect of detecting a double-sp ender. Beyond double-sp ending cases, priv acy revocation generally implies the (p oten- tially threshold-based) encryption of sensitive information that an authorised auditing party can decrypt for inv estigations. 3.4.2 Prev enting Non-Compliant User Beha viour The preven tion-based approac h seeks to make non-compliance technically infeasible or highly im- practical. Systems following this mo del often imp ose limits on user activity , suc h as transaction limits, sp ending limits, or maximum account balances. It is p ossible to enforce complex regula- tory constraints without unnecessarily reducing priv acy by using zero-knowledge pro ofs [ 93 , 94 ]. Ho wev er, these metho ds remain diﬃcult to deploy in practice b ecause they are prohibitively slo w with well-established cryptography . F aster v ariants are rather new and arguably hav e not passed the test of time. Systems enforcing user-sp eciﬁc constraints require b oth central onboarding and resistance to Sybils [ 95 ]. Otherwise, users could ev ade restrictions b y creating multiple identi- ties (Sybil attack). By con trast, global constrain ts (e. g., den y lists) do not require any cen tral on b oarding. In practice, limits rarely eliminate misuse entirely , but they do reduce its p oten tial scop e. This applies, for example, to v alue or transaction limits, whic h reduce the amount that can b e misused. 13 W e record whether a system can enforce sending (S), receiving (R), transaction (T), or holding (H) limits. An asterisk ( ∗ ) denotes limits based on predeﬁned budgets rather than range pro ofs. 3.5 P erformance This section deﬁnes categories to ev aluate performances. First, w e fo cus on the av ailabilit y of an implementation (Section 3.5.1 ), and b enc hmark results (S ection 3.5.2 ). Then we highlight the necessit y for making pa yments sequentially as a limiting factor for p erformance (Section 3.5.3 ). 3.5.1 A v ailabilit y of Implemen tations Implemen tations are absolutely necessary to ev aluate p erformance. If the describ ed proto col has b een fully implemented, we indicate this with . If only parts of the proto col hav e b een imple- men ted, w e use G # . If no implementation exists, w e mark it with # . If the implementation is released under an op en-source license, we add the op en-source icon ( ). 3.5.2 Benc hmark Results If a v ailable, we rep ort the order of magnitude of the claimed thr oughput (T x/s) and latency . Throughput is the measure of ho w many transactions a system can pro cess in one second. Latency denotes the time until a transaction is considered conﬁrmed (for probabilistic designs suc h as Bitcoin, we use measurements rep orted in the literature). W e take b enc hmarks corresp onding to the highest priv acy lev el, in line with our priv acy ev aluation. When no real-world deplo yment exists, we rely on the rep orted claims. This is why w e distinguish: • Synthetic b enchmarks (S): Based on simulated workloads appro ximating exp ected through- put and latenc y under typical conditions. Extreme scenarios, such as bulk salary paymen ts, are often omitted, which can lead to ov erestimated p erformance. • Live b enchmarks (L): Based on real-w orld deplo yments rep orting throughput and latency under actual op erational conditions. As the ﬁgures for synthetic b enc hmarks are taken directly from the original sources and are not normalised, we rep ort only rough orders of magnitude. This is relev ant since testing conditions migh t diﬀer substantially with resp ect to hardware, infrastructure, workload, and stress test as- sumptions. As the rep orted ﬁgures span sev eral decades of researc h, the ev olution of hardware capabilities cannot b e ignored. Therefore, the b enc hmarks only s erv e as an indication of p ossible scaling regimes. 3.5.3 Sequen tial Pa ymen ts Allo wing a user to b e in volv ed in more than one pa yment without in volving an operator after eac h, is not only a usability concern but also a key factor inﬂuencing system p erformance. The restriction on b eing inv olv ed in pa yments sequen tially cannot be resolv ed simply b y common scalabilit y techniques, such as distributing the operator’s workload horizon tally . Therefore, we record this constrain t as a p oten tial b ottleneck. W e distinguish: b oth sender and recipien t can participate in only one transaction at a time ( ), only the sender is constrained ( G # ), only the recipien t is constrained ( H # ), paymen ts do not need to b e sequential ( # ). 3.5.4 Global Information Gro wth The c hosen type of global information aﬀects scalability , particularly storage size and search eﬃciency . Designs based on negativ e global information require an ev er-growing list, making searc hes increasingly time consuming as the list expands. Suc h lists are limited by the av ailable memory and the computational resources needed for searching and inserting entries. P erio dic resets b ecome necessary . Ho wev er, they are non-trivial, as they add ov erhead and aﬀect priv acy 14 and usabilit y . T o improv e searc h eﬃciency , data structures, suc h as Bloom [ 96 ], Cuc koo [ 97 ], V acuum [ 98 ] or Quotient ﬁlters [ 99 ] can be used. Other solutions in volv e cleverly choosing the anon ymity set such that negativ e information can b e deleted under deﬁned conditions [ 100 ]. Each pro viding diﬀerent trade-oﬀs in space and p erformance. At an estimated global rate of 110 000 T x/s [ 101 ], a Blo om ﬁlter that is reset annually w ould require ab out 20 TB of memory , illustrating the engineering challenges of n ulliﬁer-based designs (see App endix C for details on our estimation). That is why we capture whether a design has inﬁnitely growing global information ( ), or not ( # ). Note that some designs that use p ositiv e information for the global state, such as blo c kc hains, nev er delete information and therefore hav e an ever-gro wing global state, to o. 3.6 T echnical features with implications for the user exp erience Usabilit y is a key factor in the adoption of paymen t systems [ 102 ], and studies sho w that it can also inﬂuence security [ 103 ]. Most survey ed pap ers, ho wev er, pa y little attention to usability , reﬂecting the early or prototypical stage of many designs. Since explicit usabilit y considerations are largely absen t from the survey ed pap ers, w e instead fo cus on technical features that ma y aﬀect usability at later stages of design developmen t. W e fo cus on the technical features inherent to the pa yment design itself—sp eciﬁcally , whether oﬄine paymen ts are p ossible (Section 3.6.1 ), whether the system allo ws for a single paymen t of exact v alue (Section 3.6.2 ), and whether recipien t inv olvemen t is required (Section 3.6.3 ). User in terface qualit y , k ey or password recov ery , and similar features are excluded, b ecause such asp ects can b e improv ed with supp orting infrastructure. The prop erties discussed here are intrinsic to the paymen t design and cannot easily b e added later. 3.6.1 Oﬄine P aymen t This category captures whether a pa yment system supp orts oﬄine functionality , that is, whether pa yments can b e made without communicating with the system op erator. A k ey attribute of cash is the abilit y to mak e paymen ts oﬄine. A digital v ersion of oﬄine money could preserve some of the b eneﬁts of cash without the physical handling costs. Oﬄine functionality oﬀers sev eral adv an tages. It increases resilience b y allo wing paymen ts during net work or p o w er outages [ 104 ], supp orts ﬁnancial inclusion in regions with p o or connectivity , and can enhance priv acy . F or instance, the ECB suggests that oﬄine digital euro paymen ts could oﬀer cash-like priv acy guarantees [ 105 ]. At the same time, such functionality migh t add to the c hallenges for compliance. W e distinguish three cases: full oﬄine functionality ( ), no oﬄine functionality ( # ), and one-time oﬄine functionality ( G # ). In the latter, paymen ts o ccur without op erator in volv ement, but the recipient must interact with the operator to reuse or exchange the received funds, an approach taken b y early e-cash designs [ 106 ]. 3.6.2 P aying Exact Amounts This category captures whether any amount can b e transferred exactly in a single paymen t. W e indicate this prop ert y as either supp orted ( ) or not supported ( # ). If a system supports pa yments of v arying amounts but only through multiple transactions (few er than in the trivial case of, e. g., issuing 100 units as 100 × 1 ) or if the system restricts paymen ts to sp eciﬁc amounts (e. g., p o w ers of t wo), we denote the prop ert y as G # . 3.6.3 Unin volv ed Recipient W e ev aluate whether the recipien t can remain uninv olv ed in the paymen t pro cess ( ) or must activ ely participate ( # ). If the recipient m ust pro vide input that only they can compute and that diﬀers for eac h paymen t, they are considered to b e in volv ed. Communicating an address or iden tiﬁer once do es not make the recipient in volv ed. If the recipient can remain uninv olv ed, the system b eha ves similarly to push paymen ts, such as wire transfers. 15 4 Results T ables 2 and 3 do cumen t the results of our literature analysis. W e constructed them by applying the categories from the previous section to classify 36 designs for pa yment systems (See App endix A for details on the pap er selection). Besides comparing individual designs, the tables enable us to iden tify four design patterns, presented in Section 4.1 . Section 4.2 pro vides a quantitativ e o verview of the analysed designs p er pattern with resp ect to priv acy , usability , and p erformance prop erties. T able 2: P art 1 of the classiﬁcation of 36 designs according to Section 3 sorted b y y ear of publication. Undesirable prop erties are shown in red. General info System architecture Assumptions and trust Y ear Reference Global information Integrity (global) Visibility (global) Comm. pattern Dist. s. model Sync. model Anon. network Security proof Type of evidence T rusted setup T rusted hardware Operation Issuance Privacy revocation Design pattern 1982 [ 30 ] (Blind Sig.) negative TO ¿ + # # PoC # # Ó Ó T ransfer Digital Coin 1988 [ 106 ] (E-Cash) negative TO ¿ + # # PoC # # Ó Ó T ransfer Digital Coin 1991 [ 107 ] (Oﬀ-line E-Cash) negative TO ¿ + # sketch # # Ó Ó T ransfer Digital Coin 1993 [ 108 ] (TW E-Cash) negative TO ¿ + # sketch # G # Ó Ó T ransfer Digital Coin 1998 [ 109 ] negative TO ¿ + # sketch # # Ó Ó T ransfer Digital Coin 1999 [ 110 ] (Flow Control) negative TO ¿ + # sketch # # Ó Ó T ransfer Digital Coin 1999 [ 111 ] (Auditable E-Cash) both TO  # sketch # # Ó 4 T ransfer Digital Coin 2005 [ 89 ] both TO ¿ + # game # # Ó Ó T ransfer Digital Coin 2008 [ 112 ] (Transferable E-Cash) negative TO ¿ + # game # # Ó Ó T ransfer Digital Coin 2008 [ 29 ] (Bitcoin) positive TO  # # deployed # # 4 4 Burn and Create 2009 [ 113 ] negative TO ¿ + # game # # Ó Ó  T ransfer Digital Coin 2010 [ 114 ] negative TO ¿ + # game # # Ó Ó T ransfer Digital Coin 2013 [ 115 ] (Monero) both TO  # game deployed # # 4 4 Burn and Create 2014 [ 71 ] (Zero cash) both TO  # game deployed # 4 Burn and Create 2014 [ 116 ] (Divisible E-Cash) negative TO ¿ + # game # Ó Ó T ransfer Digital Coin 2014 [ 117 ] (Ethereum) positive TO  # deployed # # 4 4 Global State Update 2015 [ 118 ] negative TO ¿ + # game # Ó Ó T ransfer Digital Coin 2016 [ 93 ] both TO  # game # # 4 4 Burn and Create 2016 [ 119 ] (RSCoin) positive TO  G # S sketch PoC # # 4 4 Burn and Create 2019 [ 120 ] (PRCash) positive TO  G # sketch PoC # # 4 4 Burn and Create 2019 [ 45 ] both TO  G # UC PoC # # 4 4 Burn and Create 2020 [ 121 ] (FastP ay) p ositive NTO ¿ A sketch PoC # # Ó Global State Update 2020 [ 94 ] (PGC) positive TO  # game PoC # # 4 Global State Update 2021 [ 122 ] (Platypus) negative TO ¿ + # game PoC # 4 Ó Local State Update 2021 [ 42 ] (EC1) negative TO ¿ + # # PoC # # Ó Ó T ransfer Digital Coin 2021 [ 123 ] negative TO ¿ + # game # Ó Ó T ransfer Digital Coin 2022 [ 124 ] (EC2) positive TO  # # PoC # 4 4 2022 [ 63 ] (Utt) negative NTO  PS UC PoC # Û Burn and Create 2022 [ 57 ] (PEReDi) negative occ. TO ¿ + A UC # Local State Update 2022 [ 125 ] (Zef ) both NTO ¿ A # PoC # # Ó 2023 [ 126 ] (Parscoin) negative NTO ¿ + G # UC # Local State Update 2023 [ 127 ] negative TO ¿ + # A UC PoC # Ó Ó T ransfer Digital Coin 2023 [ 84 ] (Hamilton) positive TO ¿ G # sketch PoC # # Ó Ó Burn and Create 2024 [ 83 ] (PayOﬀ ) negative NTO  # sketch PoC G # 4  Local State Update 2024 [ 128 ] negative TO ¿ + # game PoC # G # T ransfer Digital Coin 2025 [ 129 ] (PaxPay) b oth NTO ¿ + G # A game PoC # Û  Burn and Create 4.1 Design Patterns Our analysis rev ealed that the design space of all the digital paymen t systems reviewed in this pap er can b e brok en down in to four design patterns: Glob al State Up date , L o c al State Up date , T r ansfer Digital Coin , and Burn-and-Cr e ate . These four patterns capture three fundamental c hoices in system design: how v alue is represented, how a paymen t is authorised, and how it is v alidated. 16 T able 3: P art 2 of the classiﬁcation of 36 designs according to Section 3 sorted b y y ear of publication. Undesirable prop erties are shown in red. General info Priv acy Compliance Performance T echnical features Y ear Reference Identity privacy V alue privacy User unlinkab. Sender anon. Privacy revoc. Limits Impl. av ailable T x/s Latency Type of benchmarks Sequential payments Growing global information Oﬄine payment Exact amount Uninvolv ed recipient 1982 [ 30 ] (Blind Sig.) G # # # # # # # 1988 [ 106 ] (E-Cash) G # # # DS # G # G # # 1991 [ 107 ] (Oﬀ-line E-Cash) H # G # # # # DS # # G # # 1993 [ 108 ] (TW E-Cash) G # # # DS # # G # # # 1998 [ 109 ] G # # # # DS # # G # G # # 1999 [ 110 ] (Flow Control) G # # # # S* # # # # 1999 [ 111 ] (Auditable E-Cash) G # # # DS # H # G # # # 2005 [ 89 ] G # # # DS # # G # # # 2008 [ 112 ] (Transferable E-Cash) H # G # # # DS # # # # 2008 [ 29 ] (Bitcoin) # # # # < 1000 min L # # 2009 [ 113 ] H # G # # # U # # # # 2010 [ 114 ] G # # # DS # # G # G # # 2013 [ 115 ] (Monero) # G # G # # < 1000 min L # # 2014 [ 71 ] (Zero cash) # < 1000 min L # # 2014 [ 116 ] (Divisible E-Cash) G # # # DS # # G # G # # 2014 [ 117 ] (Ethereum) # # # # < 1000 sec L # # 2015 [ 118 ] H # G # # # DS # # # # 2016 [ 93 ] T, S # # # 2016 [ 119 ] (RSCoin) # # # # < 1000 ms S # # 2019 [ 120 ] (PRCash) G # # # # S, R G # > 1000 ms S # # # 2019 [ 45 ] G # # # 2020 [ 121 ] (FastP ay) # # # # # > 100 000 ms S G # # # 2020 [ 94 ] (PGC) G # # # S, R G # G # # 2021 [ 122 ] (Platypus) # H, S, R G # < 1000 S # # 2021 [ 42 ] (EC1) G # # # # > 1000 sec S # # G # # 2021 [ 123 ] H # G # # # DS # # G # # 2022 [ 124 ] (EC2) G # # # # > 1000 sec S # # # # # 2022 [ 63 ] (Utt) # S* > 1000 ms S # # 2022 [ 57 ] (PEReDi) S, R, H, T # # # 2022 [ 125 ] (Zef ) # < 1000 ms S # # 2023 [ 126 ] (Parscoin) # # # 2023 [ 127 ] G # # # DS G # # # G # # 2023 [ 84 ] (Hamilton) # # # # > 1 000 000 ms S # # # 2024 [ 83 ] (PayOﬀ) U H, R, S G # > 100 000 S # # 2024 [ 128 ] H # G # # # G # # G # # 2025 [ 129 ] (PaxPay) # S, T < 1000 ms S # # 17 The most straightforw ard pa yment system design is a mapping where a current balance is assigned to eac h user. A paymen t is executed by up dating the balances of the in volv ed parties accordingly . W e call designs based on this idea Glob al State Up date . Here, v alue is represented by a global state that sp eciﬁes the distribution of v alue (i. e., p ositiv e information), and every paymen t up dates this global state. Authorisation requires a secret, t ypically a priv ate key or kno wledge of creden tials. V alidation inv olv es chec king a signature or credentials, and conﬁrming that the sender has suﬃcient funds according to the global state. If v alidation succeeds, the global state is up dated. This approach corresp onds to the familiar accoun t-based mo del used in the curren t banking system and is also employ ed in crypto currencies, such as Ethereum [ 117 ]. Another approach shifts balance tracking from the op erator to the users, who each maintains their own account record. W e call this pattern L o c al State Up date . F or each transaction, the users up date their local accounts and generate zero-kno wledge proofs showing that the up date is correct, that the previous state was signed by the op erator, and that they are authorised. The new lo cal states remain hidden. The users submit commitments to the op erator, the pro ofs, and references to the previous state. V alidation in volv es verifying the pro ofs and ensuring that the referenced global state has not b een reused, thereby preven ting users from rev erting to earlier states with higher balances. If v alidation succeeds, the op erator signs the new state commitmen t and records the old reference in their list of past states (i. e., negative information). This approac h was ﬁrst prop osed in Platypus [ 122 ] and extended in subsequent work. Earlier v arian ts of this pattern that rely on trusted hardware rather than zero-knowledge pro ofs were used in prepaid card systems in the 1990s, such as Quick in Austria and Geldk arte in Germany . How ev er, these cards could only b e used to sp end funds at paymen t terminals, not to receive them from other cards [ 130 ]. When paying with cash, we simply transfer a piece of pap er or metal. Chaum [ 30 ] brough t this concept into the digital w orld by prop osing a system in which the pay er sends a conﬁdential bit string to the recipient. W e call this pattern T r ansfer Digital Coin . Users obtain a signature on a blinded bit string from the bank, which assigns v alue to it. A paymen t consists of transferring this signed, conﬁden tial bit string to another part y , who can then redeem it at the bank. The bank v eriﬁes the signature and chec ks that the bit string has not already b een redeemed. It the n records the string in a list of redeemed coins (i. e., negative information). A diﬀerent w ay of representing v alue was in tro duced in the Bitcoin whitepap er [ 29 ]. An unsp ent tr ansaction output (UTX O) is a tuple of amoun t and sp ending condition, typically a signature matc hing the o wner’s public key . Crucially , each part y can own m ultiple UTXOs. The global state records all curren tly v alid UTXOs, i. e., p ositiv e information. With each paymen t, one or more UTX Os are remov ed from the global state, or burne d , to create new UTXOs of equal total amoun t, which are added to the global state. W e call this pattern Burn-and-Cr e ate . A paymen t is authorised by fulﬁlling the sp ending condition of the input UTXOs, while v alidation consists of c hecking the signature and ensuring that all input v alues existed prior to b eing burned. A v ariant of this pattern uses p ositive and negativ e information. In this case, a paymen t do es not burn inputs directly but rather commitments to the inputs. A zero-knowledge pro of is required to sho w that the commitments op en to v alid v alues in the global state. V alidation then requires chec king the zero-knowledge pro of and the signature that authenticates spending, as w ell as conﬁrming that the commitments hav e not already b een sp en t. Once v alidated, the burned commitments are added to the list of used commitments (negative information), while the newly created v alues are added to the list of UTX Os (p ositiv e information). This v ariant of Burn-and-Cr e ate w as partially implemen ted in Monero [ 115 ] and later realised in Zero cash [ 71 ]. T wo designs that do not fully ﬁt in to either of the design patterns are Zef [ 125 ] and the second phase of Pro ject T ourbillion [ 124 ]. Zef has a base system that follows the Glob al State Up date , and for anonymous paymen ts, a system resem bling Burn and Cr e ate . EC2 [ 124 ] builds on the T r ansfer Digital Coin pattern, but switc hes from negative to p ositiv e information b y using mixes [ 131 ] instead of blinding the bitstring. While this p ositiv ely aﬀects p erformance, the provided priv acy dep ends solely on the integrit y of the mixes. 18 T able 4: Overview of the design patterns and the share of corresp onding designs that provide the diﬀerent priv acy , technical features and p erformance prop erties. Undesirable properties are mark ed in red. Design pattern Num b er of designs Iden tity priv acy V alue priv acy User unlink abilit y Sender anon ymity Oﬄine pa yment Exact amoun ts Unin volv ed recipien t Inﬁnitely gro wing Sequen tial pa yments Glob al State Up date 3 L o c al State Up date 4 T ransfer Digital Coin 17 Burn and Cr e ate a 4 6 a The tw o ro ws for Burn and Cr e ate show the t wo diﬀerent versions. The one ab o ve is the classic version, like Bitcoin, and the one below uses zk-proofs. 4.2 Quan titativ e P ersp ectiv e T able 4 pro vides an o verview of the relationship b et ween the presen ted design patterns and priv acy , tec hnical features, and p erformance prop erties. First, the table shows the n umber of analysed pap ers b elonging to each category . The table shows the percentage of papers for each design pattern that oﬀer identit y priv acy , v alue priv acy , user unlink ability and sender anonymit y . T w o pies in the Identit y Priv acy column indicate that the identit y priv acy for the sender (left) and the recipien t (right) diﬀer. The strip ed area indicates that identit y priv acy applies only in the case of an oﬄine paymen t. F or v alue priv acy , the striped area corresp onds to pap ers that hide only v alues (see Section 3.3.2 ). F or user unlink abilit y and sender anonymit y , the strip ed areas indicate set unlink abilit y (see Section 3.3.3 and Section 3.3.4 ). Next, the table sho ws the p ercen tage of pap ers within eac h pattern that achiev e the tec hnical features Oﬄine P a yment, Exact Amoun ts and Unin volv ed Recipient. F or the oﬄine category , strip ed areas mean one-time oﬄine functionality (see Section 3.6.1 ). F or exact amounts, they indicate that paymen ts of v arying amounts, but not any amount, are p ossible (see Section 3.6.2 ). Finally , the table shows, for each pattern, the n umber of papers featuring an inﬁnitely growing global state and whether paymen ts are restricted to b e sequential. Striped areas in the sequential paymen t category represent pap ers that imp ose constrain ts on either the sender or the recipient only . The table shows that none of the designs is perfect across properties. Essentially , Glob al State Up date designs lac k priv acy and oﬄine functionality , L o c al State Up date designs still require eﬀorts to improv e p erformance, T r ansfer Digital Coin designs lack priv acy for the recipient and require measures to enable exact pa yments. The Burn and Cr e ate designs either lack priv acy or p erformance, and b oth do not supp ort oﬄine functionality . 19 5 Discussion W e ev aluate the priv acy , technical features with usability-implications and p erformance resulting from the design patterns discussed in Section 4.1 . 5.1 Priv acy Enabled b y the Design P atterns It is con venien t to discuss priv acy along the design patterns b ecause the wa y v alues is represen ted and up dated impacts what information is observ able by the op erator. The Glob al State Up date designs generally cannot hide the transaction graph; therefore, they do not provide user unlink abilit y or sender anonymit y . Designs in this category oﬀer either no priv acy [ 121 ], identit y priv acy [ 117 ], or identit y priv acy combined with v alue priv acy [ 94 ]. The L o c al State Up date designs, when implemen ted with zero-knowledge pro ofs, supp ort all priv acy properties of our framework, namely iden tity priv acy , v alue priv acy , and user unlink abilit y . The T r ansfer Digital Coin designs generally pro vide identit y priv acy for the sender and sender anon ymity . Exceptions are early works [ 107 , 109 ], which fo cused on oﬄine functionalit y and di- visibilit y , resp ectiv ely , and did not provide sender anonymit y . T r ansfer Digital Coin designs that supp ort oﬄine functionalit y ac hieve a stronger level of priv acy , since they also provide identit y priv acy for the recipien t across all oﬄine hops. Finally , the Burn-and-Cr e ate pattern has tw o diﬀeren t priv acy lev els. The original design pattern, as proposed in Bitcoin, cannot hide the transaction graph and only provides identit y priv acy [ 29 , 84 , 119 ] or, in some cases, partial v alue priv acy [ 120 ]. The v arian t combining p ositiv e and negative information supp orts all priv acy prop erties of our framework [ 45 , 63 , 71 , 93 , 129 ]. An exception is Monero [ 115 ], whic h provides set unlink ability and, in its current form [ 132 ], also v alue priv acy . 5.2 Barriers to High P erformance Although latency and throughput dep end on the full set of implementation details, such as the consensus mec hanism (see App endix D ), w e identify some characteristics of the design pattern that impact p erformance. Glob al State Up date systems can b e eﬃcient in principle, in particular when priv acy is limited and there is no latency b y slo w cryptography . In some cases, the sender must make sequential pa yments. As this pattern relies on p ositiv e global information, the global state do es not need to gro w indeﬁnitely . How ever, designs with decentralized op eration hav e higher consensus ov erhead and retain the entire transaction history for trustless v alidation. Hence, not all systems using this pattern hav e high p erformance. L o c al State Up date systems require complex cryptography , such as zero-knowledge pro ofs, and rely on a constantly gro wing global state. While in early designs sequential paymen ts p er user are necessary , Pa yoﬀ [ 129 ] shows that these constraints are not inherent to the pattern. T r ansfer Digital Coin systems can b e built with eﬃcien t cryptograph y , but they require in- ﬁnitely gro wing global information. There are generally no sequential paymen ts necessary , with the exception of [ 111 ], where a recipient can receive only one coin p er ep o c h. The tw o Burn-and-Cr e ate v ariants diﬀer in terms of p erformance. The v ariant with p ositive information promises the b est p erformance of all patterns since the UTXO model can pro cess concurren t paymen ts inv olving the same users in parallel. The v arian t that relies on b oth p ositiv e and negative information uses more complex cryptograph y due to zero-knowledge pro ofs. It also requires an inﬁnitely gro wing global state. As both p ositiv e and negative information con tinue to grow, creating the zero-knowledge pro of b ecomes increasingly exp ensiv e (but at a decreasing rate). Neither sender nor recipien t are restricted to make paymen ts sequentially . W e believe that all four patterns can b e implemen ted in designs that, in principle, can p erform at the scale of a CBDC. Additional p erformance mechanisms, such as sharding (see App endix E ), can facilitate this. L o c al State Up date is the most recen t design pattern and reliable p erformance measuremen ts are missing. 20 5.3 Barriers to Usabilit y W e also ﬁnd a relationship b et ween the design pattern and p ossible technical features (as deﬁned in Section 3.6 ). The literature suggests that systems following the Glob al State Up date pattern cannot supp ort oﬄine paymen ts. On the upside, they allo w paying exact amounts and enable transactions with- out in volving the recipients. Pa yOﬀ [ 129 ] is the ﬁrst (and only) L o c al State Up date design with oﬄine functionalit y . While L o c al State Up date designs enable paying exact amounts, all published systems require that the recipient is inv olved in the transaction pro cess. Many T r ansfer Digital Coin designs provide oﬄine functionality . How ever, pa ying exact amounts remains challenging (see App endix F ). In oﬄine mode, the recipien t m ust be in volv ed. Sanders and T a-Shma [ 110 ] demonstrate that this is not necessary online. The Burn-and-Cr e ate pattern do es not supp ort oﬄine pa yments, whereas paying exact amounts and keeping the recipients uninv olv ed is straight- forw ard. Since all patterns hav e shortcomings, a fully usable CBDC ma y require t wo tec hnical bac kends, one to supp ort oﬄine functionality and a second to handle push pa yments without inv olvemen t of the recipient. Both parts m ust allow paymen ts of exact amoun ts. The online system can b e implemen ted using either the Burn and Cr e ate or the Glob al State Up date pattern. Poten tial candidates for the oﬄine syste m are based on the T r ansfer Digital Coin and L o c al State Up date designs. 6 Conclusion This pap er presents the ﬁrst top-down systematisation of knowledge on paymen t system designs suitable for CBDCs at this lev el of tec hnical depth. Beyond analysing 36 designs, w e deﬁned categories to enable comparison and identiﬁed recurring patterns, challenges, and trade-oﬀs in the curren t state of the art. The main challenges in the design space are as follo ws. Balancing priv acy and compliance seems to b e con tentious [ 20 ], but technical solutions can b e found once the p olicy discussion has conv erged. How ev er, t wo op en problems remain. First, no system oﬀering more than identit y and v alue priv acy has yet demonstrated scalability in practice. Second, the developmen t and rollout of a reliable, priv acy-preserving iden tity system—which is needed to enforce compliance—remains a c hallenge. It requires a strategic decision whether cen tral banks should do this on their own or leverage national digital identit y systems. Quan tum computers exploit the eﬀects of quantum ph ysics to p erform computations eﬃcien tly that are exp ensiv e for classical computers. It remains unclear when this technology will reac h practical application, for instance, to break cryptographic primitives that are currently considered secure. The German F ederal Oﬃce for Information Security (BSI) assumes that this could happ en in the e arly 2030s [ 133 ]. Practical quan tum computers could pose a threat to the priv acy and, ev en more critically , the in tegrity of digital pa yment systems [ 134 ]. Nevertheless, only three analysed designs explicitly mention p ost-quan tum considerations. Pro ject T ourbillon [ 124 ] is the only design with a p ost-quan tum secure fallback, but it performs p oorly in this setting. Research on post- quan tum secure pa yment systems remains insuﬃcien tly explored and unresolved. A CBDC should implemen t a fallback system to ensure integrit y , even in the presence of quantum computers, and it should b e p ossible to upgrade priv acy to p ost-quan tum secure primitives. Another rather underexplored area is oﬄine pa yments. Some T r ansfer Digital Coin designs implemen ted this functionality in the 1990s, alongside trusted-hardware-based systems [ 135 ]. The only design following a diﬀeren t pattern, implemen ting the oﬄine functionality , is P ayOﬀ [ 129 ]. Most imp ortan tly , none of the oﬄine designs analysed in this systematisation hav e been imple- men ted. More researc h in this ﬁeld is needed to iden tify the most suitable design for a CBDC with oﬄine functionality . Finally , a ma jor gap in the ﬁeld is the lack of comparable p erformance measures. Priv acy- friendly paymen t systems with compliance measures ha ve yet to b e implemen ted, as hav e p ost- quan tum secure designs and oﬄine pa ymen ts. Most of these review ed designs originate from 21 academic research, adding new functionality to existing concepts or improving up on them. Au- thors rarely implement and measure full systems, including all comp onen ts required for practical deplo yment. Communication mixes and anonymous net work lay ers are often as sumed, but rarely realised in p erformance b enc hmarks. Some prop osals dep end on underlying arc hitectures, suc h as blo c k chain technology or commercial banking systems. T ranslating a proto col into a practical sys- tem is challenging when key assumptions, such as synchron y , reliability , or trust, remain implicit or unsp eciﬁed. Moreo ver, none of the designs we analysed employ machine-v eriﬁable pro ofs, ren- dering their securit y guarantees un veriﬁable without implemen tation. How ev er, the c hallenge do es not end when a system is implemented. Man y b enc hmarks provided b y designs with p erformance data may not reﬂect real-world retail usage, such as seasonal p eaks around public holidays. Of the 36 analysed, only 15 pro vide p erformance measurements, including b enc hmarks and, in most cases, latency . F our of the designs are deploy ed cryptocurrencies; the remaining ones are syn thetic b enc hmarks tailored to the sp eciﬁc design. T o the b est of our knowledge, there is no standardised transaction dataset av ailable for benchmarking paymen t systems, suc h as retail CBDCs. Suc h a dataset w ould be essen tial for making reliable and repro ducible comparisons, especially when assessing the p erformance of priv acy-fo cused designs. CBDCs are a new form of digital money with broad so cietal and economic impact. If there is one thing this SoK has shown then it is the complexity of the problem and the breadth of the design space. In the absence of a universally accepted deﬁnition of a CBDC, it is impossible for this w ork to presen t the single p erfect CBDC design. What an appropriate CBDC lo oks lik e dep ends fundamen tally on the policy ob jectives. Many of the prop osals analysed in this work might serve as a p oten tial stepping stones to wards future CBDC systems. As seen with TLS, which ev olved o ver decades to reac h to da y’s robustness, CBDCs will also require con tinuous reﬁnement. Progress will dep end on iterative, transparent developmen t informed b y real-world deploymen t and feedbac k. W e b eliev e that suc h an approach is essential for creating secure, resilien t, and widely trusted digital currencies. A c kno wledgmen t J. S. and R. B. thank the Austrian Research Promotion Agency (FFG) for funding our research pro ject “DeFiT race” and the Anniversary F und of the Oesterreichisc he Nationalbank for supp orting the researc h pro ject on “Priv acy and the F unctions of Digital Money ,” pro ject num b er 18613. All authors thank V erena Lac hner, Kristina Magn ussen and Martin Summer for pro viding useful commen ts on earlier drafts of this pap er. References [1] Y. Mersch, “Money and priv ate currencies: reﬂections on Libra,” Speech at the ECB Legal Conference, F rankfurt am Main, Sep. 2019. [2] G. Leibbrandt and N. De T eran, The Pay Oﬀ: How Changing the W ay W e Pay Changes Everything . London, UK: Elliott & Thompson Limited, 2021. [3] P . Cip ollone, “Shifting paymen t landscap e – what a digital euro will bring,” Sp eec h at Bank of Slo venia, Ljubljana, Jul. 2025. [4] A. Di Iorio, A. Kosse, and I. Mustaﬁ, “And so we pay: More digital and faster, with cash still in pla y ,” CPMI Brief no. 8, Bank for In ternational Settlemen ts and Committee on P aymen ts and Market Infrastructures, 2025. [5] A. Kosse and I. Mattei, “Making headwa y – results of the 2022 BIS survey on central bank digital currencies and crypto,” BIS Papers no. 136, Bank for In ternational Settlemen ts, 2023. 22 [6] J. Aurazo, H. Bank a, J. F rost, A. K osse, and T. Piv eteau, “Cen tral bank digital currencies and fast paymen t systems: Riv als or partners?” BIS P ap ers no. 151, Bank for In ternational Settlemen ts, 2024. [7] BIS Innov ation Hub, Swiss National Bank, SIX, “Pro ject Helvetia: A multi-phase in vestigation on the settlemen t of tok enised assets in central bank money ,” 2023. [8] “ CBDC track er,” https://cbdctrack er.org, 2025, accessed: 2025-11-06. [9] Y.-A. de Montjo y e, L. Radaelli, V. K. Singh, and A. S. Pen tland, “Unique in the shopping mall: On the reidentiﬁabilit y of credit card metadata,” Scienc e , vol. 347, no. 6221, pages 536–539, 2015. [10] R. Auer, R. Böhme, J. Clark, and D. Demirag, “Mapping the priv acy landscap e for cen tral bank digital currencies,” Communic ations of the ACM , vol. 66, no. 3, pages 46–53, 2023. [11] Financial Action T ask F orce (F A TF), “In ternational standards on combating money laundering and the ﬁnancing of terrorism and proliferation: The F A TF recommendations,” 2012. [12] P aymen t and Settlement Systems Department, Bank of Japan, “Central bank digital currency exp erimen ts progress on the pilot program,” 2024. [13] Europ ean Central Bank, “Annex 1: F unctional and non-functional requiremen ts link ed to the mark et research for a p oten tial digital euro implementation,” 2023. [14] R. J. Garratt and M. R. C. v an Oordt, “Priv acy as a public go o d: A case for electronic cash,” Journal of Politic al Ec onomy , vol. 129, no. 7, pages 2157–2180, 2021. [15] S. Preibusch, T. Peetz, G. Acar, and B. Berendt, “Shopping for priv acy: Purchase details leak ed to paypal,” Ele ctr onic Commer c e R ese ar ch and Applic ations , v ol. 15, pages 52–64, 2016. [16] R. Arora, H. Du, R. A. Kazmi, and D.-P . Le, “Priv acy-enhancing technologies for CBDC solutions,” Staﬀ Discussion Paper no. 2025-1, Bank of Canada, 2025. [17] G. T. Vives, M. Virza, R. Y oungblom, F. C. Calabia, N. V aughan, Z. Said et al. , “Enhancing the priv acy of a digital Pound,” Bank of England and Massach usetts Institute of T echnology Digital Currency Initiative, 2024. [18] K. Asro w and S. Samonas, “Priv acy enhancing tec hnologies: Categories, use cases, and considerations,” Fintec h Edge Sp ecial Rep ort, F ederal Reserve Bank of San F rancisco, 2021. [19] Europ ean Central Bank and Bank of Japan, “Balancing conﬁdentialit y and auditability in a distributed ledger environmen t,” STELLA - joint research pro ject of the Europ ean Central Bank and the Bank of Japan, 2020. [20] R. Auer, R. Böhme, J. Clark, and D. Demirag, “Priv acy-enhancing technologies for digital pa yments: mapping the landscap e,” BIS W orking Papers no. 1242, Bank for In ternational Settlemen ts, 2025. [21] C. Baum, J. H. Chiang, B. David, and T. K. F rederiksen, “ SoK: Priv acy-enhancing tec hnologies in ﬁnance,” in Confer enc e on A dvanc es in Financial T e chnolo gies (AFT) , J. Bonneau and S. M. W ein b erg, Eds., pages 12:1–12:30, ser. LIPIcs, v ol. 282. Dagstuhl, DE: Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2023. [22] M. Nardelli, F. D. Sclavis, and M. Iezzi, “A hitchhik er’s guide to priv acy-preserving crypto currencies: A survey on anon ymity , conﬁden tiality , and auditabilit y ,” A v ailable at arXiv: https://arxiv.org/abs/2505.21008, 2025. 23 [23] P . Chatzigiannis, F. Baldim tsi, and K. Chalkias, “ SoK: Auditability and accoun tabilit y in distributed paymen t systems,” in Confer enc e on Applie d Crypto gr aphy and Network Se curity (ACNS) , K. Sako and N. O. Tipp enhauer, Eds., pages 311–337, ser. Lecture Notes in Computer Science, vol. 12727. Springer, 2021. [24] I. Agur, A. Ari, and G. Dell’Ariccia, “Designing central bank digital currencies,” Journal of Monetary Ec onomics , v ol. 125, pages 62–79, 2022. [25] R. Auer and R. Böhme, “Central bank digital currency: The quest for minimally inv asiv e tec hnology ,” BIS W orking Papers no. 948, Bank for In ternational Settlements, 2021. [26] S. Allen, S. Čapkun, I. Eyal, G. F anti, B. A. F ord, J. Grimmelmann et al. , “Design c hoices for cen tral bank digital currency: Policy and tec hnical considerations,” NBER W orking P ap er no. 27634, National Bureau of Economic Research, 2020. [27] J. Kiﬀ, J. Alwazir, S. Davido vic, A. F arias, A. Khan, T. Khiaonarong et al. , “A survey of research on retail central bank digital currency ,” IMF W orking Paper no. 20/104, In ternational Monetary F und, 2020. [28] M. L. Bec h and J. Hanco c k, “Innov ations in paymen ts,” BIS Quarterly R eview , pages 21–36, Mar. 2020. [29] S. Nak amoto, “Bitcoin: A p eer-to-peer electronic cash system,” 2008, white pap er. [30] D. Chaum, “Blind signatures for un traceable paymen ts,” in A dvanc es in Cryptolo gy - CR YPTO , pages 199–203. Plen um Press, New Y ork, 1982. [31] C. Borio, “On money , debt, trust and central banking,” BIS W orking Paper no. 763, Bank for In ternational Settlements, 2019. [32] Bank for In ternational Settlemen ts, “Promoting global monetary and ﬁnancial stabilit y ,” BIS Annual Rep ort, 2024/25. [33] J. Hick s, Critic al Essays in Monetary The ory . London, UK: Clarendon Press, 1967. [34] N. R. Kocherlak ota, “Money is memory ,” Journal of Ec onomic The ory , vol. 81, pages 232– 251, 1998. [35] C. M. Kahn, J. McAndrews, and W. Rob erds, “Money is priv acy ,” International Ec onomic R eview , v ol. 46, no. 2, pages 377–399, 2005. [36] A. Hannák, G. Soeller, D. Lazer, A. Mislo ve, and C. Wilson, “Measuring price discrimination and steering on e-commerce web sites,” in Internet Me asur ement Confer enc e (IMC) , pages 305–318. ACM, 2014. [37] A. Acquisti and H. R. V arian, “Conditioning prices on purchase history ,” Marketing Scienc e , v ol. 24, no. 3, pages 367–381, 2005. [38] M. Möser, R. Böhme, and D. Breuk er, “T ow ards risk scoring of bitcoin transactions,” in Financial Crypto gr aphy and Data Se curity Confer enc e (F C) , R. Böhme et al. , Ed., pages 16–32, ser. Lecture Notes in Computer Science, v ol. 8438. Berlin Heidelb erg, DE: Springer, 2014. [39] “ Regulation (EU) 2016/679 of the European P arliament and of the Council of 27 April 2016 on the protection of natural p ersons with regard to the pro cessing of personal data and on the free mov emen t of such data, and rep ealing Directive 95/46/EC (General Data Protection Regulation),” Oﬃcial Journal of the Europ ean Union, L 119, pp. 1-88, 2016. [40] D. Chaum, “Security without identiﬁcation: T ransaction systems to make big brother obsolete,” Communic ations of the ACM , v ol. 28, n o. 10, pages 1030–1044, 1985. 24 [41] N. Narula, W. V asquez, and M. Virza, “ zkLedger: Priv acy-preserving auditing for distributed ledgers,” in Symp osium on Networke d Systems Design and Implementation (NSDI) , pages 65–80. USENIX Asso ciation, 2018. [42] D. Chaum, C. Grothoﬀ, and T. Moser, “How to issue a central bank digital currency ,” SNB W orking Papers 3/2021, 2021. [43] V. Buterin, “Thoughts on UTX Os,” h ttps://medium.com/@Consensys/ though ts- on- utxo- b y- vitalik- buterin- 2bb782c67e53, 2016, accessed: 2025-09-15. [44] J. Zahnen tferner, “Chimeric ledgers: T ranslating and unifying utxo-based and accoun t-based crypto currencies,” A v ailable at IARC Cryptol. ePrin t Arc h.: https: //eprin t.iacr.org/2018/262, 2018. [45] E. Androulaki, J. Camenisc h, A. D. Caro, M. Dub o vitsk a ya, K. Elkhiy aoui, and B. T ackmann, “Priv acy-preserving auditable token paymen ts in a permissioned blo c kc hain system,” in Confer enc e on A dvanc es in Financial T e chnolo gies (AFT) , pages 255–267. A CM, 2020. [46] F. V ogelsteller and V. Buterin, “ ERC-20: T oken Standard,” https://eips.ethereum.org/ EIPS/eip- 20, 2015, Ethereum Improv ement Prop osal No. 20. Accessed: 2025-10-04. [47] G. W ang and M. Nixon, “ SoK: T ok enization on blo ck c hain,” in Confer enc e on Utility and Cloud Computing Comp anion (UCC) . Asso ciation for Computing Machinery , 2022. [48] Committee on Pa yments and Market Infrastructures (CPMI) and W orld Bank Group and Bank for In ternational Settlemen ts, “P aymen t aspects of ﬁnancial inclusion in the ﬁn tech era,” CPMI Papers no. 191, 2020. [49] N. Stifter, A. Judmay er, P . Schindler, and E. W eippl, “Opp ortunistic algorithmic double- sp ending: Ho w i learned to stop worrying and lo ve the fork,” in Eur op e an Symp osium on R ese ar ch in Computer Se curity (ESORICS) , pages 46–66. Springer, 2022. [50] M. C. Pease, R. E. Shostak, and L. Lamp ort, “Reac hing agreement in the presence of faults,” Journal of the ACM , vol. 27, no. 2, pages 228–234, 1980. [51] F. Cristian, H. Aghili, H. R. Strong, and D. Dolev, “Atomic broadcast: F rom simple message diﬀusion to byzan tine agreement,” Information and Computation , vol. 118, no. 1, pages 158–179, 1995. [52] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P . McCorry , S. Meiklejohn et al. , “ SoK: Consensus in the age of blo c kc hains,” in Confer enc e on A dvanc es in Financial T e chnolo gies (AFT) , pages 183–198. ACM, 2019. [53] J. A. Gara y and A. Kia yias, “ SoK: A consensus taxonomy in the blo c kc hain era,” in The Crypto gr aphers’ T r ack at the RSA Confer enc e (CT-RSA) , S. Jarecki, Ed., pages 284–318, ser. Lecture Notes in Computer Science, vol. 12006. Springer, 2020. [54] S. Sridhar, A. Sonnino, and L. K okoris-K ogias, “Stingray: F ast concurren t transactions without consensus,” A v ailable at arXiv: h ttps://arxiv.org/abs/2501.06531, 2025. [55] J. Sliwinski and R. W attenhofer, “ ABC: async hronous blo c kc hain without consensus,” A v ailable at arXiv: h ttps://arxiv.org/abs/1909.10926, 2019. [56] S. Blackshear, A. Ch ursin, G. Danezis, A. Kichidis, L. K okoris-K ogias, X. Li et al. , “Sui Lutris: A blo c kc hain combining broadcast and consensus,” in ACM SIGSAC Confer enc e on Computer and Communic ations Se curity (CCS) , pages 2606–2620. ACM, 2024. 25 [57] A. Kia yias, M. K ohlweiss, and A. Sarenc heh, “ PEReDi: Priv acy-enhanced, regulated and distributed central bank digital currencies,” in ACM SIGSAC Confer enc e on Computer and Communic ations Se curity (CCS) , pages 1739–1752. ACM, 2022. [58] N. A. Lynch, Distribute d Algorithms . San F rancisco, US: Morgan Kaufmann, 1996. [59] C. Dwork, N. A. Lync h, and L. J. Sto c kmeyer, “Consensus in the presence of partial sync hrony ,” Journal of the ACM , vol. 35, no. 2, pages 288–323, 1988. [60] J. Katz and Y. Lindell, Intr o duction to Mo dern Crypto gr aph . New Y ork, US: Chapman and Hall/CRC, 2007. [61] S. Rob ertson and J. Rob ertson, Mastering the R e quir ements Pr o c ess: Getting R e quir ements R ight , 3rd Edition. Boston, US: Addison-W esley Professional, 2012. [62] R. Canetti, “Univ ersally comp osable securit y ,” Journal of the A CM , vol. 67, no. 5, pages 28:1–28:94, 2020. [63] A. T omescu, A. Bhat, B. Applebaum, I. Abraham, G. Gueta, B. Pink as et al. , “ UTT: decen tralized ecash with accountable priv acy ,” A v ailable at IAR C Cryptol. ePrin t Arch.: h ttps://eprint.iacr.org/2022/452, 2022. [64] C. Herley and P . C. v an Oorsc hot, “ SoK: Science, security and the elusive goal of security as a scien tiﬁc pursuit,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 99–120. IEEE Computer So ciet y , 2017. [65] M. Barbosa, G. Barthe, K. Bharga v an, B. Blanc het, C. Cremers, K. Liao et al. , “ SoK: Computer-aided cryptography ,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 777–795. IEEE, 2021. [66] K. Bhargav an, B. Bond, A. Delignat-La v aud, C. F ournet, C. Ha wblitzel, C. Hritcu et al. , “Ev erest: T ow ards a v eriﬁed, drop-in replacement of HTTPS,” in Summit on A dvanc es in Pr o gr amming L anguages (SNAPL) , B. S. Lerner, R. Bodík, and S. Krishnam urthi, Eds., pages 1:1–1:12, ser. LIPIcs, vol. 71. Sc hloss Dagstuhl - Leibniz-Zentrum für Informatik, 2017. [67] C. Cremers, M. Horv at, J. Hoyland, S. Scott, and T. v an der Merwe, “A comprehensive sym b olic analysis of TLS 1.3,” in ACM SIGSAC Confer enc e on Computer and Communic ations Se curity (CCS) , pages 1773–1788. ACM, 2017. [68] K. Bharga v an, B. Blanc het, and N. K ob eissi, “V eriﬁed models and reference implemen tations for the TLS 1.3 standard candidate,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 483–502. IEEE Computer So ciet y , 2017. [69] G. Arfaoui, X. Bultel, P . F ouque, A. Nedelcu, and C. Onete, “The priv acy of the TLS 1.3 proto col,” Pr o c e e dings on Privacy Enhancing T e chnolo gies (PoPETs) , v ol. 2019, no. 4, pages 190–210, 2019. [70] E. Rescorla, “The transp ort lay er security (TLS) proto col version 1.3,” RFC 8446, Internet Engineering T ask F orce, 2018. [71] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. T romer et al. , “Zero cash: Decen tralized anonymous pa yments from bitcoin,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 459–474. IEEE Computer So ciety , 2014. [72] E. Ben-Sasson, A. Chiesa, M. Green, E. T romer, and M. Virza, “Secure sampling of public parameters for succinct zero knowledge pro ofs,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 287–304. IEEE Computer So ciety , 2015. 26 [73] S. Bo we, A. Gabizon, and I. Miers, “Scalable multi-part y computation for zk-snark parameters in the random b eacon mo del,” A v ailable at IACR Cryptol. ePrint Arch.: h ttps://eprint.iacr.org/2017/1050, 2017. [74] S. Bow e, A. Gabiz on, and M. D. Green, “A multi-part y proto col for constructing the public parameters of the pino cchio zk-snark,” in Financial Crypto gr aphy and Data Se curity. F C International W orkshops , A. Zohar et al. , Ed., pages 64–77, ser. Lecture Notes in Computer Science, vol. 10958. Springer, 2018. [75] F. W ang, S. Cohney , and J. Bonneau, “ SoK: T rusted setups for pow ers-of-tau strings,” A v ailable at IACR Cryptol. ePrint Arc h.: h ttps://eprint.iacr.org/2025/064, 2025. [76] B. Bünz, B. Fisch, and A. Szepieniec, “T ransparent snarks from DARK compilers,” in A dvanc es in Cryptolo gy - EUROCR YPT , A. Can teaut and Y. Ishai, Eds., pages 677–706, ser. Lecture Notes in Computer Science, vol. 12105. Springer, 2020. [77] T. P . Pedersen, “Non-interactiv e and information-theoretic secure veriﬁable secret sharing,” in A dvanc es in Cryptolo gy - CR YPTO , J. F eigenbaum, Ed., pages 129–140, ser. Lecture Notes in Computer Science, vol. 576. Springer, 1991. [78] W. Rankl and W. Eﬃng, Smart c ar d handb o ok , 4th Edition. Hob ok en, US: Wiley , 2010. [79] M. Sommerhalder, “Hardware securit y module,” in T r ends in Data Pr ote ction and Encryption T e chnolo gies . Springer Nature Switzerland, 2023, pages 83–87. [80] A. T omlinson, “Introduction to the TPM,” in Smart Car ds, T okens, Se curity and Applic ations , 2nd Edition. Springer, 2017, pages 173–191. [81] T rusted Computing Group, “ TPM 2.0 library sp eciﬁcation,” https:// trustedcomputinggroup.org/resource/tpm- library- sp eciﬁcation/, 2019, accessed: 2025- 11-14. [82] M. Sabt, M. A chemlal, and A. Bouab dallah, “T rusted execution en vironment: What it is, and what it is not,” in Confer enc e on T rust, Se curity and Privacy in Computing and Communic ations (T rustCom) , pages 57–64. IEEE, 2015. [83] C. Beer, S. Zingg, K. Kostiainen, K. Wüst, V. Capkun, and S. Capkun, “ Pa yOﬀ: A regulated cen tral bank digital currency with priv ate oﬄine paymen ts,” A v ailable at arXiv: h ttps://arxiv.org/abs/2408.06956, 2024. [84] J. Lov ejo y , M. Virza, C. Fields, K. Karwaski, A. Bro wnw orth, and N. Narula, “Hamilton: A high-p erformance transaction pro cessor for cen tral bank digital currencies,” in Symp osium on Networke d Systems Design and Implementation (NSDI) , pages 901–915. USENIX Asso ciation, 2023. [85] M. Möser, K. Sosk a, E. Heilman, K. Lee, H. Heﬀan, S. Sriv astav a et al. , “An empirical analysis of traceability in the monero blo c kc hain,” Pr o c e e dings on Privacy Enhancing T e chnolo gies (PoPETs) , vol. 2018, no. 3, pages 143–163, 2018. [86] A. Pﬁtzmann and M. Hansen, “A terminology for talking ab out priv acy by data minimiza- tion: Anonymit y , unlink abilit y , undetectabilit y , unobserv abilit y , pseudonymit y , and iden- tit y management,” https://dud.inf.tu- dresden.de/literatur/Anon_T erminology_v0.34.pdf , T echnical Universit y of Dresden, 2010. [87] S. Steinbrec her and S. Köpsell, “Mo delling unlink abilit y ,” in W orkshop on Privacy Enhancing T e chnolo gies (PET) , R. Dingledine, Ed., pages 32–47, ser. Lecture Notes in Computer Science, vol. 2760. Springer, 2003. 27 [88] I. W agner and D. Ec khoﬀ, “T ec hnical priv acy metrics: A systematic survey ,” A CM Computing Surveys (CSUR) , vol. 51, no. 3, pages 57:1–57:38, 2018. [89] J. Camenisch, S. Hohen b erger, and A. Lysyansk a ya, “Compact e-cash,” in A dvanc es in Cryptolo gy - EUROCR YPT , R. Cramer, Ed., pages 302–321, ser. Lecture Notes in Computer Science, vol. 3494. Springer, 2005. [90] P . Keller, M. Florian, and R. Böhme, “Collab orativ e deanon ymization,” in Financial Crypto gr aphy and Data Se curity. FC International W orkshops , M. Bernhard et al. , Ed., pages 39–46, ser. Lecture Notes in Computer Science, vol. 12676. Springer, 2021. [91] M. L. Bec h, U. F aruqui, and T. Shirak ami, “P a yments without borders,” BIS Quarterly R eview , pages 53–65, Mar. 2020. [92] M. Pieth, Editorial: The Financing of T err orism — Criminal and R e gulatory R eform , In: Financing T errorism, pages 1–3. Springer Netherlands, 2002. [93] C. Garman, M. Green, and I. Miers, “A ccountable priv acy for decen tralized anonymous pa yments,” in Financial Crypto gr aphy and Data Se curity Confer enc e (FC) , J. Grossklags and B. Preneel, Eds., pages 81–98, ser. Lecture Notes in Computer Science, vol. 9603. Springer, 2016. [94] Y. Chen, X. Ma, C. T ang, and M. H. Au, “ PGC: decentralized conﬁdential paymen t system with auditability ,” in Eur op e an Symp osium on R ese ar ch in Computer Se curity (ESORICS) , L. Chen, N. Li, K. Liang, and S. A. Schneider, Eds., pages 591–610, ser. Lecture Notes in Computer Science, vol. 12308. Springer, 2020. [95] J. R. Douceur, “The sybil attack,” in Pe er-to-Pe er Systems W orkshop (IPTPS) , pages 251– 260. Springer, 2002. [96] B. H. Blo om, “Space/time trade-oﬀs in hash co ding with allow able errors,” Communic ations of the ACM , vol. 13, no. 7, pages 422–426, 1970. [97] B. F an, D. G. Andersen, M. Kaminsky , and M. Mitzenmac her, “Cuc koo ﬁlter: Practically b etter than Blo om,” in Confer enc e on emer ging Networking Exp eriments and T e chnolo gies (CoNEXT) , pages 75–88. ACM, 2014. [98] M. W ang, M. Zhou, S. Shi, and C. Qian, “V acuum ﬁlters: More space-eﬃcient and faster replacemen t for Blo om and Cuck o o ﬁlters,” Pr o c e e dings of the VLDB Endowment , vol. 13, no. 2, pages 197–210, 2019. [99] P . P andey , A. Conw ay , J. Durie, M. A. Bender, M. F arac h-Colton, and R. Johnson, “V ector quotien t ﬁlters: Overcoming the time/space trade-oﬀ in ﬁlter design,” in Confer enc e on Management of Data (SIGMOD) , pages 1386–1399. ACM, 2021. [100] C. Cachin and F. Wic ht, “T oxic deco ys: A path to scaling priv acy-preserving crypto currencies,” Pr o c e e dings on Privacy Enhancing T e chnolo gies (PoPETs) , vol. 2025, no. 4, pages 926–943, 2025. [101] P . Bruno, U. Jeenah, A. Gandhi, and I. Gancho, “Global pa yments in 2024: Simpler in terfaces, complex realit y ,” h ttps://www.mckinsey .com/industries/ﬁnancial- services/ our- insights/global- pa ymen ts- in- 2024- simpler- in terfaces- complex- reality, McKinsey & Compan y , 2024, accessed: 2025-11-14. [102] N. Mallat, “Exploring consumer adoption of mobile paymen ts – a qualitative study ,” The Journal of Str ate gic Information Systems , vol. 16, no. 4, pages 413–432, 2007. [103] R. Kainda, I. Flec hais, and A. W. Roscoe, “Security and usabilit y: Analysis and ev aluation,” in Confer enc e on Availability, R eliability and Se curity (ARES) , pages 275–282. IEEE Computer So ciet y , 2010. 28 [104] P . de Almeida, P . F azendeiro, and P . R. M. Inácio, “Societal risks of the end of physical cash,” F utur es , vol. 104, pages 47–60, 2018. [105] Europ ean Central Bank, “F requen tly ask ed questions on the digital euro,” https://www. ecb.europa.eu/euro/digital_euro/faqs/h tml/ecb.faq_digital_euro.en.html, 2025, accessed: 2025-07-10. [106] D. Chaum, A. Fiat, and M. Naor, “Untraceable electronic cash,” in A dvanc es in Cryptolo gy - CR YPTO , S. Goldw asser, Ed., pages 319–327, ser. Lecture Notes in Computer Science, v ol. 403. Springer, 1988. [107] T. Ok amoto and K. Oh ta, “Universal electronic cash,” in A dvanc es in Cryptolo gy - CR YPTO , J. F eigen baum, Ed., pages 324–337, ser. Lecture Notes in Computer Science, v ol. 576. Springer, 1991. [108] S. Brands, “Untraceable oﬀ-line cash in w allets with observers (extended abstract),” in A dvanc es in Cryptolo gy - CR YPTO , D. R. Stinson, Ed., pages 302–318, ser. Lecture Notes in Computer Science, vol. 773. Springer, 1993. [109] A. H. Chan, Y. F rankel, and Y. T siounis, “Easy come - easy go divisible cash,” in A dvanc es in Cryptolo gy - EUR OCR YPT , K. Nyb erg, Ed., pages 561–575, ser. Lecture Notes in Computer Science, vol. 1403. Springer, 1998. [110] T. Sander and A. T a-Shma, “Flo w control: A new approach for anonymit y control in electronic cash systems,” in Financial Crypto gr aphy and Data Se curity Confer enc e (FC) , M. K. F ranklin, Ed., pages 46–61, ser. Lecture Notes in Computer Science, vol. 1648. Springer, 1999. [111] ——, “Auditable, anonymous electronic cash extended abstract,” in A dvanc es in Cryptolo gy - CR YPTO , M. J. Wiener, Ed., pages 555–572, ser. Lecture Notes in Computer Science, v ol. 1666. Springer, 1999. [112] S. Canard and A. Gouget, “Anonymit y in transferable e-cash,” in Confer enc e on Applie d Crypto gr aphy and Network Se curity (A CNS) , S. M. Bellovin et al. , Ed., pages 207–223, ser. Lecture Notes in Computer Science, vol. 5037, 2008. [113] G. F uc hsbauer, D. P ointc hev al, and D. V ergnaud, “T ransferable constant-size fair e-cash,” in Cryptolo gy and Network Se curity Confer enc e (CANS) , J. A. Gara y , A. Miya ji, and A. Otsuk a, Eds., pages 226–247, ser. Lecture Notes in Computer Science, vol. 5888. Springer, 2009. [114] S. Canard and A. Gouget, “Multiple denominations in e-cash with compact transaction data,” in Financial Crypto gr aphy and Data Se curity Confer enc e (F C) . Springer Berlin Heidelb erg, 2010, vol. 6052, pages 82–97. [115] N. v an Sab erhagen, “Cryptonote v 2.0,” 2013, white pap er. [116] S. Canard, D. P ointc hev al, O. Sanders, and J. T raoré, “Divisible e-cash made practical,” in Public-Key Crypto gr aphy Confer enc e (PK C) , J. Katz, Ed., pages 77–100, ser. Lecture Notes in Computer Science, vol. 9020. Springer, 2015. [117] V. Buterin, “Ethereum: A next-generation smart contract and decen tralized application platform,” 2014, white pap er. [118] F. Baldim tsi, M. Chase, G. F uc hsbauer, and M. Kohlw eiss, “Anonymous transferable e-cash,” in Public-Key Crypto gr aphy Confer enc e (PKC) , J. Katz, Ed., pages 101–124, ser. Lecture Notes in Computer Science, vol. 9020. Springer, 2015. 29 [119] G. Danezis and S. Meiklejohn, “Centrally banked crypto currencies,” in Network and Distribute d System Se curity (NDSS) Symp osium . The Internet So ciet y , 2016. [120] K. Wüst, K. Kostiainen, V. Capkun, and S. Capkun, “Prcash: F ast, priv ate and regulated transactions for digital currencies,” in Financial Crypto gr aphy and Data Se curity Confer enc e (F C) , I. Goldb erg and T. Mo ore, Eds., pages 158–178, ser. Lecture Notes in Computer Science, vol. 11598. Springer, 2019. [121] M. Baudet, G. Danezis, and A. Sonnino, “F astpa y: High-p erformance byzan tine fault toleran t settlemen t,” in Confer enc e on A dvanc es in Financial T e chnolo gies (AFT) , pages 163–177. ACM, 2020. [122] K. Wüst, K. Kostiainen, N. Delius, and S. Capkun, “Platypus: A central bank digital currency with unlink able transactions and priv acy-preserving regulation,” in ACM SIGSA C Confer enc e on Computer and Communic ations Se curity (CCS) , pages 2947–2960. ACM, 2022. [123] B. Bauer, G. F uchsbauer, and C. Qian, “T ransferable e-cash: A cleaner mo del and the ﬁrst practical instantiation,” in Public-Key Crypto gr aphy Confer enc e (PK C) , J. A. Gara y , Ed., pages 559–590, ser. Lecture Notes in Computer Science, vol. 12711. Springer, 2021. [124] D. Chaum and T. Moser, “ eCash 2.0: Inalienably priv ate and quan tum-resistant to coun- terfeiting,” 2022, unpublished manuscript. A v ailable at https://c haum.com/wp- conten t/ uploads/2022/11/eCash_2.0_9- 7- 22- .p df . [125] M. Baudet, A. Sonnino, M. Kelk ar, and G. Danezis, “Zef: Low-latency , scalable, priv ate pa yments,” in W orkshop on Privacy in the Ele ctr onic So ciety (WPES) , pages 1–16. ACM, 2023. [126] A. Sarencheh, A. Kiayias, and M. Kohlw eiss, “P arscoin: A priv acy-preserving, auditable, and regulation-friendly stablecoin,” in Cryptolo gy and Network Se curity Confer enc e (CANS) , M. K ohlweiss, R. D. Pietro, and A. R. Beresford, Eds., pages 289–313, ser. Lecture Notes in Computer Science, vol. 14905. Springer, 2024. [127] A. Rial and A. M. Piotro wsk a, “Compact and divisible e-cash with threshold issuance,” Pr o c e e dings on Privacy Enhancing T e chnolo gies (PoPETs) , vol. 2023, no. 4, pages 381–415, 2023. [128] E. Androulaki, A. D. Caro, K. Elkhiyaoui, R. Ga y , R. Mercer, and A. Sorniotti, “Secure and priv acy-preserving CBDC oﬄine paymen ts using a secure element,” A v ailable at IARC Cryptol. ePrint Arch.: h ttps://eprint.iacr.org/2024/1746, 2024. [129] M. Brugeres, V. Languille, P . Kuznetso v, and H. Zarfaoui, “F ast, priv ate and regulated paymen ts in asynchronous netw orks,” A v ailable at IARC Cryptol. ePrin t Arc h.: h ttps://eprint.iacr.org/2025/098, 2025. [130] Committee on Pa yments and Mark et Infrastructures (CPMI) and Bank for International Settlemen ts, “Survey of electronic money developmen ts,” CPMI Papers no. 38, 2000. [131] D. Chaum, “Untraceable electronic mail, return addresses, and digital pseudonyms,” Communic ations of the ACM , vol. 24, no. 2, pages 84–88, 1981. [132] Monero Pro ject, “What is monero (XMR)?” h ttps://www.getmonero.org/resources/ researc h- lab/, accessed: 2025-11-07. [133] German F ederal Oﬃce for Information Security , “Quantum-safe cryptography - fundamen- tals, current developmen ts and recommendations,” 2021. 30 [134] R. Auer, A. Dupont, L. Gambacorta, J. S. P ark, K. T ak ahashi, and A. V alk o, “Quan tum computing and the ﬁnancial system: opp ortunities and risks,” BIS Papers no. 149, Bank for In ternational Settlements, 2024. [135] Deutsc he Kredit wirtschaft, “Rund um die GeldKarte,” https://w eb.arc hive.org/w eb/ 20030424103845/h ttp://www.geldk arte.de/ww/de/pub/rund_um_die_geldk arte.h tm, 2003, arc hived on 24 Apr 2003. Accessed: 2025-11-14. [136] Bank for In ternational Settlements, “Pro ject tourbillon demonstrates cash-like anon ymity for retail cb dc,” https://www.bis.org/about/bisih/topics/cb dc/tourbillon.h tm, 2023. [137] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zero coin: Anonymous distributed e-cash from bitcoin,” in IEEE Symp osium on Se curity and Privacy (SP) , pages 397–411. IEEE Computer So ciet y , 2013. [138] D. Chaum, “Priv acy protected paymen ts: Unconditional pay er and/or pay ee untraceabilit y ,” in Smart Car d 2000: The F utur e of IC Car ds . Elsevier Science Publishers B.V., 1989, pages 69–93. [139] T. Ok amoto and K. Ohta, “Disposable zero-kno wledge authentications and their applications to un traceable electronic cash,” in A dvanc es in Cryptolo gy - CR YPTO , G. Brassard, Ed., pages 481–496, ser. Lecture Notes in Computer Science, vol. 435. Springer, 1989. [140] L. Luo, D. Guo, R. T. B. Ma, O. Rottenstreich, and X. Luo, “Optimizing Bloom ﬁlter: Challenges, solutions, and comparisons,” Communic ations Surveys and T utorials , vol. 21, no. 2, pages 1912–1949, 2019. [141] M. Sönmez T uran, R. P erlner, L. E. Bassham, W. Burr, D. Chang, S.-j. Chang et al. , “Third-round rep ort of the SHA-3 cryptographic hash algorithm comp etition,” NIST IR 7896, National Institute of Standards and T ec hnology , 2012. [142] D. J. Bernstein, “Optimization failures in SHA-3 soft ware,” A v ailable at https://cr.yp. to/hash/sha3opt- 20120104.p df , Departmen t of Computer Science, Univ ersity of Illinois at Chicago, 2012. [143] R. Guerraoui, P . Kuznetsov, M. Monti, M. Pa vlo vic, and D. Seredinsc hi, “The consensus n umber of a crypto currency ,” in Symp osium on Principles of Distribute d Computing (PODC) , pages 307–316. ACM, 2019. [144] M. Castro and B. Lisko v, “Practical byzan tine fault tolerance,” in Symp osium on Op er ating Systems Design and Implementation (OSDI) , pages 173–186. USENIX Asso ciation, 1999. [145] C. Stathakopoulou, T. David, M. Pa vlo vic, and M. V uk olic, “ [Solution] Mir-BFT: Scalable and robust BFT for decentralized netw orks,” Journal of Systems R ese ar ch , v ol. 2, no. 1, 2022. [146] C. Berger, S. Sch w arz-Rüsch, A. V ogel, K. Bleeke, L. Jehl, H. P . Reiser et al. , “Sok: Scala- bilit y techniques for bft consensus,” in 2023 IEEE International Confer enc e on Blo ckchain and Crypto curr ency (ICBC) , pages 1–18. IEEE, 2023. [147] B. K. Chou, A. Lewis-Py e, and P . O’Grady , “Minimmit: F ast ﬁnalit y with even faster blo c ks,” A v ailable at arXiv: h ttps://arxiv.org/abs/2508.10862, 2025. [148] Z. Xiang, Z. Li, B. Arun, T. Zhang, and A. Spiegelman, “Zaptos: T o wards optimal blo c kc hain latency ,” A v ailable at arXiv: h ttps://arxiv.org/abs/2501.10612, 2025. [149] M. Herlihy , “W ait-free sync hronization,” A CM T r ansactions on Pr o gr amming L anguages and Systems (TOPLAS) , vol. 13, no. 1, pages 124–149, 1991. 31 [150] M. Camaioni, R. Guerraoui, M. Monti, P . Roman, M. Vidigueira, and G. V oron, “Chop Chop: Byzantine atomic broadcast to the net work limit,” in Symp osium on Op er ating Systems Design and Implementation (OSDI) , pages 269–287. USENIX Asso ciation, 2024. [151] H. Cheng, Y. Lu, Z. Lu, Q. T ang, Y. Zhang, and Z. Zhang, “ JUMBO: F ully asynchronous BFT consensus made truly scalable,” A v ailable at arXiv: h 2024. [152] E. Androulaki, M. Brandenburger, A. D. Caro, K. Elkhiyaoui, L. F unaro, A. Filios et al. , “A framew ork for resilient, transparent, high-throughput, priv acy-enabled central bank digital currencies,” A v ailable at IAR C Cryptol. ePrint Arch.: https://eprin t.iacr.org/2023/1717, 2023. [153] D. Collins, R. Guerraoui, J. Komato vic, P . Kuznetsov, M. Mon ti, M. Pa vlov ic et al. , “Online paymen ts b y merely broadcasting messages,” in Dep endable Systems and Networks (DSN) 2020, V alencia, Sp ain, June 29 - July 2, 2020 , pages 26–38. IEEE, 2020. [154] R. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, D. Malkhi et al. , “ Blo c k-STM: Scaling blo c kc hain execution by turning ordering curse to a p erformance blessing,” in Symp osium on Principles and Pr actic e of Par al lel Pr o gr amming (PPoPP) , pages 232–244. A CM, 2023. [155] R. Neiheiser and E. K okoris-K ogias, “Anthemius: Eﬃcient & mo dular blo c k assembly for concurren t execution,” A v ailable at arXiv: h ttps://arxiv.org/abs/2502.10074, 2025. [156] G. Y u, X. W ang, K. Y u, W. Ni, J. A. Zhang, and R. P . Liu, “Survey: Sharding in blo c k chains,” IEEE A c c ess , vol. 8, pages 14 155–14 181, 2020. [157] G. W ang, Z. J. Shi, M. Nixon, and S. Han, “Sok: Sharding on block chain,” in Confer enc e on A dvanc es in Financial T e chnolo gies (AFT) , pages 41–61, 2019. [158] D. Chaum and T. P . Pedersen, “T ransferred cash grows in size,” in A dvanc es in Cryptolo gy - EUROCR YPT , R. A. Ruepp el, Ed., pages 390–407, ser. Lecture Notes in Computer Science, vol. 658. Springer, 1992. [159] M. Christo dorescu, W. C. Gu, R. Kumaresan, M. Minaei, M. Özdayi, B. Price et al. , “T ow ards a tw o-tier hierarchical infrastructure: An oﬄine paymen t system for central bank digital currencies,” A v ailable at arXiv: h ttps://arxiv.org/abs/2012.08003, 2020. A Metho d In this app endix, we describ e our approach and the pro cedure used to gather relev ant literature, screen it, and select the ﬁnal set of designs for the systematisation. A.1 Approac h The aim of this work is to complement the gro wing n umber of publications reviewing existing PET s as building blo c ks for future paymen t systems, with a systematisation of prop osals for complete systems that leverage priv acy-enhancing features. This helps to form in tuitions on how priv acy features can b e com bined in systems, working around the often-o verlooked problem that PET s are not alwa ys easily comp osable. Reviewing complete systems also allows for a more comprehensive view of the full set of relev ant prop erties, notably p erformance and compliance. Our pro cess inv olved a literature search and selection (Section A.2 ) and an iterative develop- men t of a suitable categorisation. Section 3 do cumen ts the resulting ﬁnal categorisation. The ﬁnal set of 36 systems is mapp ed to the classiﬁcation, leading to the ov erview T ables 2 and 3 that are at the heart of every SoK. In our opinion, not every system in this table is a “CBDC candidate,” but 32 ev ery system marks an imp ortan t p oin t in the design space. All systems w ere included b ecause making an informed decision ab out any p otential CBDC design requires an understanding of the alternativ es and the reasons why some of them are more or less suitable. A.2 Literature Selection In order to b e included in our systematisation, prop osals must sp ecify a complete pa yment system and include suﬃcien t tec hnical details to enable us to understand the relev ant steps of the under- lying proto cols. The goal is to review research contributions, i. e., technical do cumen ts describing a no vel approach supp orted with evidence. Most works are p eer-review ed. F or the initial literature search, w e used the searc h terms private, regulated, scalable CBDC design and private, regulated, scalable central bank digital currency design in Octob er 2024 via the bibliographic database Go ogle Scholar. 13 W e sorted results b y relev ance without applying any additional ﬁlters. F rom the union of the ﬁrst 100 results of each query , we iden tiﬁed 21 pap ers that prop osed a concrete design for a CBDC or d igital paymen t system. These pap ers underwen t an initial assessment. W e determined that seven of them met the criterion of oﬀering suﬃcient technical details. Next, w e p erformed a one-step forward and backw ard searc h by examining b oth the references of the seven initially selected pap ers and the papers that cited them. W e repeated this process un til we reached saturation. While our literature search started broad, we had to exclude many of the economics pap ers, whic h often explore the monetary policy implications of CBDC adoption and the role of commercial banks. While some of these w orks include high-lev el design concepts, they generally lac k the tec hnical depth required for the analysis conducted in this SoK. The same was true for rep orts of CBDC pilot pro jects, researc h initiatives, and already launc hed CBDCs. Note, that for Pro ject T ourbillon [ 136 ], we reference [ 94 ] (EC1) and [ 124 ] (EC2) for phase 1 and phase 2, resp ectiv ely . After this selection pro cess, w e were left with a collection of 66 design prop osals. Subsequently , these prop osals were man ually reviewed and certain designs excluded based on the follo wing ra- tionales: • P ap ers that were shown to b e insecure (e. g., Zero coin [ 137 ]); • Publications cen tred around the same design if others were already included (e. g., early pap ers by Da vid Chaum [ 40 ], since similar versions by the same author [ 30 , 138 ] w ere already considered); • Designs that were signiﬁcantly impro ved in follo w-up w ork (e. g., [ 139 ] b y Ok amoto w as replaced by its improv ed version [ 107 ]). This pro cess resulted in a ﬁnal set of 36 design prop osals, whic h we analysed in depth. B Comm unication Sym b ols In this app endix, we provide system examples corresp onding to all communication patterns iden- tiﬁed in our literature selection. The complete set of patterns is depicted in Fig. 3 . The b ottom left no de, alw ays depicts the sender, the bottom righ t node the recipient and the top node the op erator(s). (a) (b) (c) (d) (e) (f ) (g) (h) Figure 3: Diﬀerent communication relations. 13 Cf. https://scholar.google.com/ 33 Eac h comm unication pattern can be illustrated using existing systems. Fig. 3 (a) sho ws the comm unication necessary in Chaumian e-cash (see, for example, [ 30 ]), where the sender transfers a coin to the recipient, who then dep osits it with the op erator, i. e., the bank. Fig. 3 (b) sho ws transferable e-cash (e. g., [ 107 ]), where the sender transfers a coin to the recipien t, who can then transfer it to another user until it is dep osited with the op erator. Fig. 3 (c) depicts Flow Control [ 110 ], where the sender sends a coin to the bank via an anony- mous channel, including an identiﬁer of the recipient, allowing the bank to credit the recipient’s accoun t. Fig. 3 (d) shows F astP ay [ 121 ], where the sender broadcasts a paymen t request to m ultiple op erators. Each op erator individually signs the request, and once the sender collects enough signatures, these are broadcast again. The operators then settle the paymen t locally , therefore not needing to communicate with each other. Fig. 3 (e) illustrates Zef [ 125 ], where the recipient ﬁrst communicates the desired coins to the sender. T he sender then requests these coins from the op erators, who each sign the request. The sender aggregates the signatures and returns the signed coins to the recipient. Fig. 3 (f ) represen ts Bitcoin, where a user broadcasts a transaction request. The op erators, i. e., mining nodes, create a new blo c k containing the transaction and broadcast it to all other no des. Fig. 3 (g) corresp onds to P ARScoin [ 126 ]. As in F astPa y , op erators sign state up dates individ- ually and do not communicate with eac h other. How ev er, unlike F astPa y , the sender and recipient m ust communicate directly to up date their resp ectiv e states and then interact individually with the op erators to sign the new states. Finally , Fig. 3 (h) sho ws PEReDi [ 57 ], which is similar to P ARScoin but requires op erator-to- op erator communication in the even t of a transaction ab ort. C Eﬃcien t Storage of Negativ e Information This appendix discusses the engineering c hallenges of implementing nulliﬁer-based approaches, i. e. designs having ev er-growing lists of negative global information, and provides some estimates regarding the amount of data to b e handled to meet desirable p erformance goals. Blo om ﬁlters are a probabilistic data structure whic h can b e used to test whether a given elemen t is a mem b er of a known set in constant-time [ 96 ]. Thereb y , they never pro vide false- ne gatives , i. e., if an element is iden tiﬁed as not b eing part of the set it deﬁnitely is not. On the other hand, false-p ositives are p ossible, i. e., if an element is iden tiﬁed as being part of the set there is still a probability that it is not. The rate of false p ositiv es is parameterised, and this parametrisation leads to trade-oﬀs regarding size and the eﬃciency of the constan t time query . Over the y ears, multiple diﬀerent v arian ts and optimisation techniques hav e b een dev elop ed (see [ 140 ] for a surv ey). T o pro vide estimates regarding ﬁlter sizes and the required num b er of hash functions (or inv o cations) inﬂuencing the query time, we only consider a basic blo om ﬁlter design in this section. T able 5 provides some calculations to estimate the size requirements of a blo om ﬁlter for fast non-mem b ership pro ofs required to preven t double-sp ending. The table includes p erformance goals that would satisfy the curren t global av erage demand in the num b er of transactions and a maximum holding time of one year, i. e., only the total num b er of transactions in a year is considered. Our estimates sho w that the num b er of hash function inv o cations, which is around 30 , is insigniﬁcan t given that SHA3 [ 141 ], for example, can run in around 10 cycles p er b yte [ 142 ]. The required size of the blo om ﬁlter of around 19 TB is substantial given that it has to b e held in memory for fast access. This size is not b ey ond reac h for high-end infrastructures, but splitting up the ﬁlter into several parts has to b e considered to distribute the load. F or our calculations, w e sp eciﬁed a false-p ositiv e rate of appro ximately one false-p ositiv e p er day , which w e consider acceptable. In an y case, the use of blo om ﬁlter implies that there also has to b e a mec hanism to rule out false-p ositiv es using a slow-path. 34 T able 5: T able of diﬀerent blo om ﬁlter parametrisation to estimate the required size of the ﬁlter in a year for a giv en num b er of transactions p er second and a false p ositiv e rate of approx . one false p ositiv e p er day . T x/sec. Entries/y ear F alse p ositive rate Size Hash functions 20 6.31e+08 (630.7M) 5.79e-07 (1 in 1,728,000) 2.19 GB 21 100 3.15e+09 (3.2B) 1.16e-07 (1 in 8,640,000) 12.20 GB 23 1,000 3.15e+10 (31.5B) 1.16e-08 (1 in 86,400,000) 139.64 GB 26 50,000 1.58e+12 (1.6T) 2.31e-10 (1 in 4,320,000,000) 8.28 TB 32 110,000 3.47e+12 (3.5T) 1.05e-10 (1 in 9,504,000,000) 18.86 TB 33 1,000,000 3.15e+13 (31.5T) 1.16e-11 (1 in 86,400,000,000) 187.91 TB 36 D Consensus P erformance Considerations Agreemen t protocols suc h as consensus or state mac hine replication (SMR) 14 are an essential comp onen t of many of the distributed system designs of CBDCs that are considered in this work, pro viding strong consistency and fault-tolerance guarantees. How ever, such agreement proto cols are often asso ciated with non-trivial comm unication and co ordination costs, which can hinder throughput and scalability [ 143 ]. F or example, Byzan tine fault tolerance in SMR was long regarded as too ineﬃcient for practical deplo yment, un til Castro and Lisk ov’s PBFT proto col achiev ed p erformance suitable for real-world replicated services [ 144 ]. T o be able to satisfy the high p erformance and securit y demands of global digital paymen ts, such proto cols often require further improv emen ts and careful design [ 145 , 146 ]. Hereb y , optimising desirable consensus prop erties, such as reaching low latency , i. e. ﬁnality in a minimal num b er of communication rounds, ma y impose additional system assumptions [ 147 ] or presen t signiﬁcant engineering c hallenges [ 148 ]. Hence, any p oten tial CBDC design must carefully consider the concrete choice of agreement mechanism and des ired guarantees that it can oﬀer. In Section 3.1.2 w e discuss measures by which the integrit y of global information is ensured and, in particular, distinguish b et ween systems that guarantee total or der and no total or der of transactions. While the former generally rely on consensus, the latter build up on a prop erty that is observed in [ 143 ], which shows that the c onsensus numb er [ 149 ] of an asset transfer ob ject is 1. In essence, the approach leverages the fact that a global total order is not strictly necessary for concurren t, indep enden t transactions in order to ac hieve desirable consistency guarantees for dig- ital paymen t systems, i. e., preven t double-sp ending. Hence, more light weigh t and round-eﬃcient proto cols than consensus, such as Byzantine Consistent Br o adc ast can instead b e used for asset- transfer, with several w orks [ 57 , 83 , 126 ] building on this approac h. The drawbac k of this approach is that attempts to double sp end can render the resp ectiv e funds unusable. While this may serve as a delib erate disincen tive, it can b e diﬃcult to explain to users in cases of erroneous double sp ending. Con versely , work is being done to render systems with total order guarantees more eﬃcien t, for example, Chop Chop [ 150 ], Sui [ 56 ] and JUMBO [ 151 ], which ac hiev e 43 million and 65 million T x/s, resp ectiv ely , at p eak p erformance. These optimisations often inv olv e m ulti-lay ered approac hes, meaning a consensus-less fast path follow ed by a slow er consensus path that establishes TO. Regardless of the concrete c hoice of mechanism for ensuring consistency of the global state, 14 The exact delineation and deﬁnition of diﬀerent agreement problems is complex and nuanced. W e refer the reader to Garay and Kia yias [ 53 ] for a systematisation on the topic. 35 considerations for the abilit y to apply future scalability measures should also be tak en into accoun t. One suc h approach is enabling a system to sc ale horizontal ly , e. g. by distributing transaction pro cessing and v alidation among shards. E Sharding and Concurren t Pro cessing Horizon tal scaling is another imp ortan t approach to increasing system throughput. In the context of digital pa ymen t systems, shar ding refers to partitioning the (global) state and transaction w orkload across m ultiple committees or pro cessing units, such that disjoin t subsets of transactions can b e veriﬁed and executed indep enden tly , e. g., [ 63 , 84 , 119 , 121 , 152 ]. Hereby the concurrent nature of asset-transfer transactions can b e lev eraged [ 56 , 153 ]. The scalabilit y b eneﬁts of sharding dep end on the degree of tr ansaction indep endenc e , in the sense that transactions op erate on disjoint p ortions of state and therefore commute, p ermitting them to b e treated as indep endent concurrent ob jects [ 149 ]. F rom an arc hitectural standp oin t, negative information app ears more readily shardable, e. g., b y employing c onsistent hashing [ 42 , 63 ], ho wev er, designs suc h as Hamilton [ 84 ] demonstrate that sharding can also b e implemented on p ositiv e information. Throughput can further b eneﬁt from c oncurr ent exe cution techniques, which exploit ﬁne- grained indep endence b etw een transactions. Here, execution o ccurs optimistically , with conﬂicts detected and resolv ed during or after execution. This approac h has seen active developmen t in high-p erformance distributed ledgers and smart con tract platforms through techniques suc h as dep endency-a w are sc heduling or speculative concurrency control [ 56 , 154 , 155 ]. How ev er, such metho ds still require the underlying workload to exhibit suﬃcient parallelism. While sharding and optimistic execution b oth increase throughput by exploiting concurrency , they also in tro duce additional co ordination challenges. In particular, ensuring cr oss-shar d atom- icity requires proto cols that guarantee consistent transaction outcomes across shards, and data availability mec hanisms are needed to ensure that each shard has access to the state required for v alidation. These requirements can imp ose additional communication ov erhead, meaning that the actual p erformance gains of horizontal scaling ultimately dep end not only on workload indep en- dence, but also on the eﬃciency of the mec hanisms that co ordinate b et w een shards [ 146 , 156 , 157 ]. These horizontal scaling approaches are generally intimately tied to the particular arc hitecture and mechanisms for ensuring the integrit y of global information, rendering direct comparisons diﬃ- cult. A systematic framework for comparing these trade-oﬀs in the con text of CBDC architectures remains an imp ortan t direction for future work. F Realising Exact Amoun ts The inability to pay exact amounts is solely a problem of designs building on Chaumian e-cash, i. e., T ransfer Digital Coin patterns. Sev eral solutions ha ve b een prop osed to address this issue. Cheques. These allo w arbitrary v alues to b e spent b y encoding the v alue in binary and sp ending only the parts of the cheque that represent a 1 [ 106 ]. First, though, they p ose severe priv acy risks, since for a refund of the remainder, the negative pattern of the sp en t coin is essentially rev ealed. Second, this approach ma y only work for a limited num b er of paymen ts. F or example, one cannot sp end tw o uneven v alues with the same cheque. T ree representation. A coin is represented as a tree, where each no de represents the sum of its child no des. Sp ending a no de means that none of its descendant or ancestor no des can b e sp en t [ 107 , 109 , 114 , 116 ]. Man y v alues still require sp ending multiple no des, and each no de must b e sp en t in a separate proto col. Diﬀeren t denominations. There are diﬀeren t signatures representing diﬀerent denomina- tions of v alue. This is the same concept that is used for cash. T o b e practical, this requires a system that implements a reasonable proto col to receiv e change or exc hange coins quickly . Chaum 36 et al. [ 42 ] prop ose a c hange proto col, but it must b e signed by a bank and in volv es an in terac- tiv e proto col. Bauer et al. [ 123 ] argue that c hange in an e-cash system with oﬄine functionality is more practical, but each coin still requires a separate paymen t proto col. Rial and Piotrowsk a [ 127 ] pro vide an in-depth discussion on the optimal set of denominations but do not oﬀer an explicit c hange proto col. Coins of diﬀerent v alues. Coins of v arying v alues can b e withdrawn [ 128 ]. This approach is still impractical b ecause it has priv acy risks. If coins of arbitrary v alue can b e withdrawn, the anon ymity set for a given v alue may b e v ery small, reducing sender anonymit y . A dditionally , the exact amount must b e known in adv ance for the approach to b e practical. F or designs based on Chaumian e-cash, many ideas hav e b een prop osed to pay exact amounts, but none are convincing in terms of usability so far. As argued in [ 127 ], when denominations are ﬁxed, a user may hav e suﬃcien t funds but still be unable to complete a transaction due to the lac k of appropriate denominations. This severely impacts usabilit y . In order for an e-cash system to b e practical, tw o asp ects are required: 1. A compact metho d for sp ending multiple coins. 2. A practical proto col for giving change (trivial in the case of oﬄine paymen ts). If the ﬁrst asp ect is highly eﬃcient, the second can b e neglected. In that case, only coins of the smallest denomination are used, and many of them are sp en t in a single paymen t. G Oﬄine F unctionalit y Oﬄine functionality remains one of the biggest challenges in CBDC design, as it requires pre- v enting or managing double-sp ending without constant online v eriﬁcation. Designs oﬀering oﬄine functionalit y can b e distinguished by their approach to either pr event double-sp ending, dete ct- and-sanction it retrosp ectiv ely , or combine b oth strategies. The dete ct-and-sanction approach can b e applied in early transferable e-cash systems, where a double-sp ender is identiﬁed once a coin is redeemed twice b y diﬀerent recipients with the bank. The curren t design space suggests that the dete ct-and-sanction approac h is only p ossible when using negativ e global information. In this case, b y clev erly choosing the wa y the nulliﬁer is generated, a double-sp ender can b e iden tiﬁed. A limitation of the dete ct-and-sanction approac h is that the information size grows with eac h oﬄine transfer [ 158 ]. T w o more recent designs mov e this growing amount of information to the users themselves, although this comes at the exp ense of priv acy . F uchsbauer et al. [ 113 ] achiev e constan t-size oﬄine transfers, but at the cost of requiring every honest non-double-sp ender in the c hain of oﬄine transfers to prov e their inno cence in the ev ent of a double-sp end. This, in turn, obliges all users to retain the necessary information to do so. Similarly , P ayOﬀ [ 83 ] oﬀers oﬄine functionalit y where users m ust iteratively request signatures for account states inv olv ed in oﬄine pa yments when going back online. Again, in the even t of a double-sp end, all honest users in the c hain are required to prov e their innocence, and for each oﬄine pa yment, the user must store relev an t information. Thus, total information still grows, but it is distributed among users rather than stored globally . With to da y’s hardware, gro wing transaction sizes are less of a problem than they were 30 years ago, although extreme cases in whic h users stay oﬄine for extended perio ds migh t not b e practical. The dete ct-and-sanction approach also raises the question of who bears responsibility in a double-sp ending inciden t: the recipient or the cen tral bank. Until the funds are recov ered, one m ust co ver the loss. T o preserve trust, it is suggested that the cen tral bank be liable [ 83 ]. T o reduce p oten tial losses due to cov ering a double-sp end, holding or sp ending limits [ 83 ] are recommended. Literature suggests that the pr event double-sp ending approach requires trusted hardware (TH). These designs ha ve the drawbac k that, if the TH is compromised, the system may permit arbitrary double-sp ending in oﬄine-paymen ts. 37 T able 6: Design space of oﬄine paymen t systems by double-sp ending handling metho d and limit implemen tation. Detect-and-sanction Prev ent Both Limits [ 83 ] No limits [ 107 , 112 , 113 ] [ 118 , 123 ] [ 159 ] a [ 128 ] a The pap er by Christo dorescu et al. [ 159 ], which adopts this approach, was not included in our comparison table due to the lack of a complete technical sp eciﬁcation. That is why some designs com bine the tw o approac hes of handling double-sp ending. These designs implement mechanisms that, in case the TH is compromised, can identify the double- sp ender in retrosp ect when settling online at a later p oin t in time. T able 6 categorises the analysed designs according to their approach to handling double- sp ending and whether they oﬀer holding or sp ending limits. In summary , while several strategies for oﬄine functionalit y exist, each faces op en c hallenges: complete reliance on trusted hardware, the deanonymisation of honest users in the case of double- sp ending, or growing transactions with eac h oﬄine pa yment. T o date, no system providing oﬄine functionalit y has b een implemented. 38

Systematization of Knowledge: The Design Space of Digital Payment Systems with Potential for CBDC

Original Paper

Comments & Academic Discussion

Leave a Comment

Original Paper

Related Papers

Comments & Academic Discussion

Leave a Comment