The CBDC Design Space
Learning Objectives
Apply the CBDC Design Pyramid framework to analyze any CBDC project
Distinguish between retail and wholesale CBDCs and their respective use cases
Compare direct and intermediated distribution models
Contrast token-based and account-based access models
Explain why the two-tier intermediated model has become the default approach
When most people think about building a CBDC, they think about technology: blockchain or database? What consensus mechanism? Which cryptography? But these technical questions are secondary to more fundamental design decisions.
- Is this currency for everyone or just banks?
- Do citizens hold accounts at the central bank or at commercial banks?
- Does the currency work like cash (anonymous bearer instrument) or like a bank account (linked to identity)?
These architectural choices, made before technology selection, determine what kind of CBDC emerges. A retail, direct, token-based CBDC is fundamentally different from a wholesale, intermediated, account-based CBDC—even if both use identical underlying technology.
This lesson provides the framework for thinking about these choices systematically.
The CBDC Design Pyramid organizes design decisions into hierarchical layers. Decisions at lower layers constrain options at higher layers. Like building construction, you can't change the foundation after building the walls.
THE CBDC DESIGN PYRAMID
/
/
/ AC
/ CESS
/--------\ Layer 5: Who can use it? How?
/TECHNOLOGY
/------------\ Layer 4: What systems power it?
/ ARCHITECTURE
/----------------\ Layer 3: How is it structured?
/ OPERATORS
/--------------------\ Layer 2: Who runs it?
/ POLICY
/------------------------\ Layer 1: Why does it exist?
Each layer builds on layers below.
Decisions at lower layers constrain higher layers.
```
The foundation layer answers: Why are we building this?
LAYER 1: POLICY FOUNDATION
- What problem are we solving?
- What outcomes do we want?
- What constraints exist (legal, political)?
- Who decides these questions?
- Motivations (from Lesson 2)
- Legal framework
- Political mandate
- Success criteria
- Risk tolerance
- "This CBDC is for financial inclusion"
- "Privacy must be equivalent to cash for small transactions"
- "We will not allow programmable restrictions"
- "The banking system must not be harmed"
Why Foundation Matters:
These policy decisions constrain everything above.
If policy requires cash-like privacy, technology
must support it.
If policy prohibits bank disintermediation,
architecture must prevent it.
```
The second layer answers: Who runs the system?
LAYER 2: OPERATORS
- Which entities operate system components?
- What roles and responsibilities exist?
- How are operators governed?
- What liability do operators bear?
- Central bank
- Commercial banks
- Payment service providers
- Technology vendors
- Wallet providers
- Agent networks
- Central bank controls everything
- Central bank + licensed intermediaries
- Consortium model
- Delegated operations
- "Central bank operates core ledger only"
- "Banks provide customer-facing services"
- "Third parties can create wallets with approval"
- "Agent network for cash-in/cash-out"
The third layer answers: How is the system structured?
LAYER 3: ARCHITECTURE
- Single-tier or multi-tier?
- Centralized or distributed?
- Monolithic or modular?
- What are the system boundaries?
- Direct (central bank ↔ public)
- Intermediated (central bank ↔ intermediaries ↔ public)
- Hybrid (elements of both)
- Single-tier direct
- Two-tier intermediated
- Multi-tier cascaded
- Core ledger
- Distribution layer
- User interface layer
- Integration layer
- "Two-tier model with bank distribution"
- "Separate wholesale and retail systems"
- "Modular architecture with API layer"
- "Federated validation among banks"
The fourth layer answers: What systems power the CBDC?
LAYER 4: TECHNOLOGY
- Centralized database or distributed ledger?
- What consensus mechanism?
- What cryptographic standards?
- What infrastructure requirements?
- Traditional centralized database
- Private/permissioned DLT
- Hybrid approaches
- Ledger technology
- Identity system
- Wallet technology
- Network infrastructure
- Security systems
- "Private blockchain with BFT consensus"
- "Centralized database for speed"
- "HSM-based key management"
- "Cloud infrastructure with sovereignty controls"
The top layer answers: Who can use it and how?
LAYER 5: ACCESS
- Who can hold CBDC?
- What identity requirements exist?
- What limits apply?
- What interfaces are available?
- Token-based (bearer instrument)
- Account-based (identity linked)
- Tiered (different levels)
- Anonymous (no ID needed)
- Pseudonymous (identifier without identity)
- Full KYC (complete identification)
- Tiered KYC (levels by amount)
- Mobile wallet apps
- Bank app integration
- Physical cards
- Web interfaces
- USSD/SMS (basic phones)
- "Tier 1: No ID, €100 limit"
- "Tier 2: Basic ID, €3,000 limit"
- "Tier 3: Full KYC, no limit"
The pyramid helps analyze any CBDC:
PYRAMID ANALYSIS PROCESS
- What problem is it solving?
- What constraints are stated?
- What does success look like?
- Who runs what?
- What's the governance structure?
- Where does liability sit?
- Direct or intermediated?
- Single or multi-tier?
- How do components connect?
- What's the ledger type?
- Centralized or distributed?
- What are key technical features?
- Who can use it?
- What ID is needed?
- What limits exist?
CONSISTENCY CHECK:
Do higher layers align with lower layer decisions?
Does access model match policy goals?
Does technology enable stated architecture?
The most fundamental CBDC distinction is between retail and wholesale applications. This choice affects everything.
RETAIL VS. WHOLESALE: THE CORE DISTINCTION
- For general public (citizens and businesses)
- Everyday transactions
- Many users, many transactions
- Consumer-grade interfaces
- Replaces or supplements cash
Example: "Anyone can hold digital euros for daily payments"
- For financial institutions only
- Interbank settlement
- Fewer users, larger transactions
- Institutional-grade systems
- Replaces or supplements reserves
Example: "Banks settle with each other using digital central bank money"
THE KEY DIFFERENCE:
Retail: Public access to central bank money
Wholesale: Institutional access (which already exists via reserves)
```
RETAIL CBDC CHARACTERISTICS
- General public: millions to billions
- Businesses: millions
- Any legal entity or individual
- Many transactions: millions to billions daily
- Small value: typically < $1,000
- Diverse purposes: payments, savings, transfers
- User-friendly interfaces
- High availability (24/7)
- Fast confirmation (seconds)
- Scalability (peak demand handling)
- Accessibility (various device types)
- Privacy expectations of public
- Financial inclusion requirements
- Competition with existing payments
- Banking system impact
- Offline capability needs
Policy Complexity:
HIGH - touches every citizen, political implications
```
WHOLESALE CBDC CHARACTERISTICS
- Commercial banks: typically dozens to hundreds
- Central bank: one (as issuer)
- Possibly: Some large financial institutions
- Fewer transactions: thousands daily
- Large value: millions to billions per transaction
- Specific purposes: settlement, reserves
- Institutional security
- Regulatory compliance
- Audit capability
- Integration with existing systems
- Deterministic settlement
- Integration with legacy systems
- Regulatory approval
- Operational risk management
- Cross-border interoperability
Policy Complexity:
LOWER - affects institutions, not direct public
```
WHY RETAIL VS. WHOLESALE MATTERS
DIFFERENT PROBLEMS:
Public access to digital central bank money
Payment efficiency for consumers
Financial inclusion
Cash replacement
Interbank settlement efficiency
Cross-border payment infrastructure
Securities settlement
Reserve management
DIFFERENT CHALLENGES:
Scale: Must handle consumer volumes
UX: Must be usable by everyone
Privacy: Public expectations
Politics: Voter concerns
Integration: Must work with existing infrastructure
Compliance: Institutional regulatory requirements
Governance: Inter-institutional agreements
Standards: International compatibility
DIFFERENT TIMELINES:
Less politically controversial
Easier to pilot (fewer users)
More incremental (enhance existing)
Faster to implement
More politically contentious
Harder to pilot (need scale)
More disruptive (new paradigm)
Slower to implement
Many countries explore both, but separately:
COMBINED APPROACH: RETAIL AND WHOLESALE
Model: Separate systems serving different purposes
- Retail: e-CNY (public digital currency)
- Wholesale: Cross-border pilots (mBridge)
- Different architectures, different purposes
- Retail: Digital Euro (public)
- Wholesale: Exploring separately
- Sequential approach (retail first)
- Wholesale: Project Ubin (advanced)
- Retail: No current plans
- Focus on institutional innovation
- Different requirements, different solutions
- Wholesale can move faster
- Retail can be more cautious
- Reduced complexity per system
- Potential integration challenges later
- Duplicated infrastructure
- Coordination overhead
---
Once retail CBDC is chosen, the next major decision is distribution architecture: does the central bank serve customers directly, or through intermediaries?
DIRECT MODEL: CENTRAL BANK ↔ PUBLIC
┌────────────────┐
│ CENTRAL BANK │
│ │
│ - Issues CBDC │
│ - Holds accts │
│ - Processes │
└───────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌────▼───┐ ┌────▼───┐ ┌────▼───┐
│ User A │ │ User B │ │ User C │
└────────┘ └────────┘ └────────┘
Every citizen has account directly with central bank.
Central bank provides all services.
No commercial bank intermediation for CBDC.
- Direct relationship: citizen ↔ central bank
- Central bank operates customer systems
- No intermediary fees
- Disruptive to banking system
Advantages of Direct Model:
DIRECT MODEL ADVANTAGES
- Single system, single operator
- No coordination with banks
- Clear liability (central bank)
- No intermediary costs
- Direct transmission of policy
- Fastest possible settlement
- Anyone can have account
- No bank gatekeeping
- Maximum inclusion potential
- Central bank has full visibility
- Direct policy implementation
- No intermediary friction
Disadvantages of Direct Model:
DIRECT MODEL DISADVANTAGES
- Central bank becomes retail bank
- Millions of customers to serve
- Customer service infrastructure
- Fraud management responsibility
- Not central bank's expertise
- Deposits potentially flee to CBDC
- Bank funding disrupted
- Credit creation affected
- Political resistance from banks
- Central bank not designed for scale
- Infrastructure investment massive
- Peak demand management
- Geographic service coverage
- Central banks manage monetary policy
- Not retail service providers
- Different institutional culture
- Different skill sets required
INTERMEDIATED MODEL: CENTRAL BANK ↔ INTERMEDIARIES ↔ PUBLIC
┌────────────────┐
│ CENTRAL BANK │
│ │
│ - Issues CBDC │
│ - Wholesale │
│ - Policy │
└───────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌────▼───┐ ┌────▼───┐ ┌────▼───┐
│ Bank A │ │ Bank B │ │ PSP C │
│ │ │ │ │ │
│Wallets │ │Wallets │ │Wallets │
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
┌──────┼──────┐ │ ┌──────┼──────┐
│ │ │ │ │ │ │
User User User User User User User
Central bank serves intermediaries.
Intermediaries serve public.
Two-tier (or multi-tier) structure.
- Indirect relationship: citizen ↔ bank ↔ central bank
- Banks/PSPs provide customer services
- Preserves banking system role
- Less disruptive
Advantages of Intermediated Model:
INTERMEDIATED MODEL ADVANTAGES
- Banks already have customers
- Existing KYC systems
- Existing customer service
- Existing distribution networks
- Banks maintain customer relationships
- Deposit base less threatened
- Credit creation preserved
- Political resistance reduced
- Central bank does what it does well
- Monetary policy, not retail banking
- Wholesale operations (familiar)
- Regulatory oversight
- Distributed operational burden
- Banks already handle scale
- Competition drives quality
- Natural redundancy
Disadvantages of Intermediated Model:
INTERMEDIATED MODEL DISADVANTAGES
- Multiple parties to coordinate
- Integration requirements
- Governance challenges
- Liability questions
- Banks can fail
- What happens to CBDC in failed bank?
- Operational dependency
- Counterparty considerations
- Banks may restrict access
- Fee layers possible
- May undermine inclusion goal
- Bank priorities may differ from policy
- Policy transmission through intermediaries
- Slower to implement changes
- Intermediary compliance required
- More monitoring needed
Reality is often more complex than pure models:
HYBRID DISTRIBUTION MODELS
- Normally through banks
- Central bank provides basic account for unbanked
- Fallback option
- Banks for full-feature accounts
- PSPs for basic accounts
- Multiple paths to access
- Banks for CBDC distribution
- Fintechs for wallet services
- Central bank for core ledger
- Each does what they do best
- Multiple intermediary types compete
- Central bank sets minimum standards
- Market determines winners
- Users choose provider
MOST COMMON APPROACH:
Two-tier with multiple intermediary types
The two-tier intermediated model has become the default:
WHY TWO-TIER IS THE DEFAULT
- Banks are politically powerful
- Direct model threatens banks
- Path of least resistance
- Central banks aren't equipped for retail
- Building capability would take years
- Banks already have infrastructure
- Distributed operational risk
- Bank failure = limited impact
- Central bank failure = system failure
- Current system is two-tier (cash + deposits)
- CBDCs follow familiar pattern
- Evolutionary, not revolutionary
CONSENSUS VIEW:
"Central banks should do what central banks do.
Banks should do what banks do.
CBDC doesn't change this division of labor."
CRITICAL TAKE:
Two-tier may be pragmatic, not optimal.
It preserves existing power structures.
More innovative models face political barriers.
The final critical dichotomy is how users access CBDC: as tokens (bearer instruments) or accounts (identity-linked balances).
TOKEN VS. ACCOUNT: THE FUNDAMENTAL QUESTION
- Validity verified by examining the token
- Possession = ownership
- No identity required to use
- Like physical cash
- Validity verified by checking identity
- Ownership linked to identity
- Identity required for access
- Like bank accounts
THE ANALOGY:
I don't need to know who you are
You prove you have valid $100
Transaction complete
I need to identify you as John Smith
System checks your identity
Then processes transaction
TOKEN-BASED CBDC
How It Works:
┌────────────┐ ┌────────────┐
│ Token │──────→│ Token │
│ (valid $10)│ │ (valid $10)│
│ Sender has │ │ Receiver │
└────────────┘ └────────────┘
- Token is the value
- Transfer = move token
- Recipient verifies token, not sender
- Works without identity
- Bearer instrument: whoever holds it, owns it
- Verify object, not person
- Natural privacy (no identity link)
- Loss = permanent (like losing cash)
- Offline potential (token is self-contained)
- Digital signatures on tokens
- Cryptographic verification
- Hardware security (to prevent copying)
- Or secure software environments
Advantages:
TOKEN MODEL ADVANTAGES
- No inherent identity link
- Cash-like anonymity possible
- Transaction doesn't require identifying yourself
- Token is self-contained
- Can verify without network
- Transfer without central system
- Resilient to outages
- No ID required to receive
- Anyone can accept tokens
- No account relationship needed
- Familiar mental model
- Physical cash replacement
- Bearer instrument properties
Disadvantages:
TOKEN MODEL DISADVANTAGES
- Lose device = lose tokens
- No recovery mechanism
- Like losing physical cash
- User responsibility
- Hard to implement KYC
- AML monitoring difficult
- Regulatory concerns
- May not be allowed above thresholds
- Preventing double-spending is hard
- Requires secure hardware or clever cryptography
- Implementation more complex
- Less mature approaches
- Harder to add programmability
- Account features (statements, etc.) challenging
- Integration with other services harder
ACCOUNT-BASED CBDC
How It Works:
┌────────────────────────────────────────┐
│ CENTRAL LEDGER │
│ │
│ Alice (verified) : Balance $1,000 │
│ Bob (verified) : Balance $500 │
│ Carol (verified) : Balance $2,000 │
└────────────────────────────────────────┘
- System verifies Alice is Alice
- System checks Alice has $100
- System decrements Alice's balance
- System increments Bob's balance
- Balances linked to identities
- Transfer requires authentication
- Central record of who has what
- Online verification required
Advantages:
ACCOUNT MODEL ADVANTAGES
- Lose password → identity verification → recover
- Account persists across devices
- Central bank/intermediary can help
- Identity known
- Transactions traceable
- AML monitoring straightforward
- Regulatory requirements met
- Account statements
- Transaction history
- Programmable features
- Integration with services
- Notifications, limits, etc.
- Like bank accounts
- Users understand the model
- Existing infrastructure applies
Disadvantages:
ACCOUNT MODEL DISADVANTAGES
- All transactions linked to identity
- No anonymous transactions
- Surveillance capability inherent
- Privacy requires policy, not design
- No identity = no access
- KYC requirements barrier
- System gatekeeping possible
- Must verify identity with central system
- Network required for transactions
- Vulnerable to outages
- Accounts can be frozen
- Access can be revoked
- Programmable restrictions possible
- More government control
Most CBDC designs combine elements:
TIERED ACCESS MODEL
TIER 1: TOKEN-LIKE (LOW VALUE)
┌─────────────────────────────────────┐
│ Limits: $500 per transaction │
│ KYC: None or minimal │
│ Privacy: High (no identity link) │
│ Features: Basic payments only │
│ Recovery: Limited (bearer nature) │
└─────────────────────────────────────┘
TIER 2: BASIC ACCOUNT (MEDIUM VALUE)
┌─────────────────────────────────────┐
│ Limits: $5,000 per transaction │
│ KYC: Basic (phone number, simple ID)│
│ Privacy: Moderate │
│ Features: Standard account features │
│ Recovery: Available │
└─────────────────────────────────────┘
TIER 3: FULL ACCOUNT (HIGH VALUE)
┌─────────────────────────────────────┐
│ Limits: None │
│ KYC: Full verification │
│ Privacy: Low (full compliance) │
│ Features: All features │
│ Recovery: Full support │
└─────────────────────────────────────┘
- Low-value = high privacy (like cash)
- High-value = full compliance (like banks)
- User chooses tier based on needs
- Regulators get compliance where it matters
MOST CBDCs ARE ACCOUNT-BASED
- Regulatory requirements (AML/KYC)
- Easier implementation
- Familiar to central banks
- Recoverable (reduces liability)
- Feature-rich capability
- Offline capability for small amounts
- Simplified access for low tiers
- Cash-like properties where possible
THE HONEST ASSESSMENT:
Pure token CBDC faces regulatory barriers.
Most CBDCs will be account-based with
token-like tiers for small transactions.
Cash-like privacy at scale is politically
difficult to achieve.
```
✅ The Design Pyramid provides a systematic framework—organizing decisions hierarchically helps ensure consistency from policy through implementation.
✅ Retail and wholesale are fundamentally different—they solve different problems, face different challenges, and often need different solutions.
✅ Two-tier intermediated model dominates for pragmatic reasons—banks are politically powerful, central banks lack retail capability, and evolutionary change is easier than revolutionary.
✅ Account-based models are more common than token-based—regulatory requirements and implementation simplicity favor accounts.
⚠️ Whether two-tier is optimal or merely expedient—it may preserve inefficiencies for political reasons.
⚠️ Whether tiered models can truly deliver privacy—regulators may erode low-tier privacy over time.
⚠️ How wholesale and retail CBDCs will eventually integrate—separate development may create compatibility challenges.
📌 Assuming design choices are purely technical—every choice in the pyramid has political and economic implications.
📌 Ignoring the path dependency—early choices constrain later options. Foundation decisions are very hard to change.
📌 Expecting innovation from conservative institutions—central banks and banking systems favor incremental change.
CBDC design involves fundamental choices that shape everything else. The Design Pyramid, retail/wholesale distinction, direct/intermediated distribution, and token/account models are the building blocks. Most CBDCs converge on similar patterns (retail, two-tier, account-based) not because these are optimal but because they're politically feasible and operationally conservative. Understanding why these patterns dominate—and what alternatives exist—is essential for evaluating any CBDC project.
Assignment: Apply the CBDC Design Pyramid to analyze a specific CBDC project, systematically documenting decisions at each layer.
Requirements:
Part 1: Select a CBDC
Choose one of: Digital Euro, China e-CNY, India e-Rupee, Nigeria eNaira, or Brazil DREX.
Part 2: Pyramid Analysis (3 pages)
For each layer of the pyramid, document:
Stated motivations
Legal framework/legislation
Success criteria (if defined)
Political constraints
Who operates the core system?
Who provides customer-facing services?
What governance structure exists?
Where does liability sit?
Retail, wholesale, or both?
Direct, intermediated, or hybrid?
Single-tier or multi-tier?
Key system components
Ledger type (centralized, DLT, hybrid)
Known technical specifications
Infrastructure approach
Token-based, account-based, or hybrid?
KYC requirements
Holding/transaction limits
Available interfaces
Part 3: Consistency Assessment (1 page)
Do higher layers align with lower layers?
Do design choices match stated motivations?
Are there apparent contradictions?
What trade-offs were made?
Completeness of pyramid analysis (40%)
Accuracy of design descriptions (25%)
Insight in consistency assessment (25%)
Clarity and organization (10%)
Time Investment: 3-4 hours
Value: Mastering the pyramid framework enables systematic analysis of any CBDC project.
1. Design Pyramid Question:
Why does the CBDC Design Pyramid place "Policy Foundation" at the base?
A) Because policy is the most important layer
B) Because policy decisions are made first chronologically
C) Because policy decisions constrain all layers above them
D) Because central banks are policy institutions
Correct Answer: C
Explanation: The pyramid structure indicates that lower layers constrain higher layers. Policy decisions (like "privacy must be preserved" or "banking system must not be disrupted") determine what architecture is possible, which determines what technology is appropriate, which determines what access models work. If policy requires cash-like privacy, you can't choose account-based access that eliminates privacy. The foundational nature is about constraint, not just sequence (B) or importance (A) or institutional identity (D).
2. Retail vs. Wholesale Question:
A central bank announces it will launch a CBDC for interbank settlement only, allowing banks to hold digital central bank money for settling large-value transactions. This is an example of:
A) Retail CBDC with direct distribution
B) Retail CBDC with intermediated distribution
C) Wholesale CBDC
D) Hybrid CBDC with tiered access
Correct Answer: C
Explanation: Wholesale CBDCs are for financial institutions only (banks, in this case), used for interbank settlement (large-value transactions between banks), not for public access. This description exactly matches wholesale CBDC characteristics. Retail CBDCs (A, B) are for general public use. A hybrid CBDC (D) would involve both wholesale and retail components or tiered public access.
3. Distribution Model Question:
Why has the two-tier intermediated model become the default for retail CBDCs?
A) It is technically superior to direct models
B) It preserves the banking system's role and leverages existing infrastructure
C) Central banks are legally prohibited from serving the public directly
D) The public prefers dealing with banks rather than central banks
Correct Answer: B
Explanation: The two-tier model dominates for pragmatic reasons: it avoids disrupting the politically powerful banking sector, and it leverages banks' existing customer infrastructure, KYC systems, and service capabilities. Central banks also lack retail banking expertise. Technical superiority (A) isn't established—direct models could be more efficient. Legal prohibition (C) isn't universal. Public preference (D) isn't the driving factor in design choices.
4. Token vs. Account Question:
Which CBDC access model would BEST support a policy requirement for "cash-equivalent privacy for small transactions and offline capability"?
A) Account-based with full KYC
B) Token-based or token-like tier for small amounts
C) Account-based with tiered transaction limits
D) Wholesale-only CBDC
Correct Answer: B
Explanation: Cash-equivalent privacy means transactions shouldn't be linked to identity—this is the defining characteristic of token-based models (bearer instruments, verify the token not the person). Offline capability is also more naturally supported by token models (self-contained value). Account-based models (A, C) inherently link transactions to identity, making cash-equivalent privacy impossible. Wholesale CBDC (D) is for institutions, not the public making small transactions.
5. Design Consistency Question:
A CBDC project states its primary motivation is "financial inclusion for unbanked populations." The design requires full identity verification, smartphone-only access, and continuous internet connectivity. What does this indicate?
A) The design is well-aligned with the stated motivation
B) Technical constraints make inclusive design impossible
C) There is likely a gap between stated motivation and actual priorities
D) Financial inclusion always requires strict identity verification
Correct Answer: C
Explanation: Unbanked populations typically lack identity documents (making full verification exclusionary), smartphones (making smartphone-only access exclusionary), and reliable internet (making continuous connectivity exclusionary). A design with these requirements explicitly excludes the target population. This suggests the stated motivation (inclusion) doesn't match actual priorities (perhaps transaction monitoring or modernization for already-banked). B is incorrect—inclusive designs are possible. D is incorrect—tiered KYC can enable inclusion. A is clearly wrong given the analysis.
- Bank for International Settlements: "CBDC: Foundational Principles and Core Features"
- IMF: "Behind the Scenes of Central Bank Digital Currency"
- World Economic Forum: "CBDC Policy-Maker Toolkit"
- BIS Innovation Hub: Multi-CBDC project reports (Jura, Dunbar, mBridge)
- European Central Bank: Digital Euro project documentation
- Bank of England: "Digital Money" discussion papers
- Federal Reserve: "Money and Payments: The U.S. Dollar in the Age of Digital Transformation"
- Bank of Japan: CBDC experiment reports
- MIT Digital Currency Initiative: Project Hamilton reports
For Next Lesson:
In Lesson 4, we survey the global CBDC landscape—who's building what, where are they in the process, and what patterns emerge across different countries and regions.
End of Lesson 3
Total words: ~5,700
Estimated completion time: 55 minutes reading + 3-4 hours for deliverable
Course 58: CBDC Architecture & Design
Lesson 3 of 20
XRP Academy - The Khan Academy of Digital Finance
Key Takeaways
The CBDC Design Pyramid organizes decisions hierarchically
: Policy foundations constrain operators, which constrain architecture, which constrains technology, which constrains access. You can't change foundations after building upper layers.
Retail and wholesale CBDCs solve different problems
: Retail is for public access to digital central bank money. Wholesale is for institutional settlement efficiency. Most countries explore both but separately.
Two-tier intermediated distribution dominates
: Central banks serve intermediaries; intermediaries serve public. This is pragmatic (leverages existing infrastructure, preserves banking system) rather than optimal.
Token-based enables privacy; account-based enables compliance
: Token models support cash-like anonymity and offline use. Account models support recovery, compliance, and rich features. Most CBDCs are account-based with possible token-like tiers for small amounts.
Design choices are political, not just technical
: Every architectural decision reflects values about privacy, control, inclusion, and the role of banks. Understanding why choices were made reveals priorities. ---