Account Model vs. Token Model

ACCOUNT-BASED ARCHITECTURE

CORE CONCEPT:
Value = Balance in a named account
Transfer = Update balances after identity verification

SYSTEM STRUCTURE:
┌────────────────────────────────────────────────┐
│ CENTRAL LEDGER │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Account ID │ Identity │ Balance │ │
│ ├─────────────┼───────────┼────────────────┤ │
│ │ A001 │ Alice │ €500 │ │
│ │ A002 │ Bob │ €300 │ │
│ │ A003 │ Carol │ €1,200 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ Single source of truth │
│ Every account linked to identity │
└────────────────────────────────────────────────┘

KEY PRINCIPLE:
"Who are you?" determines access
Identity verification is the security
```

ACCOUNT MODEL ARCHITECTURE COMPONENTS

IDENTITY LAYER:
┌─────────────────────────────────────────┐
│ IDENTITY MANAGEMENT │
│ │
│ - KYC information storage │
│ - Identity verification │
│ - Authentication credentials │
│ - Access permissions │
│ │
│ Links real identity to account │
└─────────────────────────────────────────┘
│
▼
ACCOUNT LAYER:
┌─────────────────────────────────────────┐
│ ACCOUNT MANAGEMENT │
│ │
│ - Balance tracking │
│ - Transaction history │
│ - Limits and permissions │
│ - Status (active, frozen, etc.) │
└─────────────────────────────────────────┘
│
▼
TRANSACTION LAYER:
┌─────────────────────────────────────────┐
│ TRANSACTION PROCESSING │
│ │
│ - Validate authorization │
│ - Check balances │
│ - Execute transfers │
│ - Record and confirm │
└─────────────────────────────────────────┘

ACCOUNT MODEL ADVANTAGES

RECOVERY:

• Lost device? Recover with identity verification
• Forgot password? Reset with identity
• Account persists independently of device
• Central authority can assist

"Lost your wallet app? No problem—prove who you are"

COMPLIANCE:

• Identity known for every transaction
• AML/CFT straightforward
• Sanctions screening possible
• Audit trail complete

"Every transaction linked to verified identity"

RICH FEATURES:

• Transaction history and statements
• Spending analytics
• Notifications and alerts
• Integration with other services
• Programmable limits

"Full banking-like experience"

FRAUD PROTECTION:

• Suspicious activity detection
• Transaction reversal possible
• Dispute resolution feasible
• Pattern-based security

"Bank can help if something goes wrong"

ERROR CORRECTION:

• Mistakes can be corrected
• Court orders can be enforced
• System errors can be fixed
• Operational flexibility

"We can fix errors in the ledger"
```

ACCOUNT MODEL DISADVANTAGES

"Every coffee purchase on your permanent record"

"Can't verify who you are? No CBDC for you"

"They can cut you off"

"No connection = No payment"

"Identity breach is catastrophic"
```

---

TOKEN-BASED ARCHITECTURE

CORE CONCEPT:
Value = Tokens you possess
Transfer = Move tokens (verify token, not holder)

CONCEPTUAL STRUCTURE:
┌──────────────────────────────────────────────────┐
│ TOKENS │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ €10 │ │ €10 │ │ €10 │ │
│ │ Token │ │ Token │ │ Token │ │
│ │ #A001 │ │ #A002 │ │ #A003 │ │
│ │ │ │ │ │ │ │
│ │ Cryptographic signature by central bank │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Whoever holds the token, owns the value │
│ Verify the token is valid, not who holds it │
└──────────────────────────────────────────────────┘

KEY PRINCIPLE:
"What do you have?" determines value
Token verification is the security
Possession = Ownership
```

TOKEN MODEL ARCHITECTURE COMPONENTS

TOKEN CREATION (Minting):
┌─────────────────────────────────────────┐
│ CENTRAL BANK │
│ │
│ - Creates tokens with digital signature│
│ - Each token has unique identifier │
│ - Tokens represent specific value │
│ - Issuance recorded │
└─────────────────────────────────────────┘
│
▼
TOKEN STORAGE (Wallets):
┌─────────────────────────────────────────┐
│ USER WALLET │
│ │
│ - Stores tokens locally │
│ - May use secure hardware │
│ - Private keys control tokens │
│ - Balance = Sum of held tokens │
└─────────────────────────────────────────┘
│
▼
TOKEN TRANSFER:
┌─────────────────────────────────────────┐
│ TRANSFER MECHANISM │
│ │
│ - Sender transfers token to recipient │
│ - Recipient verifies token validity │
│ - May involve central registry check │
│ - Or peer-to-peer with cryptography │
└─────────────────────────────────────────┘

DOUBLE-SPEND PREVENTION:
Critical challenge—same token can't be spent twice

TOKEN MODEL ADVANTAGES

PRIVACY:

• Transfer doesn't require identity
• Transaction unlinkable to person
• Cash-like anonymity possible
• Financial privacy preserved

"Pay without revealing who you are"

OFFLINE CAPABILITY:

• Token is self-contained value
• Can transfer without network
• Verify token locally (with hardware)
• Resilient to network failures

"Pay even when internet is down"

INCLUSION:

• No account needed
• No KYC for basic use
• Receive value without identity
• Anyone can accept tokens

"Just receive tokens—no paperwork"

NO CENTRAL CONTROL:

• Can't freeze individual tokens easily
• Transfer is peer-to-peer
• Censorship resistant
• Reduced central power

"They can't stop you from paying"

BEARER INSTRUMENT:

• Clear ownership (possession)
• Simple mental model
• Like cash, but digital
• Intuitive for users

"If you have it, it's yours"
```

TOKEN MODEL DISADVANTAGES

"Drop your phone in the ocean, money gone"

"Thief has your tokens? They're the new owner"

"Technical challenge: how to prevent copying"

"Regulators don't like untraceable money"

"Harder to build correctly"
```

---

ARCHITECTURAL DIFFERENCES

ACCOUNT TOKEN
────────────────────────────────────────────────
DATA STRUCTURE
What's stored Balances Token objects
Where stored Central ledger User wallets
Ownership proof Identity Possession

TRANSACTION
Validation ID + Balance Token validity
Processing Central update Token transfer
Record Ledger entry Token movement

SECURITY
Model Authenticate Verify object
Recovery ID-based None/limited
Fraud Detectable Possession wins

PRIVACY
Identity link Always Optional/None
Traceability Full Limited/None

OFFLINE
Capability No Yes (with HW)
Verification Central needed Local possible
```

SOLVING THE DOUBLE-SPEND PROBLEM

THE PROBLEM:
Digital data can be copied perfectly
What stops spending same token twice?

SOLUTION 1: CENTRAL REGISTRY
┌────────────────────────────────────────┐
│ Every token transfer checks central DB │
│ │
│ Token #123: Status = UNSPENT │
│ │
│ Transfer request: │
│ 1. Check: Is #123 unspent? Yes │
│ 2. Mark: #123 → SPENT │
│ 3. Issue: New token #456 to recipient │
└────────────────────────────────────────┘

Problem: Requires online connection
Result: Loses offline advantage
Reality: Most "token" CBDCs do this

SOLUTION 2: HARDWARE SECURITY
┌────────────────────────────────────────┐
│ Tokens stored in tamper-proof chip │
│ │
│ Secure Element: │
│ - Cannot copy token out │
│ - Can only transfer, not duplicate │
│ - Hardware enforces single-spend │
└────────────────────────────────────────┘

Problem: Needs special hardware
Challenge: Hardware can be attacked
Reality: Smart cards, secure enclaves

SOLUTION 3: CRYPTOGRAPHIC SCHEMES
┌────────────────────────────────────────┐
│ Cryptographic proofs of spending │
│ │
│ Zero-knowledge proofs: │
│ - Prove token unspent without reveal │
│ - Complex math ensures validity │
│ - Emerging technology │
└────────────────────────────────────────┘

Problem: Complex, computation-heavy
Challenge: Maturity, practical deployment
Reality: Research stage for CBDC
```

PRIVACY: ACCOUNT VS. TOKEN

ACCOUNT MODEL PRIVACY:
┌────────────────────────────────────────────────┐
│ │
│ Transaction: Alice → Bob €100 │
│ │
│ Central Authority Knows: │
│ - Alice sent │
│ - Bob received │
│ - Amount: €100 │
│ - Time: 2025-01-15 14:32:05 │
│ - Alice's balance before/after │
│ - Bob's balance before/after │
│ - Complete transaction history │
│ │
│ Privacy: By policy only │
│ "We promise not to look unless..." │
└────────────────────────────────────────────────┘

TOKEN MODEL PRIVACY:
┌────────────────────────────────────────────────┐
│ │
│ Transaction: Token moves from A to B │
│ │
│ With full token model: │
│ - Token transferred │
│ - Amount: €100 (token denomination) │
│ - Sender: Unknown (or pseudonym) │
│ - Receiver: Unknown (or pseudonym) │
│ │
│ Privacy: By design │
│ "System can't know who" │
└────────────────────────────────────────────────┘

PRACTICAL REALITY:
Pure token model faces regulatory barriers
Most "token" CBDCs have identity for larger amounts
Privacy becomes about implementation, not just model
```

---

THE CASE FOR HYBRID MODELS

THE DILEMMA:
Account: Compliance ✓, Recovery ✓, Privacy ✗, Offline ✗
Token: Privacy ✓, Offline ✓, Recovery ✗, Compliance ✗

NEITHER IS PERFECT

HYBRID SOLUTION:
Combine elements based on use case

TIERED APPROACH:
┌────────────────────────────────────────────────┐
│ LOW VALUE (Token-like) │
│ - Below €50 per transaction │
│ - No identity required │
│ - Offline capable │
│ - Limited recovery │
│ - Privacy preserved │
├────────────────────────────────────────────────┤
│ MEDIUM VALUE (Hybrid) │
│ - €50-1,000 per transaction │
│ - Basic identity (phone number) │
│ - Online required │
│ - Recovery possible │
│ - Limited privacy │
├────────────────────────────────────────────────┤
│ HIGH VALUE (Account-based) │
│ - Above €1,000 │
│ - Full KYC required │
│ - Full compliance │
│ - Full recovery │
│ - No privacy from authority │
└────────────────────────────────────────────────┘
```

HYBRID ARCHITECTURE PATTERNS

PATTERN 1: ACCOUNT WITH OFFLINE TOKEN LAYER
┌─────────────────────────────────────────────────┐
│ ONLINE (Account) │
│ │
│ Main account balance, identity-linked │
│ Full features, recovery, compliance │
└──────────────────────┬──────────────────────────┘
│ Load tokens for offline
▼
┌─────────────────────────────────────────────────┐
│ OFFLINE (Token) │
│ │
│ Small balance in token form │
│ Offline capable, limited privacy │
│ Periodically syncs back to account │
└─────────────────────────────────────────────────┘

PATTERN 2: TOKEN WITH IDENTITY REGISTRY
┌─────────────────────────────────────────────────┐
│ TOKEN-BASED SYSTEM │
│ │
│ Tokens transfer peer-to-peer │
│ But: Large transactions require │
│ identity registration │
│ Registry links identity to transactions │
│ when threshold exceeded │
└─────────────────────────────────────────────────┘

PATTERN 3: DUAL WALLET
┌─────────────────┐ ┌─────────────────┐
│ ACCOUNT WALLET │ │ TOKEN WALLET │
│ │ │ │
│ - ID linked │ │ - Anonymous │
│ - Online │ │ - Offline OK │
│ - Full limits │ │ - Low limits │
│ - Full feature │ │ - Basic only │
└────────┬────────┘ └────────┬────────┘
│ │
└──────────┬──────────┘
│
User chooses which
to use for transaction
```

DIGITAL EURO: HYBRID IN PRACTICE

PROPOSED DESIGN:

• Account-based

• Identity linked

• Privacy: ECB doesn't see individual transactions

• Privacy: Intermediary sees their customers only

• Full compliance capability

• Token-like

• Stored on device

• Limited amounts

• Cash-like privacy

• Hardware security

PRIVACY TIERS:
Low-value offline: Maximum privacy (cash-like)
Low-value online: Intermediary knows, ECB doesn't
High-value: Full compliance requirements

HOLDING LIMITS:
~€3,000 overall
Offline portion limited within this

THE COMPROMISE:
Not pure token (regulatory requirements)
Not pure account (privacy concerns)
Hybrid attempting to balance

---

CHOOSING A MODEL: DECISION FRAMEWORK

START WITH PRIORITIES:

If PRIVACY is paramount:
→ Token-based or strong hybrid
→ Accept recovery limitations
→ Prepare for regulatory challenges

If COMPLIANCE is paramount:
→ Account-based
→ Accept privacy limitations
→ Simpler regulatory path

If OFFLINE is essential:
→ Token-based or hybrid with offline layer
→ Accept complexity of hardware security
→ Accept double-spend prevention challenges

If RECOVERY is essential:
→ Account-based
→ Accept identity requirements
→ Online dependency acceptable

If INCLUSION (no ID) is paramount:
→ Token-based for low tier
→ Accept limitations on recovery
→ Need tiered approach for compliance

MOST CBDCs:
Account-based with token-like features
Regulatory reality drives this
Hybrid via tiering is common
```

CBDC MODEL CHOICES IN PRACTICE

THE HONEST ASSESSMENT:
Pure token CBDC essentially doesn't exist
Regulatory barriers are decisive
"Token" usually means "account with features"
```

---

✅ Account-based is simpler to implement and comply—regulatory and operational advantages clear.

✅ Token-based offers theoretical privacy and offline—but faces practical challenges.

✅ Hybrid approaches are emerging as standard—account core with token features.

⚠️ Whether true offline tokens are feasible at scale—hardware security and double-spend remain challenging.

⚠️ How privacy tiers will work in practice—regulatory pressure may erode low-value privacy.

⚠️ Whether token-like features will satisfy privacy advocates—"some privacy" may not be enough.

📌 Assuming "token" means privacy—most token implementations have central registries.

📌 Underestimating double-spend challenges—pure offline is technically hard.

📌 Expecting pure token CBDCs—regulatory reality prevents this.

The account vs. token distinction is conceptually important but practically resolved: most CBDCs are account-based because regulations require it and implementation is mature. Token features (offline, privacy tiers) are added as enhancements, not alternatives. Understanding both models matters for evaluating CBDC designs, but expecting pure token models is unrealistic.

---

Assignment: Analyze account vs. token model trade-offs for a specific CBDC context.

Requirements:

Part 1: Choose a country and describe its specific context (regulatory environment, financial inclusion needs, privacy culture, technical infrastructure).

Part 2: Analyze how account-based and token-based models would perform in this context across: privacy, compliance, offline capability, recovery, inclusion, and implementation complexity.

Part 3: Recommend a model (or hybrid) with specific design features suited to this context.

Time Investment: 3-4 hours

---

1. Primary difference between account and token models?
Answer: Account verifies identity; token verifies the object itself

2. Why can't pure token CBDCs be anonymous above small amounts?
Answer: AML/CFT regulations require identity verification above thresholds

3. Main technical challenge for offline token CBDC?
Answer: Preventing double-spending without online verification

4. Why are most CBDCs account-based?
Answer: Regulatory compliance, recovery capability, implementation maturity

5. What does "hybrid" mean for CBDC models?
Answer: Account-based core with token-like features (offline, privacy tiers)

---

End of Lesson 10

Course 58: CBDC Architecture & Design
Lesson 10 of 20