Programmability and Smart Money

PROGRAMMABILITY DEFINED

SIMPLE DEFINITION:
Money with embedded rules that automatically
execute under specified conditions

EXAMPLES:

• You have €100

• Spend it however, whenever, wherever you want

• Money has no rules

• You have €100 with conditions

• Can only be spent on groceries

• Expires in 30 days

• Must be spent at approved merchants

• Money enforces rules

THE SPECTRUM:
┌─────────────────────────────────────────────────┐
│ No programmability ◄────────────► Full control │
│ │
│ Cash-like: Controlled: │
│ - No restrictions - Spending limits │
│ - User freedom - Category restrictions │
│ - No conditions - Expiration dates │
│ - Geographic limits │
└─────────────────────────────────────────────────┘
```

PROGRAMMABILITY CATEGORIES

TYPE 1: PROGRAMMABLE PAYMENTS
Rules on HOW payments work
(Not restricting WHAT you buy)

Less controversial:
Enhances convenience
User-controlled

TYPE 2: PROGRAMMABLE MONEY
Rules embedded IN the currency itself

More controversial:
Restricts user freedom
Often issuer-controlled

TYPE 3: PROGRAMMABLE PLATFORM
Rules for financial products built on CBDC

Business-focused:
Wholesale applications
Less consumer concern
```

WHO PROGRAMS THE MONEY?

USER-PROGRAMMED:
┌────────────────────────────────────────────────┐
│ User sets their own rules │
│ │
│ Examples: │
│ - "Auto-save 10% of every payment I receive" │
│ - "Block my own gambling transactions" │
│ - "Split incoming funds to multiple accounts" │
│ │
│ User retains control │
│ User can change rules │
│ Enhances user capability │
│ │
│ Generally acceptable │
└────────────────────────────────────────────────┘

ISSUER-PROGRAMMED:
┌────────────────────────────────────────────────┐
│ Central bank or government sets rules │
│ │
│ Examples: │
│ - "This stimulus payment expires in 90 days" │
│ - "This benefit can only buy approved items" │
│ - "Cannot spend more than €X per day" │
│ │
│ User has no control │
│ User cannot change rules │
│ Restricts user freedom │
│ │
│ Highly controversial │
└────────────────────────────────────────────────┘

THE KEY QUESTION:
Who holds the power to program?
This determines whether programmability
enhances freedom or restricts it
```

---

PROGRAMMABLE PAYMENT BENEFITS

ESCROW AND CONDITIONAL PAYMENTS:
┌────────────────────────────────────────────────┐
│ Scenario: Buying goods online │
│ │
│ Without programmability: │
│ - Pay seller upfront │
│ - Hope they deliver │
│ - Dispute if problems │
│ │
│ With programmability: │
│ - Payment held in smart escrow │
│ - Released when delivery confirmed │
│ - Automatically refunded if not delivered │
│ │
│ Benefit: Reduced fraud, increased trust │
└────────────────────────────────────────────────┘

SPLIT PAYMENTS:
┌────────────────────────────────────────────────┐
│ Scenario: Paying rent │
│ │
│ Programmable rule: │
│ - On 1st of month │
│ - Automatically send €1,000 to landlord │
│ - From designated account │
│ │
│ Benefit: Automation, no missed payments │
└────────────────────────────────────────────────┘

STREAMING PAYMENTS:
┌────────────────────────────────────────────────┐
│ Scenario: Subscription service │
│ │
│ Programmable rule: │
│ - Pay €0.01 per minute of use │
│ - Stop automatically when balance low │
│ - Resume when topped up │
│ │
│ Benefit: Pay for actual usage │
└────────────────────────────────────────────────┘
```

BUSINESS USE CASES

DELIVERY VS. PAYMENT (DvP):
┌────────────────────────────────────────────────┐
│ Securities settlement │
│ │
│ Traditional: │
│ - Securities move │
│ - Then cash moves │
│ - Settlement risk in gap │
│ │
│ Programmable: │
│ - Atomic swap │
│ - Securities and cash move simultaneously │
│ - Or neither moves │
│ │
│ Benefit: Eliminates settlement risk │
└────────────────────────────────────────────────┘

SUPPLY CHAIN FINANCE:
┌────────────────────────────────────────────────┐
│ Payment triggers on delivery │
│ │
│ - IoT confirms goods received │
│ - Payment automatically released │
│ - No manual processing │
│ │
│ Benefit: Efficiency, reduced disputes │
└────────────────────────────────────────────────┘

COMPLIANCE AUTOMATION:
┌────────────────────────────────────────────────┐
│ Rules enforced automatically │
│ │
│ - Transaction limits │
│ - Reporting thresholds │
│ - Sanctions screening │
│ │
│ Benefit: Reduced compliance costs │
└────────────────────────────────────────────────┘
```

GOVERNMENT USE CASES

TARGETED BENEFITS:
┌────────────────────────────────────────────────┐
│ Scenario: Food assistance program │
│ │
│ Traditional: │
│ - Paper vouchers or cards │
│ - Manual merchant verification │
│ - Fraud and waste │
│ │
│ Programmable (carefully designed): │
│ - Digital benefit │
│ - Valid at approved retailers │
│ - Valid for food categories │
│ - Automatic reporting │
│ │
│ Potential benefit: Reduced fraud │
│ Risk: Paternalistic control │
└────────────────────────────────────────────────┘

TAX AUTOMATION:
┌────────────────────────────────────────────────┐
│ Scenario: VAT/Sales tax │
│ │
│ Programmable: │
│ - Tax automatically calculated │
│ - Tax portion routed to government │
│ - Real-time, no filing needed │
│ │
│ Benefit: Efficiency, reduced evasion │
│ Risk: Total transaction visibility │
└────────────────────────────────────────────────┘

IMPORTANT CAVEAT:
These "benefits" come with control
Each use case has a dark mirror
See Section 3 for concerns
```

---

EXPIRING CURRENCY CONCERNS

THE CONCEPT:
Money that loses value or expires
if not spent by a deadline

STATED JUSTIFICATION:
"Encourage spending during recession"
"Prevent hoarding of stimulus"

THE PROBLEM:
┌────────────────────────────────────────────────┐
│ Undermines store of value function │
│ │
│ Money's core functions: │
│ 1. Medium of exchange ✓ │
│ 2. Store of value ✗ BROKEN │
│ 3. Unit of account ? │
│ │
│ If money expires, it's not really money │
│ It's a voucher with an expiration date │
└────────────────────────────────────────────────┘

PUBLIC REACTION:
Strong opposition when discussed
Central banks generally deny planning this
But technical capability is the concern
```

SPENDING RESTRICTION CONCERNS

THE CONCEPT:
Money that can only be spent on
approved categories or merchants

THE SLIPPERY SLOPE:
┌────────────────────────────────────────────────┐
│ Step 1: "Block obvious fraud" │
│ OK, reasonable │
│ │
│ Step 2: "Block illegal purchases" │
│ Understandable but who defines? │
│ │
│ Step 3: "Block unhealthy purchases" │
│ Paternalistic │
│ │
│ Step 4: "Block purchases from opponents" │
│ Authoritarian │
│ │
│ Where exactly is the line? │
└────────────────────────────────────────────────┘

SOCIAL CREDIT AND CBDC

THE FEAR:
CBDC as tool for social scoring system

SCENARIO:
┌────────────────────────────────────────────────┐
│ Social score affects CBDC access │
│ │
│ Low score: │
│ - Transaction limits reduced │
│ - Categories restricted │
│ - Travel purchases blocked │
│ │
│ High score: │
│ - Full access │
│ - Maybe lower fees │
│ - Priority service │
└────────────────────────────────────────────────┘

PROGRAMMABILITY AND PRIVACY

THE CONNECTION:
To enforce rules, system must know transactions

EXAMPLE:
"Only spend on groceries"

THE TRADE-OFF:
┌────────────────────────────────────────────────┐
│ │
│ More programmability → Less privacy │
│ Less programmability → More privacy │
│ │
│ Cash: Zero programmability, maximum privacy │
│ Full CBDC control: Total visibility │
│ │
└────────────────────────────────────────────────┘
```

---

SMART CONTRACT APPROACHES

WHAT IS A SMART CONTRACT?
Code that executes automatically
when conditions are met

FOR CBDC:
┌────────────────────────────────────────────────┐
│ │
│ IF condition THEN action │
│ │
│ Examples: │
│ - IF delivery confirmed THEN release payment │
│ - IF date = 1st THEN send rent │
│ - IF balance > X THEN invest surplus │
│ │
└────────────────────────────────────────────────┘

IMPLEMENTATION OPTIONS:

• Smart contracts run on CBDC ledger

• Native programmability

• Requires DLT-based CBDC

• Example: Brazil DREX

• Smart contracts separate from CBDC

• CBDC is just settlement

• Less integrated

• Works with centralized CBDC

• Core CBDC is simple

• Programmability at interface layer

• Modular approach

PROGRAMMABILITY ARCHITECTURE

QUESTION: Where does logic live?

OPTION 1: IN THE CURRENCY
┌────────────────────────────────────────────────┐
│ Token itself contains rules │
│ │
│ Token: │
│ - Value: €100 │
│ - Expiry: 2025-03-01 │
│ - Category: Food only │
│ - Merchant: Approved list │
│ │
│ Most concerning: Rules travel with money │
└────────────────────────────────────────────────┘

OPTION 2: IN THE SYSTEM
┌────────────────────────────────────────────────┐
│ System applies rules at transaction time │
│ │
│ Token: │
│ - Value: €100 │
│ - ID: ABC123 │
│ │
│ System: │
│ - Checks rules database │
│ - Applies relevant rules │
│ - Allows or blocks │
│ │
│ More flexible, can change rules │
└────────────────────────────────────────────────┘

OPTION 3: AT THE WALLET
┌────────────────────────────────────────────────┐
│ Wallet enforces user-defined rules │
│ │
│ CBDC: Simple, no embedded rules │
│ Wallet: User's rules applied │
│ │
│ User-controlled programmability │
│ Less concerning │
└────────────────────────────────────────────────┘
```

---

PROGRAMMABILITY GOVERNANCE

KEY QUESTIONS:

• Central bank only?

• Government?

• Intermediaries?

• Users?

• Can rules be updated after issuance?

• What approval is needed?

• What notice is required?

• If rules cause harm, who's responsible?

• What recourse do users have?

• How are disputes resolved?

GOVERNANCE MODELS:

• CB defines all rules

• Government requests features

• Users have no input

• Concerning for democracy

• Parliament defines limits

• CB implements within limits

• Judicial oversight

• Better accountability

• Users choose programmable features

• No mandatory restrictions

• User-controlled

• Most freedom-preserving

LIMITING PROGRAMMABILITY

DIGITAL EURO APPROACH:
┌────────────────────────────────────────────────┐
│ Explicit limits proposed: │
│ │
│ NO: │
│ - Expiration dates │
│ - Spending category restrictions │
│ - Social scoring integration │
│ - Programmable restrictions by issuer │
│ │
│ YES (potentially): │
│ - User-initiated automation │
│ - Business smart contracts │
│ - Compliance automation │
└────────────────────────────────────────────────┘

PRINCIPLES FOR LIMITS:

1. Preserve money's core functions

2. User control over own money

3. No discrimination

4. Transparency

5. Democratic accountability

WHY LIMITS MATTER

THE SLIPPERY SLOPE CONCERN:
┌────────────────────────────────────────────────┐
│ "We won't use these features" │
│ ↓ │
│ "We'll only use them in emergencies" │
│ ↓ │
│ "We'll only use them for criminals" │
│ ↓ │
│ "We'll only use them for public health" │
│ ↓ │
│ "We'll use them for social good" │
│ ↓ │
│ Normalized control │
└────────────────────────────────────────────────┘

CAPABILITY VS. USE:
Current promise: "We won't use it"
Long-term risk: Capability exists, temptation grows

SOLUTION: DON'T BUILD THE CAPABILITY
If certain programmability is unacceptable,
don't build it in the first place

Technical limit > Policy promise

Better: "We can't" than "We won't"
```

---

✅ Programmability enables valuable use cases—escrow, DvP, automation are legitimate.

✅ Concerning applications are technically possible—expiration, restrictions, surveillance.

✅ Public is skeptical—programmability is a major adoption barrier.

⚠️ Where to draw the line—beneficial vs. concerning isn't always clear.

⚠️ Whether limits will hold—political pressure can erode promises.

⚠️ How other countries will use it—what's forbidden here may be used elsewhere.

📌 Building capabilities with promises not to use them—promises can be broken.

📌 Normalizing any issuer-controlled restrictions—slippery slope is real.

📌 Dismissing concerns as paranoia—concerns are legitimate.

Programmability is a double-edged sword. User-controlled automation is beneficial. Issuer-controlled restrictions are dangerous. The key is who holds the power to program. Central banks claiming "we won't" is less reassuring than "we can't." Technical limits are more trustworthy than policy promises.

---

Assignment: Develop a programmability policy framework for a hypothetical CBDC, specifying what's allowed, forbidden, and how governance works.

Time Investment: 3-4 hours

---

End of Lesson 14

END OF PHASE 2: ARCHITECTURE

Course 58: CBDC Architecture & Design
Lesson 14 of 20