This is the follow-on article to the first part posted on October 18th, summarizing my thoughts on the trade off points listed in the table that John Kiff and Rob Durscki published in their article Central Bank Digital Currency Implementation Trade-Offs (Version 2) .
INDIRECTLY USER-FOCUSED
2.1 Motivation: Digitalization and financial inclusion
Downside/Risk: Smart devices required
What is required is of course a payment enabled device, nowhere near a smart phone. For 5-10 USD, one can have a token with embedded payments technology and one can enable merchants simply with a paper QR code. A lot can be done with little and a lot more is on its way. One does also need to look at each country separately, as many have a high density of smart phones already. I would also expect that each provider can handle at least smartphones that are up to 8 years old.
2.2 Motivation: G2P payments
Downside/Risk: Limited spending controls, depreciating money
I suppose the spending controls were already addressed with my remarks to point 1.5. in the first article. I do not understand the depreciating money downside. Maybe it refers to the lack of interest payments?
2.3 Motivation: Payment system efficiency/competition
Downside/Risk: Risk of private payment ecosystem crowding out
Risk of crowding out the private payment ecosystem does not exist, in my opinion. How much competition will we have in a Visa/Mastercard oligopoly after cash disappears? Will 2 closed solutions lead to innovation/efficiency and competition? Certainly not in my view of the world. Put out an open/free (FLOSS) CBDC solution where everything is open, and every interested party can participate with its adapted innovative wallets and solutions, then you get innovation, competition and efficiency. And vendor independence/sovereignty on top.
Never going to happen? Just think of this: Once upon a time, there was closed server solution called Microsoft Windows that nearly had a monopoly, and a free/open (FLOSS) server solution used by a few geeks called Linux. What happened? Today, 25 years later, most of the Microsoft Azure Cloud runs on Linux!!!!
2.4 Motivation: Payment system safety and resilience
Downside/Risk: Single point of failure risk if it is not DLT based, or if it is, the risk of a consensus protocol failure
These are 2 different topics. To assess safety, you need to define the different attack vectors and see how the respective solution addresses them. For example, with a token-based solution (like physical cash) you can only lose what you carry in your wallet, with an account-based solution (like your bank account) you can be subject to ID theft and someone totally empties your account.
To assess resilience, I think it is not appropriate to believe that a permissioned central-bank centrally owned DLT will for sure behave in a more resilient way than the most resilient deployments of federated or clustered databases. This assumption needs to be proven before we should accept it as fact. If all the nodes operated by the central all get the same updates from the central bank, then a vulnerability in the update represents a single point of failure. It is important not to compare apples with oranges on this subject.
A single-owner permissionned DLT is also very different from the Bitcoin or Ethereal blockchain with complete decentralization when it comes to resilience. Even there, I would invite you to research the uptime of the Bitcoin blockchain since launch and compare with the SWIFT numbers. That is an interesting comparison I would like to see the numbers of.
2.5 Motivation: Stimulate bank competition / reach
Downside/Risk: Disintermediation if banks do not react to stimuli (even less competition that before)
This very much depends on the CBDC solution. If the central bank introduces the digital equivalent of the physical wallet and it cannibalizes physical wallet market share, banks are completely unaffected. If the central bank offers bank accounts, banks risk taking a beating or the CBDC needs to be made'technically' unattractive.
CENTRAL-BANK FOCUSED
3.1 Motivation: Strengthen monetary policy analysis by giving the central bank (pseudo-anonymized) date on people’s spending.
Downside/Risk: User concerns about potential government surveillance and controls
If the central bank designs its CBDC system correctly with data minimization and privacy by default, it does not need to pseudo-this or anonymize-that. If the system only collects the information that in area code 75007 on July 14th 2023, 759 baguettes were bought (or similar), the central bank can do much better analysis than today for monetary policy. And the user must not have any concern. All possible today…
3.2 Motivation: Strengthening monetary policy transmission with policy rate-linked remuneration
Downside/Risk: Prospect of a negative-interest rate paying CBDC could be unpopular with users.
This is a purely political/policy topic, technology can do what is necessary, either way. Of course, user will not like such possibilities but here also it is no different than what happens with bank accounts today.
3.3 Motivation: Supporting the authorities’ efforts to combat illicit financial activity
Downside/Risk: User concerns about government surveillance, holding/transaction caps
As we have seen above, it is not a problem today to eliminate tax evasion, black markets and illegal activity and not only preventing mass surveillance, but offering cryptographically guaranteed spender privacy. What problematic scenarios remain if such a solution is realized?
3.4 Motivation: Preserving seigniorage revenue
Downside/Risk: Inflation
This again is a purely political/policy topic, technology can do what is necessary, either way. Changing nothing to existing processes and adding a fully automated digital cash CBDC issuance would only increase the seigniorage revenue (as digital cash is a lot cheaper than physical cash and some more would transition over from bank deposits). While seigniorage can be linked to inflation, it's not the only factor influencing inflation and I am not enough of a specialist to assess if it is material or not.
3.5 Motivation: Mitigating currency substitution risk
Downside/Risk:
That is a decision for the central bank to facilitate or discourage in their design. Any retail CBDC project certainly will first and foremost be 1:1 with the physical currency I would expect. If the country has mismanaged its currency for too long, and all people want to do is switch to dollars or Bitcoin, no CBDC will fix that problem. Let's keep an eye on Argentina for example.
GOVERNMENT-FOCUSED
4.1 Motivation: Reducing international trade dependency on the USD
Downside/Risk: Governments fail to replace USD payments system liquidity, and end-up replacing USD fiat rail with USD digital rails (DEX, DeFi, AMMs...)
This maybe a topic for China, Russia and so forth, where it is unavoidable because of the weaponisation of the US dollar, while other countries would love to see more USD (like Argentina according to some presidential candidates). We can also return to Bretton Woods and this time give Keynes’ Bancor idea a try.
This concludes my second and final post on my input to John Kiff's table as referenced above.
If we limit ourselves to thinking about retail CBDCs, we should take away from this article that nearly all motivations can be satisfied very well with available technical solutions. Offline is the only motivation listed, where I am personally not comfortable with the safety of the technically available solutions.
Unfortunately so far, many proposals for CBDC offer comparably terrible or sub-optimal solution designs for many those problems. It is important for people to learn what is actually possible today in CBDCs, so that citizens and politicians can come to a point where they are able to make decisions, that they understand the long term consequences of.
