Project Hamilton and OpenCBDC Frequently Asked Questions

Project Hamilton was a multi-year, collaborative research project between the MIT Digital Currency Initiative and the Federal Reserve Bank of Boston. The goal of Project Hamilton was to investigate the technical feasibility of a general purpose central bank digital currency (CBDC) that could be used by an economy the size of the United States and to gain a hands-on understanding of a CBDC’s technical challenges, opportunities, risks, and tradeoffs. This collaboration concluded in February 2023.

The first phase of Project Hamilton led to the release of OpenCBDC-tx, a research codebase for a transaction processor, and an associated research paper, A High Performance Payment Processing System Designed for Central Bank Digital Currencies. This was the first contribution to a larger open source project called OpenCBDC, which was maintained by the MIT DCI. The goal of this project was to help central bankers, policymakers, industry, academics, and others make decisions on how to best design this technology while promoting neutral, collaborative global research. Through OpenCBDC we hoped to engage a community of engineers and scholars, alongside government, business, and civil society leaders, in research and development to learn how digital currency systems could be designed to best advance privacy, user agency, innovation, and financial equity.

Project Hamilton’s Phase One goal was to investigate the technical feasibility of a high-throughput, low-latency, and resilient transaction processor that could provide flexibility for a wide-range of eventual CBDC design choices.

The goal for Project Hamilton was not to design a complete CBDC system. OpenCBDC was neither production-ready, nor did it provide the functionality needed for a working CBDC. We do not yet know if a CBDC is the best way for countries to achieve their public policy goals. Before they are deployed, we should have the data needed to design them in a way that improves user agency, privacy, and accessibility.

We built two architectures for a centralized transaction processor. The first architecture (the atomizer) processes transactions through an ordering server and can handle 170,000 transactions per second. The second architecture (2PC) processes transactions in parallel on multiple computers and can handle 1.7 million transactions per second. The main functional difference between our two architectures is that the atomizer materializes an ordered history for all transactions, while 2PC does not. As we explained in our paper, this highlights initial tradeoffs we found between scalability, privacy, and auditability.

Our modular design supports experimentation with models where intermediaries could take on a variety of different roles and serve different purposes, including the non-custodial model, or self-custody, where users can receive a payment without requiring an account with anyone (even the central transaction processor), similar to cash today.

Our current financial system still faces a number of frictions. The wide variety of exciting experimentation in cryptocurrencies is causing technologists and central bankers to rethink how existing payment systems might operate. A well-designed CBDC might contribute to a more interoperable financial system with a simplified institutional structure, capable of serving the public at a much lower cost.

Though there has been discussion about the policy dimensions of a CBDC, there were important technical ideas and questions missing from the conversation. DCI aimed to fill this gap by engaging technologists, user researchers, central bankers, private sector leaders, and academics in service of a more accessible, trusted, fair, and resilient economy. We didn't know if a CBDC could help improve our financial system, or how one might be best designed to do that, but we believed engaging in technical research was an important step in answering that question.

The MIT DCI’s interest in collaborating with the Boston Fed stemmed from a desire to have, as much as possible, a hand in ensuring that neutral, responsible research is being done with this technology before any policy decisions were made. Building and implementing helped us understand the problems and challenges better, putting us in a unique position to help shape a CBDC that emphasized privacy, user agency, and financial equity.

At the time, more than 87 countries (comprising over 90% of the global GDP)[1] were in various phases of CBDC research, development, and pilots, due in part to factors such as government interest and other external developments (e.g., privately-issued stablecoins). As discussed in the report “Money and Payments: The US Dollar in the Age of Digital Transformation”:, “the Federal Reserve is charged with promoting monetary and financial stability and the safety and efficiency of the payment system and is studying how a CBDC could improve on an already safe and efficient U.S. domestic payments system.” [2,3] Project Hamilton was part of this exploration.

Project Hamilton’s research focused solely on a hypothetical CBDC platform’s technical architecture. It was not intended to be a usable US CBDC nor did it analyze or propose solutions to the many policy, regulatory, or legal questions required of such an exploration.

Project Hamilton, the collaboration between The Boston Fed and the MIT DCI, concluded in February 2023. Although the OpenCBDC project has concluded, its research outputs remain an important contribution to the global conversation on digital currency systems and the future of public and private financial infrastructure. The research that began as Phase 2 of Project Hamilton was spun off into an independent project, called PArSEC, that is integrated into the OpenCBDC-tx codebase. You can learn more about this project here.

Traditionally, central bank money has taken two forms: (1) physical currency (cash) widely available for use by individuals, businesses and others, and (2) digital reserves held by eligible financial institutions at the central bank. CBDC is a generic term for a third version of central bank money that is digital, accessible to individuals (directly or intermediated), and a direct liability of the central bank.

CBDCs are typically grouped into two categories: retail and wholesale. “Wholesale CBDCs are intended for the settlement of interbank transfers and related wholesale transactions, for example to settle payments between financial institutions.” In contrast, “Retail CBDCs modify the conventional two-tier monetary system in that they make central bank digital money available to the general public, just as cash is available to the general public as a direct claim on the central bank.”[4]

A lot of the potential benefits, and potential harms, of a CBDC depend on the policy decisions made, and its final design and implementation. On the one hand, a CBDC could be an opportunity for a ground-up redesign of our legacy payment systems, offering a chance to reimagine market roles and incentives and to solve foundational problems in our financial system. If designed in the right way, a CBDC might strengthen user financial agency, increase competition, and standardize disparate data models, leading to more interoperability and creating a platform for innovation, much as the Internet created a platform for innovation on top of the transfer of information. On the other hand, there are many challenges around protecting user data, understanding impact to financial stability, and making sure not to discourage or prevent innovation in the private sector.

OpenCBDC focused on the technical design of a transaction processor to support a general purpose CBDC. Our research did not focus on an analysis of monetary policy. The Board of Governors of the Federal Reserve System put out a paper in January 2022 that outlines various policy considerations of a CBDC.

Yes. To support the scale of retail transactions in a large country such as the US and capture the benefits of faster, real-time payments, a CBDC transaction processor needs to process thousands of transactions a second and settle them quickly. One architecture we built (called the atomizer) can process 170,000 transactions per second and the other (2PC) can process 1.7 million transactions per second with settlement-time at less than 2 seconds for both.

We used techniques from cryptography and existing cryptocurrencies in designing the transaction processor to minimize the amount of data collected and retained by a central transaction processor. For instance, the central transaction processor only needed to store commitments to unspent funds as opaque 32 byte hashes.

We considered fault tolerance and did extensive experiments to ensure the system could continue to operate in case of failures, whether those might be due to hardware, natural disasters, or data centers being offline. But it’s worth noting that since this is research code, and it's definitely the case that there are bugs in research software—putting more eyes and minds toward improving the software, testing more architectures, and uncovering these vulnerabilities is a big reason why we open sourced our codebase.

OpenCBDC took select ideas from cryptography, blockchain technology, and classical distributed systems technologies to enable functionality like cryptographic proof of payments, atomic transfers, and flexible forms of authorization while maintaining robust performance in a transaction processor. Both of the architectures we developed use the Unspent Transaction Output (UTXO) model to represent user funds in the system, but we were interested in investigating other designs as well. One architecture we built (called the atomizer) can process 170,000 transactions per second and the other (called 2PC) can process 1.7 million transactions per second with settlement-time at less than 2 seconds for both.

Our first phase of research borrowed components from blockchain and cryptocurrency systems, but discarded some features of each. More information can be found in our technical paper. While CBDC is often associated with blockchain or distributed ledger technology, a CBDC does not require a blockchain if it is operating in one trust domain.

Users address and sign transactions using their public/private key pairs stored in their digital wallets, (as is the case in many cryptocurrencies). User wallets submit transactions to the centralized transaction processor to move money (represented as unspent funds).

First and foremost, OpenCBDC is not (nor is it intended to be) a complete, functioning CBDC. We barely began to explore the full slate of design choices available to a hypothetical CBDC. Our work in Phase One was scope-limited, in some of the following ways: (1) we had not yet implemented our design for privacy-preserving auditing, (2) we started with a UTXO model, but would have liked to contrast and compare to an account-balance model, (3) though we tried to store very little data in the transaction processor, we thought we could do better and provide stronger privacy guarantees using different cryptographic designs such as zero-knowledge proofs, (4) our system had limited programmability semantics, and (5) we had not implemented other essential parts of a CBDC, like secure wallets. We might investigate more of these questions in future work, and also hope that others will help by contributing to the open source code and design.

Since there are still open questions in many jurisdictions about how a CBDC might operate, we designed our system to support a variety of nuanced access models to help experiment and compare. To illustrate its flexibility, here are some examples of the types of design our system could support. Note that these lists are not exhaustive and are merely intended to be illustrative of the types of designs that OpenCBDC could or could not support. They are also not intended to be a commentary on the viability or likelihood of the eventual adoption of these choices. Our modular design supports experimentation with models where intermediaries could take on a variety of different roles and serve different purposes, but it could also support different types of intermediation. Under a non-custodial model (self-custody), users could receive a payment without requiring an account with anyone (even the central transaction processor), similar to cash today. Our design is also compatible with options where intermediaries offer custodial accounts to users who do not wish to maintain their own keys, and execute transactions on a user’s behalf using a pool of funds. Alternatively, it is also compatible with designs where users might seek help from intermediaries simply to back up their own keys, or different services might offer digital wallet software without necessarily taking custody of a user’s funds. Our design supports a choice where intermediaries could help mitigate denial of service attacks while the transaction processor still settles transactions with finality, or a choice where they could be involved in providing credentials to authorize certain public keys for high-value payments, while not being involved at other stages of transaction processing. These examples illustrate that policymakers potentially have many choices to make in how a CBDC might operate.

OpenCBDC borrowed heavily from innovations in blockchain technology, cryptography, distributed systems, and other disciplines that are key to decentralized cryptocurrencies and that have been at the core of MIT DCI’s research efforts since 2015. We tried to combine useful features of decentralized currencies into OpenCBDC.

A cryptocurrency, at least in a colloquial sense, refers to digital assets that are usually stored on a blockchain network that is not reliant on any central authority (such as a government or bank) to maintain it. Cryptocurrencies usually use software to control issuance, instead of being managed by a central bank.

In contrast to this, a central bank digital currency (CBDC) is best thought of as a digital form of a currency managed by a central bank (i.e. a digital form of the dollar, euro, pound, or yen etc). CBDC is a generic term for a new version of general purpose central bank money, one that is both digital and a liability of the central bank.

Bitcoin and other cryptocurrencies fulfill a very different use case than that of a potential CBDC. For instance, many users value Bitcoin and other cryptocurrencies because there is no central operator and instead, issuance and operation are controlled by a distributed network and software. Our OpenCBDC research explored the potential of CBDC to complement cash as well as other emerging and legacy payment systems, not to replace them.

Privacy, especially of one’s financial transactions, is extremely important for the safety, dignity, health, and wellbeing of every individual and of our society as a whole. We've observed the harms that poor data-privacy protections have had over the past few decades. With OpenCBDC we tried to design a system that stores very little data inside the transaction processor, and is compatible with even stronger privacy-preserving designs. We are continuing to explore more advanced cryptographic privacy preserving options in future research.

OpenCBDC is not in use as a digital currency; it is a research project. We hope this work will help inform regulators and policymakers about the technical feasibility and tradeoffs of various privacy options. We are trying to show that strong privacy-preserving designs can be practical at scale. However, ultimately, if a CBDC were ever to be deployed, decisions around privacy protections would be decided by policymakers.

The energy use of a centralized system is incomparable with energy use of a decentralized system, as they operate under different threat models and aim to achieve different goals. OpenCBDC is not meant to support a decentralized cryptocurrency, and so doesn’t need to use mining, or rely on proof of work or proof of stake. A system using OpenCBDC would use minimal energy. Its electricity consumption would be comparable to typical Internet services or centralized payment processors (such as Cash App, Venmo, Zelle, credit cards, etc.).