taler-cbdc.tex (13453B)
1 \documentclass{scrartcl} 2 \usepackage[a4paper, 3 top=2cm, 4 bottom=1cm, 5 includefoot, 6 left=4cm, 7 right=2cm, 8 footskip=1cm]{geometry} 9 10 \usepackage{lastpage} % enables \pageref{LastPage} 11 12 \usepackage{scrlayer-scrpage} 13 \cfoot*{\normalfont Page \pagemark{} of \normalfont \pageref{LastPage}} 14 \pagestyle{scrheadings} 15 16 % German indentation 17 \setlength{\parindent}{0pt} 18 \setlength{\parskip}{0.5ex plus 1pt minus 1pt} 19 20 21 \usepackage{graphicx} 22 %\usepackage{mathpazo} 23 \usepackage{newtxtext,newtxmath} 24 %\usepackage{mathptmx} 25 \usepackage[utf8]{inputenc} 26 \usepackage[T1]{fontenc} 27 %\usepackage[ngerman]{babel} 28 \usepackage{color} 29 \usepackage[hidelinks]{hyperref} 30 31 \begin{document} 32 33 \title{Taler as the Foundation \\ for a European Retail \\ Centrally Banked Digital Currency} 34 \author{Florian Dold} 35 \date{\today} 36 \maketitle%\vspace{-15ex} 37 38 This note elaborates on how the open source payment system GNU Taler fits into 39 the requirements of a Centrally Banked Digital Currencency (CBDC) intended for 40 use in the European retail market. It was created as a response to an 41 unpublished draft note by an internal expert group of the European Central Bank's 42 InnovationLab. 43 44 \emph{Neither the original list of requirement nor this response reflects the 45 opinion of the ECB. The ECB's official stance can be found in official 46 documents such as 47 \url{https://www.ecb.europa.eu/press/key/date/2017/html/sp170116.en.html}.} 48 49 \section*{Overview} 50 Taler Systems is developing GNU Taler, the software 51 infrastructure for an electronic payment system with focus on security, 52 efficiency and data minimization. Cryptography is employed for security, 53 privacy by design and data minimization, but can at the same time guarantee that cash flows 54 to merchants/retailers are transparent for AML and other financial auditing 55 features. 56 57 The following components form the core of the system: 58 \begin{enumerate} 59 \item An \emph{Electronic wallet} software stores cryptographic 60 tokens of value (called digital coins), implemented via blind 61 signatures. Wallets are typically managed by the end user; a 62 \emph{wallet provider} can manage storage of cryptographic 63 material for the user, providing backup, synchronization and 64 recovery. 65 66 \item The \emph{Exchange} issues digital coins to wallets, after 67 receiving money in a escrow account. The authorized electronic 68 wallet is identified using an ephemeral \emph{reserve public key} 69 encoded in the wire payment instructions. As blind signatures are 70 used, the exchange knows that it issued coins of a certain 71 monetary value, but not to which wallet. Digital coins are always 72 denominated in a fiat currency (e.g. Euro). 73 74 \item The \emph{Merchant} proposes contracts to customers and 75 receives payment in the form of contracts signed using digital 76 coins. The merchant must then immediately clear these 77 \emph{deposit permissions} with the exchange. The exchange checks 78 against double-spending, and if everything is in order provides 79 the merchant with an instant \emph{deposit confirmation}. After 80 possibly aggregating many micro-transactions, the exchange sends 81 money from the escrow account to the merchant's bank account. 82 83 \item \emph{Auditors} are entities that certify which Exchanges can 84 be trusted as legitimate. Auditors must be configured in the 85 electronic wallets and the merchants' infrastructure before these 86 users accept digital coins of the respective exchanges. Auditors 87 include a software component used to conduct ongoing automated 88 checks of the Exchanges' wire transaction history to detect if 89 they deviate from their expected operation. For this, auditors 90 must be provided a replica of the exchange's database and read-only 91 access to the escrow account. 92 \end{enumerate} 93 94 The implementation of all core components is licensed as free and open 95 source software (FOSS). 96 97 \section*{Addressing CBDC Requirements} 98 99 We now sketch how the Taler components map to a Centrally Banked Digital 100 Currency system run by the ECB or national central banks (NCBs), according to 101 the draft requirements. Taler is a value-based payment system (as opposed to 102 an account-based system), and thus we will address the common requirements 103 C1-C8 and requirements V1-V4 specific to the value-based model. 104 105 \paragraph{C1. Tokenization:} \emph{Units of digital currency (CBDC units) are only created against money 106 blocked on a transit account, which will be held by ECB/NCBs}. 107 108 The ECB/NCBs would simultaneously take the role of the Taler Exchange 109 and Taler Auditor (or could outsource operations to qualified third parties). 110 111 \paragraph{C2. Issuance:} \emph{A central authority creates new CBDC units on 112 the reception of the transfer of an equivalent EUR amount from the 113 participating bank to the transit account. The same logic applies to the 114 destruction of existing CBDC units, where the central authority destroys CBDC 115 and releases EUR that were previously held by the ECB/NCBs in the transit 116 account.} 117 118 The ECB/NCBs create new CBDC units by issuing Taler digital coins, 119 and destroy CBDC units by accepting digital coin deposits from merchants, subsequently releasing 120 funds blocked in the escrow account and sending them to the merchant's bank account. 121 122 \paragraph{C4. 1-on-1 parity rule:} \emph{The parity rule applies when CBDC units are newly created or destroyed, 123 meaning that for each EUR blocked in (released from) the transit account there will be exactly 124 one CBDC created (destroyed). The parity rule also applies when CBDC are exchanged for 125 commercial bank deposits or physical cash, and vice versa.} 126 127 Digital coins in GNU Taler correspond 1-on-1 to a 128 value in a fiat currency such as the Euro. 129 130 \paragraph{C4. Two-tier structure:} \emph{The central authority issues CBDC only to entities entitled to deposit funds 131 in the transit account held at ECB/NCBs in exchange for newly issued CBDC units. Also, end- 132 users’ access to the CBDC payment system is intermediated via other entitled entities, acting as 133 gateways. All these entities, hereafter “tier-2 entities”, could be commercial banks or non-banks 134 (for example, payment service providers (PSPs), wallet providers etc.).} 135 136 137 With Taler, national banks could serve as 138 the primary Tier-2 entity, establish customer's identities (KYC) during bank 139 account setup, and facilitate the transfer from a customer's bank 140 account to the exchange's escrow account. A secondary Tier-2 entity are the wallet providers. 141 Banks can serve as wallet providers, but other third party businesses could offer 142 a wallet backup/sync/restore services as well. Customers are also given the option to be 143 responsible for the security of their wallet on their own, and manage private keys directly 144 and on their own device. 145 146 147 \paragraph{C5. Compliance with AML regulation:} \emph{Transactions with amounts above a certain threshold must be 148 disclosed to relevant parties as required by the AML regulation. In general, the system must be 149 designed in a way that discourages end-users from using it for anonymous large-value 150 transactions.} 151 152 Strict withdrawal limits can 153 be placed on customers' bank accounts. Merchants can be required to collect 154 customer data for critical transactions. Due to the technical measures 155 that provide transparency of cash flows to merchants, the compliance of 156 merchants is easy to verify. 157 158 \paragraph{C6. Fees:} \emph{The system should enable fee collection. The issuance of CBDC to banks and the 159 destruction of returned CBDC are free of charge for the entitled tier-2 entities (i.e. banks). Tier-2 160 entities can, however, charge fees to end-users for services they provide, such as their 161 involvement in the transfers of CBDC and/or the exchange of EUR into CBDC and vice versa.} 162 163 Taler has a flexible fee structure that is easily configured so that Tier-2 banks 164 can charge for CBDC creation and other activities. 165 166 167 \paragraph{C7. Availability:} \emph{Payments are processed 24 hours a day, 7 days a week, 365 days a year, without 168 operational downtimes.} 169 170 Taler requires no manual processing and can be made highly 171 available with standard software deployment and operations techniques. 172 173 174 \paragraph{C8. Throughput, transaction time and micropayments:} \emph{The 175 payment system must be able to handle a sufficiently large amount of 176 transactions. Each transaction must be processed real-time (to be compliant 177 with the SEPA Instant Credit Transfer (SCT Inst) scheme, the transaction time 178 would have to be maximum ten seconds). Furthermore, the payment system 179 should/could enable micropayments (low value, large volume, low cost, real time 180 transactions).} 181 182 Transactions 183 with Taler are processed in the order of milliseconds. Unlike DLTs, Taler can 184 be easily scaled both horizontally (sharding, more processing nodes) and 185 vertically (faster machines). Since multiple payments to a merchant can be aggregated into 186 one bank transfer, even micropayments with fractions of a cent are possible. All coins 187 are issued with expiration dates, ensuring that the exchange may eventually delete ancient 188 transactions. 189 190 \paragraph{V1. Non-interest-bearing:} \emph{In the value-based model, holdings of CBDC do not bear interest - neither 191 positive nor negative.} 192 193 In Taler, digital coins do not bear interest; however, 194 when coins expire it is possible to charge fees when the electronic wallets trade 195 expiring coins for fresh coins. This feature may be used to 196 provide a mechanism for negative interest rates (for non-circulating coins). 197 198 199 \paragraph{V2. Limitation of bank runs:} \emph{In the value-based model, to avoid a situation, in which end-users 200 (suddenly) shift large amounts of their commercial bank deposits to CBDC, daily (potentially also 201 weekly or monthly) limits should be imposed on the amount that can be converted from 202 commercial bank deposits into CBDC.} 203 204 Bank runs are discouraged and limited with Taler: (1) Withdrawal 205 limits can be imposed by the Tier-2 banks on the withdrawal of CBDC units; (2) wallet providers may place limits 206 on how much money can be stored in online wallets; (3) customers that mange their own wallet are discouraged from 207 storing large amounts of CBDC units in their wallets, as they must ensure its safety similar to a physical wallet; 208 (4) modest expiration times with modest refresh fees make hoarding coins unattractive. 209 210 211 \paragraph{V3. Anonymity and AML:} \emph{The system should allow anonymous low-value transactions (below a 212 certain amount used as threshold). Moreover, it should be possible to trace large-value 213 transactions and link them to the identities of the participants (through KYC). Furthermore, as 214 countermeasure against splitting large-value transactions into multiple low-value anonymous 215 transactions, it should be possible to identify multiple low-value transactions which are 216 processed within a certain period of time and which sum up to an amount greater than the 217 chosen threshold.} 218 219 The exchange does not know which customer owns which coin 220 due to the use of blind signatures during the withdrawal process. 221 AML measures are based on the \emph{income transparency} feature, 222 where cash flows to merchants are visible to the exchanges (and 223 thus ECB/NCBs). As the merchant redeems CBDC units with a transaction to their bank account, the KYC process 224 already happened when the merchant opened their SEPA bank account. Furthermore, the 225 deposit permissions are linked to the contract with the customer, allowing authorities 226 to validate the plausiblity of the transaction during tax audits. 227 With Taler, ownership of digital coins between mutually distrusting parties can only be securely transferred with a digital coin deposit via the exchange. 228 This discourages ``invisible'' payments by sharing digital coins between wallets 229 without involving the exchange. 230 231 \paragraph{V4. Ownership and spending rights of CBDC:} \emph{In the value-based model, units of CBDC are held by 232 end-users themselves. Each end-user has cryptographic information (e.g. private keys, other 233 secrets) without which CBDC units associated with that particular cryptographic information 234 material cannot be spent. Spending rights are defined by technology (e.g. if you have private 235 keys you can spend).} 236 237 Technically literate 238 users have the option to manage their own wallets and private keys, whereas 239 other users can use wallet backup/sync/restore providers. 240 241 \section*{Contrast and Relationship to DLT-based Systems} 242 243 The Taler payment system is independent from Distributed Leder 244 Technology (DLT) systems. In particular, Taler payments are not 245 necessarily backed by any blockchain or cryptocurrency. Even though 246 Taler uses cryptographically secured payment tokens, it is distinct 247 from ``cryptocurrencies'': Taler is a very efficient electronic 248 payment system with certain characteristics like cash, but it is not a 249 currency. Taler is designed to serve as a payment instrument for 250 retail commerce, in contrast to DLTs which are generally used more as 251 a long-term stores-of-value or as speculative assets. 252 253 Some technological advancements made by DLTs could potentially benefit Taler. 254 For example, public cryptographic key material and data relevant for auditing 255 could be further secured by a distributed ledger. Yet a distributed ledger is 256 not mandatory to operate Taler, as payments are facilitated by a federation of 257 trusted entities, with oversight from each other and/or a central institution, 258 not too dissimilar from how traditional banking systems work. 259 260 \end{document}