fbpx Engineering is the Key to the Debate Over Whether to Create a CBDC - Timothy Massad | Harvard Kennedy School

Engineering is the Key to the Debate Over Whether to Create a CBDC
By Timothy Massad
October 17, 2021

Any day now, the Federal Reserve Board will release a paper that discusses the advantages and disadvantages of a central bank digital currency or CBDC. The Boston Federal Reserve Bank is then expected to provide an update on Project Hamilton, its joint effort with MIT to design a hypothetical CBDC platform. While the Board’s policy paper will provoke a lot of reaction, the Project Hamilton update deserves as much or more attention. That’s because the only way we can decide whether a CBDC is worthwhile is to figure out exactly how it would work. That’s what the second report will begin to tell us. 

The Board of Governors paper is not expected to take a position on whether we should create a CBDC. Instead, it is likely to discuss the many policy issues raised by the idea.  These include whether a CBDC is a good way to advance financial inclusion, and whether it would disintermediate the banking system and reduce credit creation. Would it enable the government to know all our transactions and intrude on reasonable expectations of privacy, or can we ensure a reasonable level of anonymity? Do we need a CBDC to preserve the global primacy of the dollar, now that China has launched one? Although the paper is unlikely to provide any definitive answers, its language will be studied closely — as with FOMC statements — for clues as to what the Fed might ultimately recommend. That is particularly true because there is little agreement right now: Governors Quarles and Waller have publicly expressed skepticism about the need for a CBDC, while Governor Brainard has suggested a CBDC may be inevitable.

The Project Hamilton whitepaper, on the other hand, will describe how a U.S. CBDC might actually work. The results will be preliminary — the project has only been underway for about a year — but it will provide some important knowledge. For example, a major argument for a CBDC is to achieve faster payments. But because there are many ways to do that, we need to know how a CBDC might compare to the alternatives. How many transactions can be processed in a second, and what are the computing (and energy) requirements to achieve that? For example, Bitcoin can currently process around 5-7 transactions per second, and it requires massive amounts of energy, which is why Bitcoin will never be a payments system.2 VISA claims it can process 65,000 per second; actual throughput is estimated at around 1700. The major banks’ real-time payments initiative is less than VISA, and FedNow — the Federal Reserve’s current real-time payments initiative that is expected to be on line in 2023 — is likely to be in that same ballpark. On the other hand, while we don’t know the capability of China’s e-CNY, it is presumably in the vicinity of the Chinese mobile phone industry, which has achieved rates exceeding 500,000 per second

Equally important is resiliency — the percentage of time the system is up and running, as well as the time it takes to recover if there is an interruption. The Solana decentralized blockchain is reportedly the fastest blockchain at around 50,000 per second, but it  suffered a 17-hour outage in September, its second significant outage in nine months. That’s not something we can tolerate in a national currency. (However, the Fed’s systems have gone down for a few hours before as well, as in April 2021.) 

The Project Hamilton whitepaper will not only describe the platform architecture and these metrics. In addition, the actual code will be made available for inspection. That will enable third parties to give their own assessments of — and suggestions for — the architecture.   The public sector effort needs input from the incredible private sector talent that has driven innovation in blockchain and payments generally. 

The Project Hamilton whitepaper won’t address the policy issues in the Board’s paper. But unless we commit to more engineering work, the policy discussion — whether at the Fed, within Congress, or otherwise — will remain too abstract.  It will be a debate about core principles — do you value privacy more than preventing illicit activity? Do you think financial inclusion justifies some disintermediation of banks? We cannot resolve those issues in a vacuum, because the resolution involves striking a balance between competing objectives, and that requires knowing what’s feasible. We need an iterative process, a continuous feedback loop: the technology wizards cannot construct a hypothetical platform unless given some policy direction, and the policy discussion needs to be grounded in reality by the engineering. Moreover, the engineering work will likely generate policy issues we haven’t even thought of.  

The bottom line is we need a more intensive research and development effort to ultimately answer the question of whether we should create a CBDC. There is no single way to design a CBDC, and what is right for the U.S. will be different from what China is doing. China’s choices will not determine ours, but their actions should motivate us to speed up our work to determine the best path to modernize our payments system. Our private sector will generate more innovative ideas over time than the government, so we may prefer a design in which a CBDC is the core operating system on which private sector applications, properly regulated, can be built. We also need to be at the table as the international conversation about how to make systems interoperable picks up. 

All this requires an expanded effort that involves the best talent from the government, universities and the private sector. It’s not quite like the race to put a man on the moon, but it is certainly of great national importance.


1Research Fellow, Harvard Kennedy School; former Chairman, Commodity Futures Trading Commission; and former Assistant Secretary of the Treasury. 

2Of course, there are complexities to this and all measures of throughput, such as whether to consider layer 2 protocols for blockchains that can process more transactions off-chain, and whether transactions must be processed in a particular order or whether they can be processed in parallel.