Privacy and Programmable Money

Level	Visibility	Example
0	None	Physical cash
1	Aggregate only	Anonymous CBDC (theoretical)
2	Pseudonymous	Most cryptocurrencies
3	Tiered by amount	EU Digital Euro proposal
4	Full to issuer	China e-CNY
5	Full and shared	Authoritarian implementation

Capability ≠ Use:
Having the ability to surveil doesn't mean active surveillance occurs. But:

Mission creep is historical pattern:

Step 1: Surveillance for terrorism
Step 2: Surveillance for organized crime
Step 3: Surveillance for tax evasion
Step 4: Surveillance for regulatory compliance
Step 5: General surveillance capability

---

Concept:
Prove a statement is true without revealing the underlying data.

Example:

Statement: "My balance is greater than transaction amount"
Proof: Mathematical proof that statement is true
Revealed: Nothing about actual balance

Statement: "I am over 18"
Proof: Mathematical proof from verified credential
Revealed: Nothing about actual age
```

Application to programmable money:

Rule: "Only allow transactions under $1000"
Traditional: System sees amount, checks < $1000
ZK: User proves amount < $1000 without revealing amount

Result: Rule enforced, privacy preserved
```

Concept:
Perform computation on encrypted data, producing encrypted results.

How it works:

Encrypt(A) + Encrypt(B) = Encrypt(A + B)

Balance check: Encrypt(balance) - Encrypt(amount) = Encrypt(result)
If Encrypt(result) > Encrypt(0): Allowed
System never sees balance or amount in plaintext
```

Concept:
Hardware-based secure enclaves process data privately.

How it works:

Data enters TEE (Intel SGX, ARM TrustZone)
Processing occurs in isolated enclave
Even system operators can't see inside
Results emerge without intermediate visibility

Application:

Transaction enters TEE
Rules checked inside enclave
Approval/denial emerges
No transaction details visible to operator

Concept:
Different parties see different data based on role and need.

Example implementation:

User-to-user: Only parties see details
Merchant: Sees amount, basic verification
Bank: Sees user identity, transaction patterns
Central bank: Sees aggregate statistics
Tax authority: Sees flagged transactions over threshold

Approach	Privacy Level	Programmability	Practicality	Trust Required
ZK Proofs	High	Limited	Improving	Minimal
Homomorphic	High	Limited	Low	Minimal
TEEs	Medium	High	Medium	Hardware
Selective Disclosure	Medium	High	High	Intermediaries
Full Visibility	None	Full	High	Central authority

---

Tension:
European citizens value privacy, but AML rules require visibility. Resolution: Tiered privacy with thresholds.

---

Full Privacy          Full Programmability
     |                        |
     |     [Impossible]       |
     |         Zone           |
     |                        |
     |________________________|
                 ↑
         Can achieve one or the other,
         but not both fully

Use Case	Privacy Need	Programmability Need	Appropriate Design
Daily retail	High	Low	Cash-like CBDC
Large purchases	Medium	Medium	Tiered with thresholds
Government benefits	Low	Medium	Full visibility acceptable
Enterprise treasury	Medium	High	Private systems
Cross-border	Medium	Medium	Selective disclosure
High-value settlement	Low	High	Full visibility acceptable

---

---

✅ Privacy and programmability are in tension (inherent)
✅ Full privacy with full programmability is impossible
✅ Different implementations make different tradeoffs
✅ Mission creep in surveillance is historical pattern

⚠️ Whether privacy-preserving tech will mature enough
⚠️ What tradeoffs publics will accept
⚠️ Whether legal protections will hold
⚠️ Long-term political evolution of surveillance norms

📌 "Controllable anonymity" is surveillance, not privacy
📌 Temporary measures become permanent
📌 Capability creates temptation
📌 Accepting surveillance for programmability convenience

Full privacy and full programmability cannot coexist. Every programmable money system makes a tradeoff. Understanding where that tradeoff sits, who decided it, and what accountability exists is essential for evaluating any implementation.

---

Evaluate the privacy implications of a specific programmable money implementation.

Time Investment: 3-4 hours

---

A) Technical limitations that will be solved
B) Programmability requires visibility to evaluate conditions; privacy hides the data needed
C) Regulators mandate surveillance
D) Privacy technology is too expensive

Correct Answer: B

---

A) True anonymity with user control
B) Anonymity from counterparties but full visibility to central bank
C) Complete privacy from everyone
D) Anonymous small transactions only

Correct Answer: B

---

A) They are mathematically impossible
B) They only work for predefined specific proofs, not arbitrary programmability
C) They require too much electricity
D) They are illegal in most countries

Correct Answer: B

---

End of Lesson 12

• Previous: Lesson 11 - Cross-Border Programmable Money
• Next: Lesson 13 - Control, Censorship, and Programmable Money