Key Results of Project Hamilton CBDC

In concluding my review of the Project Hamilton CBDC white paper, I want to summarize the seven key results of the project as identified by the authors, which are enlightening.

“CBDC design choices are more granular than commonly assumed.” The existing design models are too limiting. CBDC developers need to move beyond token-based or account-based designs and even beyond blockchain. Desired features need to dictate design, not vice versa.

“CBDCs can adopt a wide variety of design characteristics depending on public policy objectives and system performance demands.” Technical researchers can provide a lot of options to policymakers in CBDC design. But, policymakers need to establish “clear policy objectives” to guide design.

“Techniques from cryptography, distributed systems and blockchain technology can be combined to provide unique functionality and robust performance.” Designers need to break out of mindsets that limit them to just one approach to developing a CBDC design.

“Using a Byzantine fault tolerant (BFT) single state machine approach might cater for an unnecessarily strong threat model if the central bank directly operates the CBDC.” A central bank directly running its CBDC does not need a BFT design as the threat from malicious nodes is almost non-existent.

“Executing all transactions via a single-threaded state machine, whether generating a blockchain-like data structure or not, prevents horizontal scaling the maximum throughput of the system by adding more nodes.” A total ordering of all transactions (which means vertical scaling), if required, will run up against bandwidth and processor speed limitations.

“It is challenging to implement a non-interactive payment protocol while maintaining user-to-user privacy.” If two parties in a transaction cannot speak to each other to verify settlement to maintain privacy, then transactions need to be visible to all parties so that parties can independently verify settlement. This situation is not acceptable for a privacy-focused CBDC, making for complex design.

“The central bank does not need to retain all transaction information to implement a secure CBDC system.” It is appealing for privacy concerns that the central bank does not have to retain full transaction data (storing only unspent funds as opaque 32 byte hashes), but it makes self-custody more challenging for users.