MK3 BLOG

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)

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. 

MKitch3|Sept. 21,2025

You can’t open a financial journal or scroll a central banker’s LinkedIn feed without stumbling on four letters: CBDC. Central Bank Digital Currency.

Depending on who you ask, it’s either the evolution of money, or the most polite dystopia since QR codes on restaurant menus. But strip away the hype, and what you find is a mountain of research papers, pilots, and stress-tested prototypes. Taken together, they form a rough blueprint of what a CBDC system will actually look like if and when the switch gets flipped.

This piece digs into that blueprint—the tradeoffs, the pilots, and the recurring design patterns that matter.

Why are central banks obsessed with this?

At a high level, the goals are surprisingly sober:

• Keep control of monetary sovereignty as cash usage declines.

• Boost payment resilience in case commercial systems collapse.

• Nudge competition in retail payments where a handful of private players dominate.

• Explore inclusion and cheap cross-border rails that don’t take three days and a kidney to settle.

As of 2025, 94% of central banks are officially “exploring” a CBDC. Translation: everyone’s tinkering, but only a handful are in live production.

Core design choices

The research converges on a few forks in the road:

1. Distribution model: The overwhelming favorite is “two-tier.” The central bank runs the core ledger, while private banks and fintechs handle onboarding, compliance, and wallet innovation. BIS’s Project Rosalind is the poster child here, sketching out an API layer that lets intermediaries plug in without the central bank becoming a retail help desk.

2. Ledger structure: Some experiments lean into distributed ledgers (think wholesale corridors like Project Jura or mBridge), while retail pilots often look suspiciously like a high-performance centralized database (see Project Hamilton’s blazing throughput demo).

3. Token vs. account: Do you want each digital “note” to exist like a token (UTXO style), or do you just update account balances? Answer: both, depending on who’s running the pilot.

4. Programmability: Everyone likes to whisper about “programmable money.” In reality, most designs punt policy enforcement to the wallet and API layer—transaction limits, KYC rules, consent frameworks—not hard-coded into the core ledger.

The privacy dilemma

This is where the politics crash into the math. CBDCs force societies to pick a point on the spectrum between cash-like anonymity and panopticon-level traceability.

Options on the table:

• Selective disclosure: Share data only with regulators when due process demands it.

• Privacy-enhancing tech: Zero-knowledge proofs, blind signatures, multiparty computation—the usual cryptography suspects, though still not plug-and-play at national scale.

• Chaumian eCash 2.0: BIS’s Tourbillon prototype tested anonymous, quantum-resistant tokens that can still be audited for counterfeits.

Europe is pushing hardest on “high privacy.” The US prefers to mumble vaguely about “balancing innovation and compliance.”

Offline payments: the holy grail nobody has solved

Everyone wants cash-like resilience—value that changes hands without network coverage. The BIS Polaris handbook lays out the requirements: tamper-resistant hardware, risk caps, reconciliation protocols, and a tolerance for lost devices. But no one has rolled out a national-scale solution yet. Offline CBDC remains the most technically gnarly corner of the map.

Field lessons: what went wrong and right

• DCash (Eastern Caribbean): The network went dark because someone forgot to renew a security certificate. Let that sink in: a digital currency taken down by the IT equivalent of an overdue library book.

• Sand Dollar (Bahamas): First-mover advantage, but still struggling with adoption. The tech works, the people are ambivalent.

• eNaira (Nigeria): Same story—big launch, lukewarm uptake. Reminds us that you can build the rails, but you can’t force the train to run.

• JAM-DEX (Jamaica): Got attention by literally paying people to sign up. Adoption through incentives—go figure.

The cross-border obsession

Domestic CBDCs are one thing. The real prize is cross-border payments: instant, cheap settlement without correspondent banks clipping the ticket.

• mBridge (China, UAE, Thailand, Hong Kong): Live MVP for wholesale settlement across currencies.

• Project Cedar (NY Fed): Demonstrated atomic FX settlement in seconds.

• Project Jura & Helvetia (Europe/Switzerland): Proved delivery-versus-payment on tokenized assets with wholesale CBDC.

• Icebreaker (Nordics + Israel): Hub-and-spoke model for retail CBDCs exchanging across borders.

The tech works. The sticking point is governance—who runs the hub, who enforces rules, and who eats the cost of failure.

So what’s the “safe” design?

If you distill hundreds of pages of public research, you get a recipe:

• Two-tier distribution with a central bank core and intermediaries at the edge.

• API-first architecture so wallets and fintechs can innovate without destabilizing the base.

• Minimal core ledger, leaving programmability and policy knobs to the wallet/API layer.

• Privacy-enhancing features baked in early, with selective disclosure as the default.

• Dedicated offline subsystem with risk caps and secure hardware.

• Interoperability plan from day one, whether through shared platforms (mBridge), interlinked ledgers (Jura), or hub-and-spoke models (Icebreaker).

And above all: operational discipline. The DCash outage taught everyone that grand designs crumble if you forget to renew a certificate.

The open debates

• How much privacy is enough?

• Should retail or wholesale CBDC come first?

• Can offline ever really be secure?

• Do central banks risk crowding out private innovation?

• Who actually governs cross-border corridors?

None of these questions have neat answers, which is why CBDC papers read like Choose-Your-Own-Adventure novels.

Final thought

CBDCs aren’t just a monetary experiment. They’re a stress test of how much trust people are willing to hand back to central banks in a digital age. The architecture is emerging—two-tier, API-driven, privacy-tempered—but the politics will decide if anyone actually uses the thing.

Money is already mostly digital. The real question is whether the next upgrade to the operating system comes from the public sector, the private sector, or some uneasy hybrid.