\documentclass{article} % {article} % {acmart} \usepackage{url} \usepackage{eurosym} \usepackage[T1]{fontenc} % \usepackage{lmodern} % \usepackage{verbatim} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage[a4paper,left=25mm,right=25mm, top=25mm, bottom=25mm]{geometry} \usepackage{enumerate} \begin{document} \pagestyle{plain} % \thispagestyle{empty} \newcommand\logo{\includegraphics[width=0.07\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}} \begin{center} {\huge Centrally Banked Digital Currency \\ for Illiterate and Low-literate People } \end{center} \begin{center} \includegraphics[width=3cm]{taler-logo-2021-plain.pdf} \hskip1cm \includegraphics[width=5cm]{myoralvillage.png} \end{center} \def\red{} % FIXME \begin{abstract} Taler is a cryptographic protocol with a Free Software reference implementation for a value-based transaction system. Taler payments are executed in fiat currency with privacy and regulatory compliance, which makes Taler suitable for a Central Bank Digital Currency (CBDC). My Oral Village (MOVE) has been developing user interfaces for electronic payment systems that can be used by illiterate and innumerate groups, with field experience from Kenya and Pakistan where substantial portions of the population cannot read multi-digit numbers or text. We propose to integrate the user interface work of My Oral Village with the Taler payment system to create an inclusive payment solution that minimizes the digital divide. \end{abstract} \section{Introduction to GNU Taler} Taler Systems SA is developing an online payment system called Taler, that broadly fits the requirements of CBDCs. The major parts of the system have already been built. Taler's unique focus is on regulatory compliance, efficiency and data minimization. Cryptography is employed for security. While Taler includes privacy features, it can still guarantee that cash flows to merchants/retailers are transparent for anti-% money-laundering (AML) and know-your-customer (KYC) auditing requirements. Transactions with Taler execute in one network round-trip time. Taler is economically viable for micro-payments (payments of 1 cent) as its design minimizes requirements in terms of CPU time (typically less than 1 M cycles per transaction), bandwidth (typically 1-10 KB/transaction), and storage (again a few KB/transaction, with the ability to delete old data once legal data retention periods have expired). \subsection{Unique sales propositions} The unique sales propositions of Taler as it exists today are: \begin{itemize} \item All operations are cryptographically secured, with mathematically sound proofs for courts and auditors \item Customer payments are privacy-preserving, like cash \item Merchants are identifiable in each payment they receive \item Payments are in existing currencies \item Payment fraud is eliminated, short of catastrophic failure in cryptographic primitives \item Linear scalability ensures Taler can handle transaction volumes seen in global payment systems today \item Suitable for micro-payments due to very low transaction costs \item The patent-free, open standard protocol and the free reference implementation provide long-term sustainability and technological independence from foreign providers %\item Can be used for smart contracts \item Ease of use (one-click, instant, no authentication during payment, again like cash) \end{itemize} The proposed work will extend this list by making Taler {\bf suitable for illiterate and innumerate adults}. After consultation with My Oral Village, we believe the payment process with Taler can be made safe and convenient for their use. Based on years of direct field research, MOVE develops locally-validated solutions that blend graphical representations of money, iconographic navigation cues and metaphors, and experimental insights from cognitive psychology. We also have plans to make Taler suitable for (numerate) children. \subsection{Taler architecture} The Taler architecture includes a register-based system of bank accounts for customers and merchants with an escrow-account for the exchange. The exchange signs electronic coins into existence, customers use them to sign contracts and merchants deposit them in return for a credit to the register. The exchange collects cryptographic proofs that it operates correctly, which are then checked by an auditor (auditor not shown): \begin{center} \includegraphics[width=\textwidth]{../presentations/comprehensive/operations.png} \end{center} Thus, the following components form the core of the system: \begin{enumerate} \item An \emph{Electronic wallet} software stores cryptographic tokens of value (called digital coins), implemented via blind signatures. Wallets are typically managed by the end user; a \emph{wallet provider} can manage storage of cryptographic material for the user, providing backup, synchronization and recovery. \item The \emph{Exchange} issues digital coins to wallets, after receiving fiat money in an escrow account, or based on a central bank creating the digital coins as a central bank liability. The authorized electronic wallet is identified using an ephemeral \emph{reserve public key} encoded in the wire payment instructions. As blind signatures are used, the exchange knows that it issued coins of a certain monetary value, but not to which wallet. Digital coins are always denominated in a fiat currency (e.g. Euro). \item The \emph{Merchant} proposes contracts to customers and receives payment in the form of contracts signed using digital coins. The merchant must then immediately clear these \emph{deposit permissions} with the exchange. The exchange checks against double-spending, and if everything is in order provides the merchant with an instant \emph{deposit confirmation}. After possibly aggregating many micro-transactions, the exchange sends money from the escrow account to the merchant's bank account. \item \emph{Auditors} are entities that certify which Exchanges can be trusted as legitimate. They are not strictly needed in a CBDC setting, but can be used by the central bank to verify that its own operations have not been compromised. \end{enumerate} The implementation of all core components is licensed as free and open source software (FOSS). \subsection{Vision} Our vision is close to the electronic cash system ``DigiCash'' proposed by David Chaum in the 1990s, except that Taler's design and implementation supports key features such as giving change, providing refunds, securely handling aborts and various other practical issues previous technical solutions lacked. In summary, the overall system roughly operates as follows: The Taler wallet is filled via wire-transfer to the Taler exchange's escrow account, where the subject identifies the Taler wallet eligible to withdraw the CBDC. Regulators can limit the amount an entity is entitled to exchange from rand into CBDC, like ATM withdrawal limits. When withdrawing electronic coins, they are blindly signed by the Taler exchange and stored in the consumer's wallet, which is value-based. The consumer can then spend its coins at merchants using cryptographic signatures over electronic contracts. Merchants must immediately deposit the coins at the exchange, which performs an online check for double-spending. The exchange will then credit the merchant's register-based accounts using aggregated wire-transfers. \subsection{Company Profile: My Oral Village} My Oral Village is a not-for-profit social enterprise incorporated in Canada. Engaged in human-centred design and field research at the oral-digital frontier, we build trusted, usable financial-interface solutions for the world's billion functionally illiterate and innumerate adults to support their transition into financial inclusion. Our suite of ``oral information management'' (OIM) tools and solutions enable poorly schooled individuals to safely and confidently engage in formal financial transactions. We are currently piloting a hybrid (digital and paper-based) solution for entrepreneurial pastoralists in northern Kenya, and testing our ``cash calculator'' for Android in Pakistan. We recently designed a passbook for new credit union members in Sierra Leone. With MicroSave, we wireframed a full 'concept-level' mobile money app for northern India. Our OIM solution for savings groups in the Solomon Islands has been adopted by the Ministry of Women and the Anglican Church of Melanesia. We are also developing a field experiment in Kenya with a team of numerical cognition researchers at the Universities of Tuebingen and Western Ontario. \subsection{Company profile: Taler Systems SA} Taler Systems SA was established in 2016 and is headquartered in Luxembourg, but also has developers in Argentina, Brazil, Germany, Switzerland and the United States of America. Taler Systems SA was founded as a startup by with support from INRIA, the French national institute for research in computer security (\url{https://www.inria.fr/}) and the Free Software community (\url{https://www.gnu.org/}). % The company is privately owned and debt-free. Taler Systems SA business model is to provide technical support for users of the Taler payment system, and to possibly dual-license the Free Software for users that have specific licensing requirements. Taler Systems is in the unique position of not having technological business secrets to protect, as all of our code and documentation is freely available. Thus, we can easily find and train local partners in our technology and focus on providing second-level support. We have been involved in consultations with the Swiss National Bank, the European Central Bank, and the Swedish Riksbank, as all three were interested in Taler in their respective CBDC initiatives. However, none of them is yet at the point where the respective central banks have made any commitments for any particular direction or technical solution. \section*{Contact} \begin{tabular}{l l} Dr. C. Grothoff & grothoff@taler.net \\ Dr. F. Dold & dold@taler.net \\ L. Schumacher & schumacher@taler.net \\ B. Matthews & brett@myoralvillage.org \\ \end{tabular} \vfill \includegraphics[width=0.05\textwidth]{../presentations/investors/partner-logos/ashoka.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/inria.png} \hfill \includegraphics[width=0.1\textwidth]{../presentations/comprehensive/bfh.png} \hfill \includegraphics[width=0.025\textwidth]{../presentations/investors/partner-logos/tum.png} \hfill \includegraphics[width=0.025\textwidth]{../presentations/investors/partner-logos/gnu.jpeg} \end{document} \subsection*{What would a solution for a register-based CBDC look like?} \subsection*{What would a solution for a value-based CBDC look like?} \section*{What is your vision for an CBDC?} % Are there other possible solutions than register-based and value-based that you consider to be more appropriate?} \section*{What challenges and opportunities do you envisage?} Taler provides the advantages of cash while supporting taxation and limiting criminal abuse, as recipients of payments are identifiable. Furthermore, Taler transactions are faster, easier and more secure than cash or credit card transactions. The main challenge is the integration of the Taler merchant backend into the diverse POS systems that exist today. While integrating Taler can be done with a few hundred lines of code, NFC-enabled POS systems would require at least a firmware update. Convincing vendors to upgrade their systems will thus require a major up-front investment. Taler also requires further development to ensure that wallets are available on all relevant platforms. However, consumer systems are much less diverse and hence this effort is significantly smaller. Deploying Taler at scale should have no major impact on monetary policy because the issued CBDC would be 1:1 backed by fiat currency in the escrow account at the central bank. However, if there is a significant shift from the use of credit-cards to CBDC, there might be a reduction in M2 from fractional reserve banking as CBDC is debit-based while credit-cards are credit-based. Thus, instead of commercial bank money being created from debts, consumers may effectively hold CBDC claims against the escrow account at the central bank. The resulting reduction in M2, and the loss of revenue at banks from credit-card interest payments, may require adjustments in monetary policies. \section*{What is missing in our concept?} A key requirement for governments considering electronic payment systems is the preservation of the Commons. Cash is a Commons as all market participants have equal liberties in handling cash. If cash is replaced by proprietary solutions such as Visa's credit card system or ApplePay, these companies have exclusive control over critical infrastructure, which often leads to high fees. Worse, such payment service providers may discriminate against individuals or certain businesses and can refuse service to individuals or businesses without judicial oversight. In contrast, Taler is implemented as Free Software distributed under the GNU General Public License, and without patent encumbrances. This ensures that any government retains sovereignty after deploying Taler, as it can liberally inspect, use and modify the software. In particular, no foreign government or company can impose their own restrictions or regulatory regime. Governments can foster competition between multiple Taler exchange operators, or run a Taler exchange as a government monopoly equivalent to a government mint for coins. \section{Addressing CBDC Requirements} We now sketch how the Taler components map to a Centrally Banked Digital Currency system run by the ECB or national central banks (NCBs), according to the draft requirements. Taler is a value-based payment system (as opposed to an account-based system), and thus we will address the common requirements C1-C8 and requirements V1-V4 specific to the value-based model. \paragraph{C1. Tokenization:} \emph{Units of digital currency (CBDC units) are only created against money blocked on a transit account, which will be held by ECB/NCBs}. The ECB/NCBs would simultaneously take the role of the Taler Exchange and Taler Auditor (or could outsource operations to qualified third parties). \paragraph{C2. Issuance:} \emph{A central authority creates new CBDC units on the reception of the transfer of an equivalent EUR amount from the participating bank to the transit account. The same logic applies to the destruction of existing CBDC units, where the central authority destroys CBDC and releases EUR that were previously held by the ECB/NCBs in the transit account.} The ECB/NCBs create new CBDC units by issuing Taler digital coins, and destroy CBDC units by accepting digital coin deposits from merchants, subsequently releasing funds blocked in the escrow account and sending them to the merchant's bank account. \paragraph{C4. 1-on-1 parity rule:} \emph{The parity rule applies when CBDC units are newly created or destroyed, meaning that for each EUR blocked in (released from) the transit account there will be exactly one CBDC created (destroyed). The parity rule also applies when CBDC are exchanged for commercial bank deposits or physical cash, and vice versa.} Digital coins in GNU Taler correspond 1-on-1 to a value in a fiat currency such as the Euro. \paragraph{C4. Two-tier structure:} \emph{The central authority issues CBDC only to entities entitled to deposit funds in the transit account held at ECB/NCBs in exchange for newly issued CBDC units. Also, end- users’ access to the CBDC payment system is intermediated via other entitled entities, acting as gateways. All these entities, hereafter “tier-2 entities”, could be commercial banks or non-banks (for example, payment service providers (PSPs), wallet providers etc.).} With Taler, national banks could serve as the primary Tier-2 entity, establish customer's identities (KYC) during bank account setup, and facilitate the transfer from a customer's bank account to the exchange's escrow account. A secondary Tier-2 entity are the wallet providers. Banks can serve as wallet providers, but other third party businesses could offer a wallet backup/sync/restore services as well. Customers are also given the option to be responsible for the security of their wallet on their own, and manage private keys directly and on their own device. \paragraph{C5. Compliance with AML regulation:} \emph{Transactions with amounts above a certain threshold must be disclosed to relevant parties as required by the AML regulation. In general, the system must be designed in a way that discourages end-users from using it for anonymous large-value transactions.} Strict withdrawal limits can be placed on customers' bank accounts. Merchants can be required to collect customer data for critical transactions. Due to the technical measures that provide transparency of cash flows to merchants, the compliance of merchants is easy to verify. \paragraph{C6. Fees:} \emph{The system should enable fee collection. The issuance of CBDC to banks and the destruction of returned CBDC are free of charge for the entitled tier-2 entities (i.e. banks). Tier-2 entities can, however, charge fees to end-users for services they provide, such as their involvement in the transfers of CBDC and/or the exchange of EUR into CBDC and vice versa.} Taler has a flexible fee structure that is easily configured so that Tier-2 banks can charge for CBDC creation and other activities. \paragraph{C7. Availability:} \emph{Payments are processed 24 hours a day, 7 days a week, 365 days a year, without operational downtimes.} Taler requires no manual processing and can be made highly available with standard software deployment and operations techniques. \paragraph{C8. Throughput, transaction time and micropayments:} \emph{The payment system must be able to handle a sufficiently large amount of transactions. Each transaction must be processed real-time (to be compliant with the SEPA Instant Credit Transfer (SCT Inst) scheme, the transaction time would have to be maximum ten seconds). Furthermore, the payment system should/could enable micropayments (low value, large volume, low cost, real time transactions).} Transactions with Taler are processed in the order of milliseconds. Unlike DLTs, Taler can be easily scaled both horizontally (sharding, more processing nodes) and vertically (faster machines). Since multiple payments to a merchant can be aggregated into one bank transfer, even micropayments with fractions of a cent are possible. All coins are issued with expiration dates, ensuring that the exchange may eventually delete ancient transactions. \paragraph{V1. Non-interest-bearing:} \emph{In the value-based model, holdings of CBDC do not bear interest - neither positive nor negative.} In Taler, digital coins do not bear interest; however, when coins expire it is possible to charge fees when the electronic wallets trade expiring coins for fresh coins. This feature may be used to provide a mechanism for negative interest rates (for non-circulating coins). \paragraph{V2. Limitation of bank runs:} \emph{In the value-based model, to avoid a situation, in which end-users (suddenly) shift large amounts of their commercial bank deposits to CBDC, daily (potentially also weekly or monthly) limits should be imposed on the amount that can be converted from commercial bank deposits into CBDC.} Bank runs are discouraged and limited with Taler: (1) Withdrawal limits can be imposed by the Tier-2 banks on the withdrawal of CBDC units; (2) wallet providers may place limits on how much money can be stored in online wallets; (3) customers that mange their own wallet are discouraged from storing large amounts of CBDC units in their wallets, as they must ensure its safety similar to a physical wallet; (4) modest expiration times with modest refresh fees make hoarding coins unattractive. \paragraph{V3. Anonymity and AML:} \emph{The system should allow anonymous low-value transactions (below a certain amount used as threshold). Moreover, it should be possible to trace large-value transactions and link them to the identities of the participants (through KYC). Furthermore, as countermeasure against splitting large-value transactions into multiple low-value anonymous transactions, it should be possible to identify multiple low-value transactions which are processed within a certain period of time and which sum up to an amount greater than the chosen threshold.} The exchange does not know which customer owns which coin due to the use of blind signatures during the withdrawal process. AML measures are based on the \emph{income transparency} feature, where cash flows to merchants are visible to the exchanges (and thus ECB/NCBs). As the merchant redeems CBDC units with a transaction to their bank account, the KYC process already happened when the merchant opened their SEPA bank account. Furthermore, the deposit permissions are linked to the contract with the customer, allowing authorities to validate the plausiblity of the transaction during tax audits. With Taler, ownership of digital coins between mutually distrusting parties can only be securely transferred with a digital coin deposit via the exchange. This discourages ``invisible'' payments by sharing digital coins between wallets without involving the exchange. \paragraph{V4. Ownership and spending rights of CBDC:} \emph{In the value-based model, units of CBDC are held by end-users themselves. Each end-user has cryptographic information (e.g. private keys, other secrets) without which CBDC units associated with that particular cryptographic information material cannot be spent. Spending rights are defined by technology (e.g. if you have private keys you can spend).} Technically literate users have the option to manage their own wallets and private keys, whereas other users can use wallet backup/sync/restore providers. \section*{Contrast and Relationship to DLT-based Systems} The Taler payment system is independent from Distributed Leder Technology (DLT) systems. In particular, Taler payments are not necessarily backed by any blockchain or cryptocurrency. Even though Taler uses cryptographically secured payment tokens, it is distinct from ``cryptocurrencies'': Taler is a very efficient electronic payment system with certain characteristics like cash, but it is not a currency. Taler is designed to serve as a payment instrument for retail commerce, in contrast to DLTs which are generally used more as a long-term stores-of-value or as speculative assets. Some technological advancements made by DLTs could potentially benefit Taler. For example, public cryptographic key material and data relevant for auditing could be further secured by a distributed ledger. Yet a distributed ledger is not mandatory to operate Taler, as payments are facilitated by a federation of trusted entities, with oversight from each other and/or a central institution, not too dissimilar from how traditional banking systems work.