Project Hamilton takes its first run at modeling a digital dollar
MIT and Boston Fed ran computer models for a potential central bank digital currency system and published a white paper on their findings.
Imagine that you’re buying a coffee. But instead of fumbling around in your wallet for crumpled paper dollars or a credit card, you can tap a digital wallet app on your phone to send some digital dollars to the shop owner. The payment would be instant, and unlike Venmo, you wouldn’t need to go through—or even have—a private bank account. That’s the promise behind a newly proposed form of money called central bank digital currencies, or CBDC.
These CBDCs would be a digital representation of a government-issued currency that can be accessed through a government-made wallet app, and many countries have been probing the feasibility of this idea. The Bahamas has already launched a digital sand dollar, and China is in a late-stage pilot for its digital yuan.
The Federal Reserve Bank of Boston and the Massachusetts Institute of Technology first announced they were teaming up to investigate how the US might go about building a central bank digital currency back in 2020. Today, they published the first whitepaper from their technology research, which they call Project Hamilton. They have grouped their initial findings into a “Phase 1” program, and they’re making the software code for the models they developed under this program available through an MIT open-source license on Github.
“To my knowledge, this is the first time the Fed has ever issued code under an open-source license,” Boston Fed executive vice president Jim Cunha said in a press call. “We thought that was important so that others can learn from this work, but also so they can comment on the strengths and weaknesses and contribute to the code base itself.”
Researchers can also use this platform to gather data, and compare how well it works against similar systems in the future.
What MIT and Boston Fed have currently built is not yet a complete system. It’s more of a processing engine that can store and move digital currency. “The core of what we built is a high-speed transaction processor for a centralized digital currency, to demonstrate the throughput, latency, and resilience of a system that could support a payment economy at the scale of the United States,” Neha Narula, director of MIT’s Digital Currency Initiative, said in an press release. “This project is not a comment on whether or not the US should issue a CBDC… [It] serves as a platform for creating and comparing more viable designs, and provides a place to experiment and collaborate on more advanced digital currency functionality.”
Creating and running technical mockups like this could help policymakers think about what type of model is best if and when they decide to roll out a formal central bank digital currency project. “We don’t yet know if a CBDC is the right way forward. But we believe that doing neutral, responsible research is the only way we can assess the questions and arrive at informed answers,” Narula said, acknowledging that while CBDCs could create a more inclusive financial system, other alternatives exist as well. “Ideally, this work that we’re doing will complement policy discussions.”
The Phase 1 program tested two different code bases, with two different designs that illustrate some of the tradeoffs that might need to be made between scalability, privacy, and auditability. In both designs, users received digital wallets. The wallets had public keys that tell the funds where to go, and could create cryptographic signatures to authorize payments. The wallets were used to interact with a centralized transaction processor.
In the trial runs, the Hamilton transaction processor, a stand-in for the central bank, stores the encrypted payments—which contain a value and is associated with a public key—as unspent central bank funds. When a wallet signs transactions, it destroys the funds in the sender’s account and creates an equivalent amount of new funds in the receiver’s account. The transaction processor validates transactions. “In this version of our work, there are no intermediaries, fees, or identities outside of public keys,” the Federal Reserve Bank of Boston explained in an executive summary.
Proof-of-work, which Bitcoin and Ethereum use to mint new coins and validate transactions, consumes an absurdly large amount of electricity. Because Hamilton’s system is centralized, it “doesn’t need to use mining or proof-of-work, or proof-of-stake, or any of these other techniques that are used in cryptocurrencies,” Narula said. “A system built on the technology we’ve implemented so far would use minimal energy. We think its electricity consumption would be comparable to typical centralized payment processors like credit cards, Venmo, Zelle, or Cash App.”
One of the designs used a single ledger to record all transactions in the order they were processed, just like most cryptocurrency blockchains do. Validated transactions had to go through an ordering server that groups them into batches, but it caused a bottleneck of 170,000 transactions per second. This design is easier to audit. However, the Fed noted that “storing the history of transactions implies the central transaction processor can reconstruct the transaction graph, which, in combination with other data sources, could reveal sensitive user information.”
The other design was faster, and could process 1.7 million transactions per second. It processes transactions in parallel on multiple computers, and the quantity of transactions could scale linearly with the addition of more server computers.
Both systems can still function with the loss of two datacenter locations, the team said, accounting for unexpected events like natural disasters or internet outages.
“Moving forward, we’ll be defining a number of use cases that focus on different design and possibly policy questions,” Cunha said. Not only will this allow them to see how the system behaves when more complex components like smart contracts and offline payments are added, but it will also allow them to understand where policy and design can clash. “For example, if one policy goal was to maximize privacy, and the other is to stop criminal activity, those create conflicts from a technology perspective in how you design the system.”