Ledger Technology Options

Every monetary system depends on a ledger—a record of value and ownership. Physical cash uses a distributed ledger of sorts: whoever holds the bill holds the value, and the bill itself is the record. Bank accounts use centralized ledgers: the bank's database is the authoritative record of who owns what.

CBDCs need ledgers too. But what kind? The technology choice affects everything: speed, security, privacy, scalability, resilience, and cost. It's one of the most consequential decisions in CBDC design.

Despite the hype around blockchain, the answer isn't obvious. Many of the world's most efficient payment systems—including central bank settlement systems—run on traditional databases. Adding "blockchain" doesn't automatically make a system better. The question is what you're trying to optimize for.

---

WHAT A LEDGER DOES

CORE FUNCTION:
Record who owns what and track changes

ESSENTIAL PROPERTIES:

1. ACCURACY

2. INTEGRITY

3. AVAILABILITY

4. CONSISTENCY

LEDGER OPERATIONS:

CREATE: Add new account/entry
READ: Query balances/history
UPDATE: Record transactions
DELETE: Close accounts (rare)

• Create: Open wallet
• Read: Check balance
• Update: Process payment
• Delete: Rarely needed (archive instead)

EVOLUTION OF LEDGERS

Example: Bank clerks with ledger books

Example: Modern bank core systems

Example: Bitcoin, Ethereum, enterprise DLT

FOR CBDC:
Physical: Not an option (this is digital currency)
Centralized: Traditional proven approach
Distributed: Newer, different trade-offs
Hybrid: Combining elements
```

---

CENTRALIZED DATABASE ARCHITECTURE

STRUCTURE:
┌─────────────────────────────────────────┐
│ CENTRAL DATABASE │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Account: Alice Balance: $500 │ │
│ │ Account: Bob Balance: $300 │ │
│ │ Account: Carol Balance: $1,200 │ │
│ │ ... │ │
│ └─────────────────────────────────┘ │
│ │
│ Single authoritative source │
│ Managed by central operator │
│ Standard database technology │
└─────────────────────────────────────────┘
│
┌──────┴──────┐
│ │
┌──▼──┐ ┌──▼──┐
│Read │ │Read │ Backup/Read replicas
│Only │ │Only │ for performance
└─────┘ └─────┘

Authority: Central operator (central bank)
Trust: Users trust central operator
```

CENTRALIZED DATABASE ADVANTAGES

PERFORMANCE:

• Very fast: Thousands to millions TPS possible
• Low latency: Milliseconds for transactions
• Proven: Decades of optimization
• Scalable: Known techniques for growth

Example: Visa processes 65,000+ TPS peak
Central bank RTGS systems: Very high throughput

SIMPLICITY:

• Well-understood technology
• Abundant expertise available
• Mature tooling
• Easier to audit

Implication: Lower development risk

CONTROL:

• Central operator has full authority
• Changes implemented immediately
• Clear governance
• Unified upgrades

For central bank: Matches existing model

EFFICIENCY:

• No consensus overhead
• No replication delay
• Minimal redundant computation
• Lower infrastructure cost

AUDITABILITY:

• Single authoritative record
• Complete transaction history
• Clear audit trail
• Standard reporting

CENTRALIZED DATABASE DISADVANTAGES

Mitigation: High availability architecture
But: Fundamentally centralized risk

For CBDC: Trust in central bank (usually high)

Mitigation: Extensive security investment

For CBDC: May be acceptable (government operates)

CBDCs USING CENTRALIZED APPROACHES

---

DISTRIBUTED LEDGER TECHNOLOGY (DLT)

DEFINITION:
Ledger replicated across multiple nodes
with consensus mechanism for agreement

STRUCTURE:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ NODE A │ │ NODE B │ │ NODE C │
│ │ │ │ │ │
│ Full Ledger │ │ Full Ledger │ │ Full Ledger │
│ Copy │◄─►│ Copy │◄─►│ Copy │
│ │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
│
┌────────┴────────┐
│ CONSENSUS │
│ MECHANISM │
│ (Agreement on │
│ valid state) │
└─────────────────┘

TYPES OF DLT:

• Anyone can participate

• Bitcoin, Ethereum

• High decentralization

• Lower performance typically

• Known, approved participants

• Enterprise blockchain

• Lower decentralization

• Higher performance possible

• Most CBDC DLT is this type

BLOCKCHAIN EXPLAINED

STRUCTURE:
┌────────┐ ┌────────┐ ┌────────┐
│Block 1 │───▶│Block 2 │───▶│Block 3 │
│ │ │ │ │ │
│Hash: A │ │Hash: B │ │Hash: C │
│Prev: 0 │ │Prev: A │ │Prev: B │
│Txns:...│ │Txns:...│ │Txns:...│
└────────┘ └────────┘ └────────┘

IMPORTANT DISTINCTION:
Blockchain ⊂ DLT
(Blockchain is a subset of DLT)

Not all DLT is blockchain
Not all blockchain is relevant for CBDC
CBDC blockchain is typically permissioned
```

POTENTIAL DLT ADVANTAGES

RESILIENCE:

• No single point of failure
• System continues if some nodes fail
• Geographic distribution possible
• Inherent redundancy

Caveat: Depends on actual distribution

TRANSPARENCY/AUDITABILITY:

• Multiple parties have ledger copy
• Can verify independently
• Harder to manipulate secretly
• Shared visibility

Caveat: In permissioned systems, still limited set

PROGRAMMABILITY:

• Smart contract capability
• Automated logic on ledger
• Complex conditions possible
• New functionality

Caveat: Centralized databases can also be programmable

INTEROPERABILITY POTENTIAL:

• Standard DLT may connect to other DLTs
• Cross-chain bridges possible
• Ecosystem compatibility

Caveat: Standards still developing

STAKEHOLDER DISTRIBUTION:

• Multiple operators possible
• Banks could operate nodes
• Shared responsibility
• Distributed governance

Caveat: For CBDC, central bank still controls issuance
```

DLT CHALLENGES FOR CBDC

Reality: CBDC needs high performance
Many DLTs struggle with scale

Result: Higher development and operation costs

For CBDC: Needs to handle millions/billions of users

Note: CBDC would use permissioned (lower energy)

For CBDC: Central bank wants control anyway

CBDCs USING DLT

PATTERN:
Retail CBDCs: Often centralized or hybrid
Wholesale CBDCs: More often DLT
Scale requirements favor centralized for retail
Multi-party nature favors DLT for wholesale
```

---

CENTRALIZED VS. DISTRIBUTED: TRADE-OFFS

CENTRALIZED DISTRIBUTED
DATABASE LEDGER (DLT)
────────────────────────────────────────────────
PERFORMANCE
Throughput Very High Lower (varies)
Latency Very Low Higher (varies)
Scalability Proven Challenging

TRUST MODEL
Single operator Yes No (varies)
Verify vs Trust Trust Can verify
Transparency By policy By design

RESILIENCE
Single failure Possible Reduced risk
Geographic dist Extra work Natural

COMPLEXITY
Development Lower Higher
Operations Lower Higher
Expertise needed Common Specialized

FLEXIBILITY
Upgrades Easy Coordination
Error correction Possible Difficult
Governance Simple Complex

COST
Infrastructure Lower Higher
Development Lower Higher
Operations Lower Higher

CONTROL
Central bank Full Varies
Policy changes Immediate Consensus
```

SELECTION CRITERIA

CHOOSE CENTRALIZED WHEN:
✓ Performance is critical (high TPS, low latency)
✓ Central bank trust is established
✓ Single operator is acceptable
✓ Simplicity is valued
✓ Cost efficiency is important
✓ Retail scale is required
✓ Fast deployment is needed

CHOOSE DISTRIBUTED WHEN:
✓ Multiple parties must share control
✓ Cross-border/multi-country scenario
✓ Transparency is paramount
✓ Resilience against single failures critical
✓ Programmability/smart contracts central
✓ Interoperability with DLT ecosystem needed
✓ Wholesale (lower volume) application

CHOOSE HYBRID WHEN:
✓ Want benefits of both
✓ Different layers have different needs
✓ Core = centralized, interface = distributed
✓ Evolution path desired
```

---

HYBRID ARCHITECTURE CONCEPT

DEFINITION:
Combining centralized and distributed elements
to capture benefits of both

COMMON PATTERNS:

PATTERN A: CENTRALIZED CORE, DISTRIBUTED INTERFACE
┌─────────────────────────────────────────────┐
│ CENTRALIZED CORE LEDGER │
│ (High performance, control) │
└─────────────────────┬───────────────────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Bank A │ │ Bank B │ │ Bank C │
│ Node │ │ Node │ │ Node │
│(DLT/DB) │ │(DLT/DB) │ │(DLT/DB) │
└─────────┘ └─────────┘ └─────────┘

Core: Central bank operates high-performance ledger
Interface: Banks/PSPs may use DLT for their operations

• Wholesale layer: DLT (banks, settlement)

• Retail layer: Centralized (consumers, performance)

• Bridge between them

• DLT structure

• Central bank node has special authority

• Veto power or final authority

• Distributed form, centralized control

HYBRID APPROACHES IN PRACTICE

HYBRID ARCHITECTURE TRADE-OFFS

ADVANTAGES:

• Best of both worlds potential
• Flexibility in design
• Can optimize each layer
• Evolution path available
• Accommodates different stakeholders

THE HONEST ASSESSMENT:
Hybrid often reflects inability to choose
or genuine multi-layer requirements
Not automatically better than pure approaches
Complexity has real costs
```

---

LEDGER TECHNOLOGY DECISION FRAMEWORK

STEP 1: DEFINE REQUIREMENTS

STEP 2: ASSESS OPTIONS

STEP 3: EVALUATE TRADE-OFFS

STEP 4: CONSIDER EVOLUTION

WHY CENTRALIZED WINS (OFTEN)

PERFORMANCE ARGUMENT:
Retail CBDC needs high TPS
Centralized delivers proven performance
DLT performance is improving but still lower
"We need 10,000 TPS minimum"

SIMPLICITY ARGUMENT:
Central banks aren't technology companies
Centralized is well-understood
DLT adds complexity
"We want proven, not experimental"

TRUST ARGUMENT:
Central bank is already trusted
Adding DLT doesn't increase trust
Users trust the institution, not the technology
"If they don't trust us, DLT won't help"

CONTROL ARGUMENT:
Central bank wants to control its currency
DLT distributes control by design
CBDC issuance should be centralized
"Why would we give up control?"

COST ARGUMENT:
Centralized is cheaper to build and operate
Central banks are budget-conscious
DLT expertise is scarce and expensive
"We need to justify the cost"

THE COUNTERARGUMENT:
DLT proponents argue long-term benefits
Interoperability, programmability, future-proofing
But central banks focus on now
```

---

✅ Centralized databases can handle CBDC requirements—decades of payment system experience prove this.

✅ DLT has trade-offs, not just benefits—performance, complexity, and cost are real concerns.

✅ Hybrid approaches are emerging—combining elements pragmatically.

✅ Technology choice depends on requirements—no single answer is right for all CBDCs.

⚠️ Whether DLT performance will match centralized—improvements continue, but gap remains for high-volume retail.

⚠️ Long-term benefits of DLT—interoperability and programmability claims are forward-looking.

⚠️ Which hybrid patterns work best—limited operational experience.

📌 Choosing DLT because it's "modern"—blockchain hype doesn't equal suitability.

📌 Assuming centralized can't innovate—programmability and new features are possible in centralized systems too.

📌 Underestimating hybrid complexity—two systems means two sets of problems.

There's no universally correct ledger technology for CBDCs. Centralized databases are proven, fast, and simple but require trust in a single operator. Distributed ledgers offer resilience and transparency but with performance and complexity costs. Hybrid approaches try to balance both but add their own complexity. The choice depends on specific requirements, trust models, and what trade-offs are acceptable. Most retail CBDCs are trending centralized or hybrid for practical reasons.

---

Assignment: Evaluate ledger technology options for a hypothetical CBDC, making and justifying a recommendation.

Requirements:

Part 1: Define the Scenario (1 page)

• Country characteristics (population, existing payment infrastructure)
• CBDC goals (primary motivation from Lesson 2)
• Performance requirements (estimated TPS, latency)
• Trust context (central bank trust level)
• Stakeholder requirements (banks, consumers, government)

Part 2: Option Analysis (2 pages)

• How well does it meet performance requirements?
• How does it fit the trust model?
• What are the complexity and cost implications?
• What are the specific advantages in this scenario?
• What are the specific disadvantages?

Part 3: Recommendation (1 page)

• Which approach do you recommend and why?

• What are the key trade-offs you're accepting?

• What risks should be monitored?

• How might the choice evolve over time?

• Realism and completeness of scenario (20%)

• Thoroughness of option analysis (35%)

• Quality of reasoning in recommendation (35%)

• Clarity and organization (10%)

Time Investment: 3-4 hours
Value: Practicing technology assessment develops analytical skills applicable to real CBDC evaluation.

---

1. Ledger Function Question:

What is the primary function of a CBDC ledger?

A) To mine new digital currency
B) To record who owns what and track changes in ownership
C) To connect to other blockchain networks
D) To encrypt all user communications

Correct Answer: B
Explanation: A ledger's core function is recording ownership and tracking transactions—who has what and how it changes. Mining (A) is specific to proof-of-work blockchains and not relevant to CBDCs. Blockchain connectivity (C) might be a feature but isn't the primary function. Encryption (D) is a security measure, not the ledger's purpose.

---

2. Performance Trade-off Question:

Why do centralized databases typically offer better performance than distributed ledgers?

A) Centralized databases use more advanced hardware
B) There's no consensus overhead—one authority decides validity
C) Distributed ledgers are designed for low-performance applications
D) Centralized systems have more developers working on them

Correct Answer: B
Explanation: Centralized databases have one authority that validates and records transactions—no need to wait for multiple nodes to agree. Distributed ledgers require consensus among nodes, adding latency and limiting throughput. Hardware quality (A) isn't the differentiator. DLT isn't designed for low performance (C). Developer count (D) isn't the core issue.

---

3. DLT Advantage Question:

In which scenario would a distributed ledger be MOST advantageous for a CBDC?

A) A retail CBDC requiring 50,000 transactions per second
B) A cross-border wholesale CBDC involving multiple central banks with shared governance
C) A domestic CBDC where the central bank is highly trusted
D) A pilot project with 1,000 test users

Correct Answer: B
Explanation: DLT's key advantage is multi-party control and shared governance without a single trusted authority. A cross-border wholesale CBDC involving multiple central banks (none of which fully trusts the others to control the system) is ideal for DLT. High retail TPS (A) favors centralized. High trust (C) reduces DLT's value. Small pilot (D) could use either.

---

4. Technology Trend Question:

What pattern is emerging in retail CBDC ledger technology choices?

A) Universal adoption of public blockchain like Bitcoin
B) Centralized or hybrid approaches for performance and simplicity
C) Complete rejection of any digital ledger technology
D) Exclusive use of proof-of-work consensus

Correct Answer: B
Explanation: Retail CBDCs are trending toward centralized cores (for performance) or hybrid approaches (for flexibility). Public blockchains (A) are too slow and uncontrollable for central banks. No one is rejecting digital ledgers (C)—that would prevent having a digital currency. Proof-of-work (D) is energy-intensive and slow, unsuitable for CBDC.

---

5. Hybrid Architecture Question:

What is the primary trade-off when choosing a hybrid ledger architecture?

A) Hybrid systems are always slower than pure DLT
B) Hybrid systems cannot support programmability
C) Hybrid systems add complexity of maintaining two types of systems
D) Hybrid systems cannot meet regulatory requirements

Correct Answer: C
Explanation: Hybrid architectures try to capture benefits of both centralized and distributed approaches, but the trade-off is complexity—you're essentially running two different systems, with integration challenges, more potential failure points, and higher operational costs. Speed (A) depends on design. Programmability (B) is possible in both. Regulatory compliance (D) is about design, not architecture type.

---

For Next Lesson:
In Lesson 9, we examine consensus mechanisms in detail—how distributed systems agree on truth, and which approaches are suitable for CBDCs.

---

End of Lesson 8

Total words: ~5,800
Estimated completion time: 60 minutes reading + 3-4 hours for deliverable

---

Course 58: CBDC Architecture & Design
Lesson 8 of 20
XRP Academy - The Khan Academy of Digital Finance