Central banks that have made the decision to explore retail central bank digital currency (CBDC) issuance are focusing on a common set of key design choices. These include the operating model, the technology platform (centralized versus decentralized database technology, or token-based), degree of anonymity/privacy, availability/limitations, and whether to pay interest. These design decisions are driven by country-specific factors and balance the need to achieve the policy objectives that launched the exploration process and be attractive to users and merchants. (For more detail on these factors and considerations see the 2020 IMF working paper on CBDC operational considerations.)
In this blog I want to talk about the technology platform decision, broadly speaking breaking down into those with centralized or decentralized ledger architectures, and ledger-less offline peer-to-peer stored value platforms. In a traditional centralized ledger (client-server model with no distributed components) transaction processing would entail the payor connecting to the central ledger keeper and initiating a funds transfer to the recipient’s account. The ledger would be updated after the payor has been confirmed as the account holder who has enough funds to carry out the transaction.
Alternatively, the ledger could be run on a distributed ledger technology (DLT) platform, in which the ledger is replicated and shared across several participants. With a DLT platform the central bank could have a centralized, decentralized or partially-decentralized authority for verifying and/or committing transactions. DLT platforms can be “public” (accessible by anyone) or restricted to a group of selected participants (“consortium” or “private”). Ledger integrity can be managed by a selected group of users (“permissioned”) or by all network participants (“permissionless”).
So far, central banks that have reached the proof of concept (PoC) and pilot stages of CBDC explorations have opted platforms that allow for control over platform access and participants, and role-based oversight and visibility of transactions (see table). Such platforms also ensure that the central bank retains full control over money issuance and monetary policy. They include centralized ledger and DLT private permissioned platforms, and digital bearer instrument platforms. Permissionless (decentralized authority) platforms have tended to fall short on scalability, and settlement finality, and financial integrity risk management.
| Digital Currency | Partner Firm | Platform Technology | Platform Type |
| Bahamas Sand Dollar | NZIA | NZIA Cortex DLT | DLT private permissioned |
| China e-CNY | n/a | n/a | Centralized ledger |
| ECCB DCash and Nigeria eNaira | Bitt | Hyperledger Fabric | DLT private permissioned |
| Uruguay e-Peso | Roberto Giori | GSMT | Centralized ledger |
| Jamaica | eCurrency | DSC3 | Digital bearer instrument |
| Ghana | G+D | Filia | Agnostic |
| Sweden e-Krona | Accenture | R3 Corda | DLT private permissioned |
| Ukraine E-Hryvnia | Stellar | Stellar | DLT private permissioned |
| Ecuador dinero electrónico | n/a | Mobile money | Centralized ledger |
It has been generally believed that centralized platforms process transactions more quickly. VISA says their network can handle up to 65,000 transactions per second (TPS), while private DLT platforms have tended to be way slower (e.g., 10,000+ TPS). There is also the issue of “finality” – the point at which transferred funds become irrevocable. Some networks, like Bitcoin and R3 Corda, offer only what is called “probabilistic finality” which won’t cut it for a retail payment system.
Although all the pros and cons of DLT-based versus centralized ledger-based retail payment systems are out of scope of this post, it’s worth mentioning that DLT-based platforms may offer enhanced resiliency by reducing single points of failure. Also, potential data loss at one node can be recovered through replication of the ledger from other nodes when the network comes back online. But DLT-based platforms may experience attacks against the network layer, which includes the consensus mechanism by which database updates are approved, or smart contract exploits. (For more on such pros and cons, see Raphael Auer and Rainer Böhme’s Technology of Retail Central Bank Digital Currency article)
In the table below, I’ve listed what I believe to be the main players in the retail CBDC platform space. My main criterion for inclusion is that the platform has been used in a CBDC or sovereign digital currency pilot or proof of concept or has published something substantive to back up the claim that it offers a viable CBDC platform. I’ve tried to categorize them by whether they’re ledger- or token-based, and if they’re ledger-based, whether the ledger management is centralized or distributed. My plan is to make this a “live” table, and possibly add more columns based on your comments and suggestions. If you have platform suggestions that I’ve missed, please provide links to written material that supports the claim.
