Central Bank Digital Currency (CBDC) System Design: A Comprehensive Survey of Public Research (2019–2025)

MKitch3|Sept. 21, 2025

This is my white paper of the public research on CBDC system design across central banks, BIS/IMF handbooks and large technical pilots. This research is a year in the making and still has a long way to go. 

Executive summary

Public research converges on a few core CBDC design choices that determine performance, privacy, resilience and policy control. Across dozens of proofs-of-concept and pilots, three patterns recur: two-tier distribution with public–private roles; modular architectures that mix centralized and distributed components; and granular policy controls implemented via wallets and APIs rather than “programmable money” embedded in the ledger itself. Offline payments remain achievable but complex; privacy can be enhanced with selective disclosure or Chaum-style eCash techniques; and cross-border efficiency gains are real in wholesale settings, where PvP/DvP workflows and atomic settlement reduce settlement risk. 

1) Design goals and constraints

Policy objectives

Typical goals: maintain monetary sovereignty and singleness of money, improve payments resilience/competition, enhance financial inclusion and cross-border efficiency, and safeguard privacy proportional to AML/CFT obligations. Recent official surveys find 94% of central banks exploring CBDCs, with retail work most advanced and a sharp uptick in wholesale pilots. 

Non-functional requirements

CBDC systems target very high throughput and low latency, fault tolerance, cyber resilience, and robust governance. BIS emphasizes modular system design and the feasibility of combining centralized and decentralized components. 

2) Core architectural choices

2.1 Distribution model

  • Single-tier: central bank provides wallets and services directly. Simple but burdens private sector innovation and scale.
  • Two-tier (prevailing model): central bank runs the core infrastructure/ledger; intermediaries handle customer-facing services, onboarding, compliance and innovation. BIS Project Rosalind prototypes an API layer that exposes central bank ledger functions to private providers in a two-tier model.  

2.2 Ledger and processing

  • Centralized, sharded processors: Project Hamilton (MIT/Boston Fed) shows that a centrally managed, in-memory transaction processor can reach very high throughput while keeping the ledger technology agnostic; the codebase (OpenCBDC) demonstrates alternative data structures.  
  • DLT or hybrid: Many wholesale pilots (Helvetia, Cedar, Jura, mBridge, Dunbar) use permissioned DLT to enable atomic PvP/DvP across institutions and currencies, often with each currency on its own ledger bridged by orchestration.  

2.3 Token vs account abstractions

Designs vary between account-based models, UTXO-style tokens, or hybrids. BIS projects explore UTXO semantics for retail tokens (Rosalind glossary), while other work abstracts accounts at the API layer and treats “balance changes” as events. 

2.4 API-first architecture

Rosalind frames an extensible API layer to standardize integration, enable innovation, and enforce policy via access-controlled endpoints rather than custom ledger logic. 

3) Privacy, data minimization, and compliance

3.1 Spectrum of privacy

Central bank papers stress that CBDC privacy is not binary. Designers can hide data from some actors while revealing to others under due process, using architectural, cryptographic and governance controls. 

3.2 Techniques

  • Selective disclosure & PETs: Bank of Canada surveys PETs (ZK proofs, MPC, TEEs, differential privacy) for CBDC contexts, noting maturing but still limited production readiness.  
  • Chaumian eCash prototypes: BIS Project Tourbillon explores quantum-resistant eCash variants that offer payer anonymity while maintaining anti-counterfeiting controls and scalability.  
  • Policy direction in major jurisdictions: ECB’s preparation-phase reports emphasize “high privacy” for online and offline transactions, with holding limits and offline design under development. UK work considers privacy-enhancing approaches for a potential digital pound.  

3.3 AML/CFT and supervision

Policy levers tend to sit in wallet layers and onboarding processes; APIs can enforce tiered limits, KYC regimes, and transaction monitoring, preserving central bank separation from personal data where politically required. Rosalind explicitly targets compliance while retaining a two-tier model. 

4) Offline payments

Offline is defined as value transfer between devices without network connectivity. BIS Project Polaris provides the de facto handbook and a higher-level design guide, concluding there is no one-size-fits-all solution; solutions require secure hardware, tamper resistance, risk caps, lifecycles, and procedures for re-sync and double-spend handling. Most offerings are not yet live at scale. 

5) Resilience and security lessons from live deployments

  • DCash outage (ECCU): a region-wide interruption was traced to an expired certificate in the Hyperledger Fabric deployment, underlining certificate management and operational discipline as critical to CBDC availability.  
  • Sand Dollar (Bahamas): ongoing modernization aims to interoperate with a national fast payments platform; early research focused on inclusion outcomes and payment efficiency.  
  • eNaira (Nigeria): initial adoption and awareness challenges documented by IMF and CBN; architecture follows a two-tier DLT model with phased rollout.  
  • JAM-DEX (Jamaica): launch supported by onboarding incentives; adoption strategy research highlights the role of targeted bonuses.  

6) Cross-border and interoperability designs

6.1 Wholesale corridors

  • mBridge: multi-central-bank platform for instant cross-border settlement reached MVP in 2024; BIS subsequently stepped back, leaving central bank partners to continue development.  
  • Jura & Helvetia: SNB/Banque de France/BIS experiments proved PvP/DvP settlement with wCBDC integrated into banks’ core systems and legal frameworks.  
  • Cedar (NY Fed) & Cedar x Ubin+: FX spot settlement on DLT reduced settlement time to seconds in simulated environments, exploring multi-ledger atomicity.  
  • Dunbar: common multi-CBDC platform design and governance insights for cross-border payments across several central banks.  

6.2 Retail corridors

  • Icebreaker: hub-and-spoke model connecting domestic retail CBDCs for cross-currency payments with FX competition at the hub.  

7) Retail platform and API design

  • Rosalind (BIS/BoE): demonstrates how an API layer can mediate wallet functions, consent, and policy rules while keeping the core ledger minimal; glossary covers UTXO, RTP/ARTP, verifiable credentials.  
  • Sela (HKMA/Bank of Israel/BIS): introduces an “access enabler” intermediary to widen competition while maintaining cybersecurity and cash-like properties; non-banks can connect directly to the central bank ledger under this model.  
  • Aurum (HKMA/BIS): two-tier system issuing both intermediated CBDC and a CBDC-backed stablecoin, informing Hong Kong’s e-HKD research.  

8) The digital euro, digital pound and US policy research

  • Digital euro: ECB is in a preparation phase focusing on high privacy, offline capability, and holding limits while EU legislation progresses. Recent communications press lawmakers to accelerate the legal framework.  
  • Digital pound: BoE/HM Treasury 2023 consultation and 2024 response outline a two-tier model and emphasize privacy by design; separate work with MIT DCI explores privacy-enhancing techniques.  
  • United States: Federal Reserve’s 2022 discussion paper and public comment summary frame benefits, risks and design considerations without endorsing issuance. Technical research at the New York Fed and Boston Fed continues via Cedar and Hamilton.  

9) Technology building blocks

  • Identity & credentials: tiered KYC with verifiable credentials; policy knobs (limits, age-restricted features) applied at wallet layer.  
  • Cryptography: ZK proofs, VOPRFs and blind signatures are under active evaluation; eCash variants show strong privacy for payer anonymity with anti-counterfeiting controls.  
  • Offline secure elements: secure enclaves/SE chips and tamper-resistant counters mitigate double-spend; reconciliation protocols cap offline risk exposure.  
  • Message and data standards: ISO 20022 alignment and standardized APIs are recurring themes in BIS/IMF materials; resilience requires disciplined key, cert and secrets management, per DCash lessons.  

10) Governance, risk and operational readiness

  • Cyber and operational resilience: IMF’s CBDC handbook chapters and notes focus on securing the ecosystem across central bank, intermediaries and vendors, including incident response, change control and supply-chain risks.  
  • Legal positioning: EU is actively legislating a digital euro; UK and US remain in consultation/research phases. Wholesale pilots often operate under existing legal frameworks with central bank oversight.  

11) Open design debates (2025)

  1. How much privacy is enough? Europe signals strong privacy commitments; technical PETs are improving but are not yet “turnkey” at national scale.  
  2. Retail vs wholesale first: Many jurisdictions prioritize wholesale CBDC to resolve settlement risk and cross-border frictions; retail remains politically sensitive.  
  3. Offline at scale: Feasible, but device security, risk caps, user UX and merchant hardware remain open challenges.  
  4. Interoperability: Competing architectures exist for cross-border flows (hub-and-spoke vs shared platforms vs interlinked ledgers); governance is as hard as the tech.  
  5. Role of central banks vs private sector: Sela and Rosalind show viable models for widening competition while preserving the central bank core.  

12) Comparative snapshot of flagship projects (non-exhaustive)

Project

Scope

Key ideas

Notable takeaways

Hamilton (US)

High-throughput retail core processor

Centralized, modular, code released as OpenCBDC

Ledger-agnostic engine can hit very high TPS; policy left to wallet/API layers. 

Rosalind (BIS/BoE)

Retail API layer

Two-tier, API-first, wallet functions and consent

Standardized APIs accelerate innovation while central bank stays minimal. 

Polaris (BIS)

Offline payments

Device security, counters, risk caps

No universal solution; operational design equals cryptographic design in importance. 

Sela (HK/IL)

Retail access model

“Access enabler” broadens intermediaries

Competition and security can coexist; non-banks may connect to core. 

Aurum (HK)

Retail prototype

Two token types incl. CBDC-backed stablecoin

Useful design space for rCBDC plus tokenized deposits. 

mBridge (HK/TH/CN/UAE …)

Multi-CBDC wholesale cross-border

Shared platform for instant settlement

Reached MVP; BIS exited oversight role as partners continue. 

Cedar (NY Fed)

Wholesale cross-border FX

Multi-ledger atomic settlement

FX PvP in seconds in a lab setting; complements global interlinking work. 

Jura & Helvetia (SNB/BdF/BIS)

Wholesale DvP/PvP

Integration with banks’ core systems

Feasible under Swiss law; legal and ops integration tractable. 

Icebreaker (Nordic/IL)

Retail cross-border

Hub-and-spoke FX with competition

Pathway for connecting domestic rCBDCs across borders. 

Digital euro (ECB)

Retail program

High privacy, offline, limits; legislation pending

Tech work advancing while EU law proceeds. 

13) Practical design checklist (what consistently works)

  1. Start two-tier with an API gateway between the core ledger and intermediaries; build policy in wallets and APIs.  
  2. Target ledger minimalism, keep programmability at the edges; use event-driven integration to existing RTGS and fast-payments systems.  
  3. Engineer privacy by design with selective disclosure and PETs; adopt jurisdiction-specific defaults and due-process access controls.  
  4. Treat offline as a separate subsystem with its own risk, device, and lifecycle model; cap value and frequency while offline.  
  5. Plan for cross-border early: decide whether to interlink domestic systems (Icebreaker), join shared platforms (mBridge/Dunbar), or pursue bilateral corridors (Jura/Helvetia).  
  6. Don’t neglect ops: certificates, keys, and change control can take you down faster than code bugs, as DCash showed.  

14) Annotated bibliography (selected, by theme)

System architecture and APIs

• BIS: CBDCs – System design (2024). Modular, mix-and-match components; privacy as a key design axis. 

• BIS/BoE: Project Rosalind report (2023). API prototypes and wallet functionality. 

• MIT/Boston Fed: Project Hamilton / OpenCBDC (2022). High-performance retail core. 

Offline payments

• BIS Polaris: Handbook (May 2023) and High-level design guide (Oct 2023). Canonical offline design references. 

Privacy

• Bank of Canada: Privacy in CBDC technology (2020) and Privacy-Enhancing Technologies for CBDC (2025). 

• BIS: Project Tourbillon (2023). eCash with privacy/security/scalability. 

Wholesale cross-border

• NY Fed: Project Cedar (2022–23). FX PvP on DLT, multi-ledger atomicity. 

• BIS/partners: Project Dunbar (2022), mBridge (2022–24), Jura (2021), Helvetia (2022). 

Retail cross-border

• BIS: Project Icebreaker (2023). Hub-and-spoke rCBDC corridor with competitive FX. 

Regional deployments

• Bahamas: Sand Dollar modernization (2025) and inclusion studies. 

• Nigeria: eNaira design paper (2021) and IMF one-year review (2023). 

• Jamaica: adoption and incentive design. 

• ECCU: DCash outage post-mortems. 

Jurisdictional programs and law

• ECB digital euro prep-phase updates and legal track. 

• BoE/HMT digital pound consultation and responses. 

• Federal Reserve: Money and Payments (2022) + public comments summary (2023). 

15) Minimum viable blueprint for a retail CBDC (synthesized)

  1. Core: centralized, scalable transaction processor with append-only log and deterministic state machine; HSM-backed keying and continuous audit. Hamilton-style throughput targets.  
  2. Interfaces: Rosalind-style API gateway enforcing rate limits, consent, limits, tiered KYC and programmability via rules engines.  
  3. Distribution: two-tier intermediaries (banks and non-banks; Sela access-enabler option) for onboarding, AML, customer support.  
  4. Wallets: reference mobile wallet and SDK with PETs for selective disclosure and offline risk caps per Polaris.  
  5. Resilience: multi-region active-active, cert automation, staged rollouts, chaos testing; explicit incident runbooks learned from DCash.  
  6. Cross-border: interlinking strategy evaluated early (Icebreaker hub vs mBridge/shared corridors vs bilateral PvP/DvP like Jura).  

16) Appendix: quick pointers to primary sources

  • BIS “CBDCs – System design” PDF (2024).  
  • BIS Project Rosalind report (2023).  
  • BIS Project Polaris handbook + design guide (2023).  
  • MIT/Boston Fed Project Hamilton + OpenCBDC.  
  • NY Fed Project Cedar Phase I and technical appendix.  
  • BIS Projects mBridge, Dunbar, Jura, Helvetia; updates and PDFs.  
  • ECB digital euro preparation-phase updates (2024).  
  • BoE/HMT digital pound consultation (2023) and site (2025).  
  • IMF CBDC Virtual Handbook: cybersecurity and design notes (2023–24).  
  • Live deployments: Sand Dollar (Bahamas), eNaira (Nigeria), JAM-DEX (Jamaica), DCash (ECCU).  

Bottom line

If you distill the public research, the safest, most future-proof pattern is a two-tier, API-first system with a minimal core, PET-hardened wallets, explicit offline subsystem, and an early cross-border strategy. The rest is governance, ops and politics, which, as DCash and EU legislative delays remind everyone, can make or break the tech. 



Posted

views

Tags