Offline Payment Capability
Learning Objectives
Explain why offline capability matters for CBDCs
Describe the technical approaches to enabling offline payments
Identify the security challenges of offline transactions
Compare different offline payment architectures
Evaluate the trade-offs between offline capability and other features
Cash works in a power outage. Cash works in a remote village with no cell signal. Cash works when the internet goes down. This resilience is one of cash's most important properties—and one of the hardest to replicate digitally.
For CBDCs positioning as "digital cash," offline capability isn't optional—it's essential. But achieving it is technically difficult. Digital systems typically require online verification to prevent fraud. Making them work offline while preventing double-spending is a fundamental challenge.
WHY OFFLINE CAPABILITY MATTERS
INFRASTRUCTURE GAPS:
┌────────────────────────────────────────────────┐
│ Rural areas with poor connectivity │
│ Developing countries with unreliable power │
│ Underground locations (subways, basements) │
│ Events with network congestion │
│ Natural disasters disrupting infrastructure │
└────────────────────────────────────────────────┘
EMERGENCY SCENARIOS:
┌────────────────────────────────────────────────┐
│ Power grid failure │
│ Natural disasters (hurricanes, earthquakes) │
│ Network outages │
│ Cell tower overload │
│ Intentional network disruption │
└────────────────────────────────────────────────┘
DAILY CONVENIENCE:
┌────────────────────────────────────────────────┐
│ Airplane mode │
│ Roaming situations │
│ Underground parking │
│ Crowded venues │
│ Connection failures │
└────────────────────────────────────────────────┘
THE CASH COMPARISON:
Cash works in ALL of these scenarios
If CBDC claims to replace cash,
it should work in these scenarios too
```
OFFLINE USE CASES
- Emergency payments during disasters
- Rural commerce
- Public transit (underground)
- Small retail transactions
- Peer-to-peer transfers
- Temporary connectivity loss
- International travel
- Events and festivals
- Building interiors
- Extended offline periods
- Large value transactions
- Complex transactions
DIGITAL EURO REQUIREMENTS:
"A digital euro should be available
for offline use to mirror cash's
ability to function without
connectivity" - ECB
TARGET: Cash-equivalent resilience
REALITY: Significant technical challenges
```
THE FUNDAMENTAL CHALLENGE
ONLINE: Easy to prevent double-spend
┌────────────────────────────────────────┐
│ Transaction → Central system │
│ → Checks balance │
│ → Updates ledger │
│ → Confirms │
│ │
│ Same token can't be spent twice │
│ because system tracks in real-time │
└────────────────────────────────────────┘
OFFLINE: How to prevent double-spend?
┌────────────────────────────────────────┐
│ Transaction → No central check │
│ → How to verify? │
│ → How to prevent copy? │
│ │
│ Digital data can be copied perfectly │
│ What stops spending same value twice? │
└────────────────────────────────────────┘
THE CORE QUESTION:
Without real-time central verification,
how do you ensure the same digital value
isn't spent multiple times?
```
APPROACH 1: SECURE HARDWARE
CONCEPT:
Store value in tamper-resistant hardware
Hardware enforces single-spend
ARCHITECTURE:
┌────────────────────────────────────────────────┐
│ SECURE ELEMENT │
│ │
│ ┌────────────────────────────────────────┐ │
│ │ PROTECTED STORAGE │ │
│ │ │ │
│ │ Balance: €50 │ │
│ │ Transfer count: 3 remaining │ │
│ │ Last sync: 2025-01-15 10:00 │ │
│ │ │ │
│ │ Hardware prevents: │ │
│ │ - Balance modification │ │
│ │ - Data copying │ │
│ │ - Transaction replay │ │
│ └────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘
- Sender's secure element authenticates
- Receiver's secure element authenticates
- Value transferred SE-to-SE
- Sender's balance decremented in hardware
- Receiver's balance incremented in hardware
- Transaction logged in both devices
- Balance stored in tamper-proof hardware
- Hardware won't allow spending more than balance
- Can't copy balance out of secure element
- Physical security protects digital value
SECURE ELEMENT OPTIONS
SMARTPHONE SE:
┌────────────────────────────────────────┐
│ Built-in secure element │
│ (iPhone Secure Enclave, Android TEE) │
│ │
│ + Most users already have device │
│ + No additional hardware │
│ - Varying security levels │
│ - Not all phones have good SE │
│ - Battery dependent │
└────────────────────────────────────────┘
SMART CARD:
┌────────────────────────────────────────┐
│ Dedicated card with SE │
│ (Like chip credit card) │
│ │
│ + Dedicated security hardware │
│ + No battery needed (passive NFC) │
│ + Familiar form factor │
│ - Additional device to carry │
│ - No display (or limited) │
│ - Requires reader device │
└────────────────────────────────────────┘
DEDICATED HARDWARE WALLET:
┌────────────────────────────────────────┐
│ Purpose-built device │
│ │
│ + Highest security │
│ + Full display and controls │
│ + Independent of phone │
│ - Most expensive │
│ - Additional device │
│ - Battery management │
└────────────────────────────────────────┘
SIM-BASED:
┌────────────────────────────────────────┐
│ SE on SIM card │
│ │
│ + Existing infrastructure │
│ + Carrier relationship │
│ - Carrier dependency │
│ - Limited storage │
└────────────────────────────────────────┘
```
APPROACH 2: CRYPTOGRAPHIC PROTOCOLS
CONCEPT:
Use cryptography to create unforgeable,
limited-spend tokens
EXAMPLE: DIGITAL CASH SCHEMES
Blind Signatures (Chaum):
┌────────────────────────────────────────┐
│ 1. User creates token │
│ 2. Bank blindly signs │
│ 3. User unblinds → valid token │
│ 4. Merchant receives token │
│ 5. Merchant redeems with bank │
│ 6. Bank checks if token spent before │
└────────────────────────────────────────┘
Problem: Requires online redemption eventually
Offline only between parties
Zero-Knowledge Proofs:
┌────────────────────────────────────────┐
│ Prove token is valid without revealing│
│ which specific token it is │
│ │
│ + Strong privacy │
│ + Cryptographic security │
│ - Computationally intensive │
│ - Complex implementation │
│ - Still needs eventual settlement │
└────────────────────────────────────────┘
REALITY:
Pure cryptographic offline is research-stage
Most practical offline uses hardware
```
PRACTICAL OFFLINE ARCHITECTURE
NORMAL OPERATION (Online):
┌────────────────────────────────────────────────┐
│ │
│ User ←──────────────────────────→ System │
│ Transactions validated online │
│ Full balance available │
│ Real-time settlement │
│ │
└────────────────────────────────────────────────┘
OFFLINE PREPARATION (While Online):
┌────────────────────────────────────────────────┐
│ │
│ System → User Device │
│ │
│ "Load" offline balance: │
│ - Pre-authorize amount for offline │
│ - Store in secure element │
│ - Deduct from online balance │
│ │
│ Example: │
│ Online balance: €500 → €450 │
│ Offline balance: €0 → €50 │
│ │
└────────────────────────────────────────────────┘
OFFLINE USE:
┌────────────────────────────────────────────────┐
│ │
│ User ←───────────────────────→ Merchant │
│ Direct device-to-device │
│ No network needed │
│ Limited to pre-loaded amount │
│ │
└────────────────────────────────────────────────┘
RECONCILIATION (Back Online):
┌────────────────────────────────────────────────┐
│ │
│ User Device → System │
│ │
│ - Sync offline transactions │
│ - Reconcile balances │
│ - Report to central ledger │
│ - Refresh offline allocation │
│ │
└────────────────────────────────────────────────┘
```
OFFLINE TRANSACTION LIMITS
WHY LIMITS?
- Offline = delayed verification
- Fraud harder to detect
- Limiting exposure limits risk
- Until reconciliation, double-spend possible
- Smaller amounts = smaller risk
- Larger amounts require online
TYPICAL LIMIT STRUCTURE:
Maximum €50-100 per offline transaction
Above threshold requires online
Maximum €100-500 held offline
Must go online to reload
Maximum 3-5 offline transactions
Then must sync
Offline period limited
Must sync within 24-72 hours
Or wallet functionality reduced
Offline capability for small amounts
Limits to manage risk
Specific thresholds TBD
RECONCILIATION PROCESS
WHEN DEVICE COMES BACK ONLINE:
Device connects to system
Authenticates user
Offline transactions sent to system
Timestamp and sequence preserved
Cryptographic proof of validity
System verifies transactions
Checks for anomalies
Detects potential double-spend
Transactions recorded on central ledger
Merchant receives confirmed payment
Balances finalized
Offline balance topped up (if user chooses)
New offline allocation issued
Ready for future offline use
HANDLING CONFLICTS:
Flag the account
Investigate
May involve fraud team
Offline capability may be restricted
Hardware attestation fails
Account suspended
Investigation triggered
OFFLINE SECURITY RISKS
ATTACK 1: DOUBLE-SPEND
┌────────────────────────────────────────┐
│ Spend same offline balance twice │
│ before reconciliation │
│ │
│ Mitigation: │
│ - Secure hardware prevents │
│ - Limits reduce exposure │
│ - Reconciliation detects │
└────────────────────────────────────────┘
ATTACK 2: HARDWARE TAMPERING
┌────────────────────────────────────────┐
│ Extract keys or modify balance │
│ in secure element │
│ │
│ Mitigation: │
│ - Tamper-resistant hardware │
│ - Remote attestation │
│ - Hardware security certification │
└────────────────────────────────────────┘
ATTACK 3: FORGERY
┌────────────────────────────────────────┐
│ Create fake offline value │
│ │
│ Mitigation: │
│ - Cryptographic signatures │
│ - Hardware-bound credentials │
│ - Central bank signing │
└────────────────────────────────────────┘
ATTACK 4: REPLAY
┌────────────────────────────────────────┐
│ Replay old valid transactions │
│ │
│ Mitigation: │
│ - Unique transaction IDs │
│ - Sequence numbers │
│ - Time-based validity │
└────────────────────────────────────────┘
ATTACK 5: LOST DEVICE FRAUD
┌────────────────────────────────────────┐
│ Report device lost, use offline │
│ balance, claim refund │
│ │
│ Mitigation: │
│ - Device binding │
│ - No refund for offline balance? │
│ - Investigation for patterns │
└────────────────────────────────────────┘
```
OFFLINE RISK TRADE-OFFS
CENTRAL BANK PERSPECTIVE:
Risk: Some fraud/double-spend possible
Mitigation: Low limits, hardware security
Acceptance: Small losses for resilience benefit
- Some counterfeiting exists
- Cost of business
- Benefits outweigh losses
RISK MANAGEMENT APPROACH:
Small individual losses
Rare occurrences
Detection and response
Systemic fraud
Large value losses
Undetectable attacks
Transaction limits: €50-100
Balance limits: €100-500
Frequency limits: 3-5 transactions
Time limits: 24-72 hours
Within these limits, some loss is accepted
as cost of providing offline resilience
---
OFFLINE IN REAL CBDCs
- Offline capability developed
- SIM-based and hardware wallet options
- NFC device-to-device tested
- "Touch and touch" payments
- Most advanced implementation
Status: Piloting, expanding
- Offline is explicit requirement
- Cash-like properties for small transactions
- Technical approach still being designed
- Privacy emphasis for offline tier
Status: Design phase
- Some offline discussion
- Limited implementation
- Infrastructure challenges
Status: Limited
OTHERS:
Most CBDCs don't have robust offline yet
It's technically challenging
Often deprioritized for initial launch
```
OFFLINE TECHNOLOGY READINESS
MATURE:
✓ NFC communication
✓ Secure elements (in devices)
✓ Basic cryptographic protocols
DEVELOPING:
◐ Cross-device SE communication
◐ Standardized offline protocols
◐ Consumer-ready hardware wallets
EMERGING:
○ Full offline CBDC implementations
○ Scalable cryptographic approaches
○ Long-duration offline capability
- Basic offline: Available now
- Robust offline: 2-3 years
- Advanced offline: 5+ years
Digital Euro offline capability
will be significant milestone
if successfully implemented
```
✅ Hardware-based security can enable offline—secure elements provide tamper resistance.
✅ Limits are necessary—offline inherently has more risk than online.
✅ Cash-equivalent resilience is achievable—for small transactions with proper design.
⚠️ Security at scale—limited real-world testing of offline CBDC.
⚠️ User experience quality—how smooth will offline be in practice?
⚠️ Hardware availability—will secure elements be good enough in all devices?
📌 Promising offline without delivering—overpromising damages trust.
📌 Underestimating implementation complexity—offline is technically hard.
📌 Ignoring the trade-offs—offline means accepting some risk.
Offline capability is technically achievable but challenging. It requires secure hardware, acceptance of some risk, and careful limit management. China's e-CNY is furthest along; the Digital Euro is designing for it. Most CBDCs don't have robust offline yet. Achieving true cash-equivalent resilience will take years and significant investment.
Assignment: Assess offline payment requirements and design for a specific country context, considering infrastructure, use cases, and acceptable risk levels.
Time Investment: 3-4 hours
End of Lesson 13
Course 58: CBDC Architecture & Design
Lesson 13 of 20
Key Takeaways
Offline matters for cash equivalence
: If CBDC claims to replace cash, it should work without connectivity.
The challenge is preventing double-spend
: Without online verification, secure hardware or complex cryptography must prevent the same value being spent twice.
Hardware security is the practical approach
: Tamper-resistant secure elements that enforce single-spend are the main solution.
Limits manage risk
: Small transaction limits, balance caps, and time constraints reduce exposure from offline fraud.
Implementation is still maturing
: China leads; Digital Euro is designing; most others don't have robust offline yet. ---