The Programmability Spectrum - Finding the Right Level

Recall from Lesson 1 the programmability spectrum:

Level	Name	Characteristics	Example
0	No programmability	Bearer instrument, no conditions	Physical cash
1	Basic policy rules	Account limits, fraud detection	Bank accounts
2	Simple conditions	Expiration, category restrictions	Gift cards, SNAP
3	Reactive logic	External triggers, multi-party conditions	Smart escrow
4	Complex workflows	Multi-step, branching, loops	DeFi lending
5	Turing-complete	Arbitrary programs	Ethereum

Value Added
    ^
    |           .........
    |       ....
    |    ...
    |  ..
    | .
    |.
    +-------------------------> Programmability Level
    0    1    2    3    4    5

Risk Added
^
| ...
| ...
| ...
| ....
| ....
|.....
+-------------------------> Programmability Level
0 1 2 3 4 5
```

For most use cases, this optimum is Level 2-3, not Level 5.

---

To determine appropriate programmability level, ask:

• No conditions → Level 0

• Simple time/amount conditions → Level 2

• External data conditions → Level 3

• Complex financial logic → Level 4-5

• Mass retail → Lower level (complexity kills adoption)

• Sophisticated/institutional → Higher level acceptable

• Automated systems → Higher level possible

• High stakes (savings, national currency) → Lower level (security priority)

• Lower stakes (DeFi experimentation) → Higher level acceptable

• Reversible (enterprise with governance) → Higher level with safeguards

• Replacing cash → Level 1-2 sufficient

• Replacing complex TradFi → Level 3-4 may be needed

• Enabling entirely new use cases → May require higher levels

Retail CBDC for general payments:

Conditions needed: Basic (limits, maybe expiration for stimulus)
Users: Mass retail (low sophistication)
Stakes: National currency (very high)
Alternative: Cash, existing digital payments

Appropriate level: 1-2
Justification: Simple is safer for national scale
```

Government benefit programs:

Conditions needed: Category restrictions, expiration possible
Users: Benefit recipients (varied sophistication)
Stakes: Moderate (individual benefits)
Alternative: SNAP, direct deposit

Appropriate level: 2-3
Justification: Restrictions add value, complexity limited
```

Trade finance (letters of credit):

Conditions needed: Document verification, multi-party
Users: Businesses and banks (sophisticated)
Stakes: Significant commercial transactions
Alternative: Traditional LC process (slow, expensive)

Appropriate level: 3-4
Justification: Complexity justified by value, professional users
```

DeFi lending:

Conditions needed: Collateral management, liquidation, rates
Users: Crypto-native, risk-accepting
Stakes: User funds at risk (accepted)
Alternative: Centralized crypto lending, TradFi

Appropriate level: 4
Justification: Complexity required for functionality, users accept risk
```

Experimental financial instruments:

Conditions needed: Novel, complex, exploratory
Users: Sophisticated, risk-capital only
Stakes: Accepted loss potential
Alternative: None (innovation space)

Appropriate level: 5
Justification: Innovation requires flexibility, limited deployment
```

Use Case	Recommended Level	Key Reasoning
Retail CBDC	1-2	Mass market, high stakes, simplicity
Wholesale CBDC	2-3	Institutional users, specific use cases
Government benefits	2-3	Restrictions valuable, limited complexity
Consumer stablecoin	1-2	Payment utility, not complexity
Enterprise treasury	2-3	Professional users, defined workflows
Trade finance	3-4	Complex but standard processes
DeFi lending	4	Requires complexity, accepts risk
DeFi derivatives	4-5	High complexity inherent
Experimental	5	Innovation, limited scale

---

Examples:

Over-engineered CBDC:

Proposed: Full smart contract capability for retail CBDC
Reality: 99% of transactions are simple payments
Risk: Massive attack surface for minimal value
Better: Level 1-2 with clear upgrade path

Over-engineered stablecoin:

Proposed: Algorithmic stability without collateral
Reality: UST collapse showed algorithm isn't enough
Risk: $40B lost to over-confidence in code
Better: Simpler, collateralized design

Over-engineered enterprise:

Proposed: Full DeFi-style programmability for corporate treasury
Reality: Enterprises want defined, auditable workflows
Risk: Compliance challenges, audit failures
Better: Level 3 with clear boundaries

Technical enthusiasm:
Engineers want to build interesting things. Level 5 is more interesting than Level 2. The question "can we?" overshadows "should we?"

Competitive positioning:
Marketing wants differentiating features. "More programmable than competitors" sounds good even if users don't need it.

Future-proofing fallacy:
"We might need this later" leads to building for hypothetical futures instead of real presents.

Scope creep:
Each stakeholder adds requirements. Combined requirements exceed any single use case.

Insufficient user research:
Building for imagined users rather than real ones. Real users often want simpler.

Start minimal:
Launch with minimum viable programmability. Add complexity only when proven necessary.

Prove demand before building:
"We need X feature" should require evidence that users actually want it, not speculation.

Separate layers:
Build simple core with optional complexity layers. Users choose their level.

Sunset unused features:
If features aren't used, remove them. Reducing complexity is valuable.

Benchmark against adoption:
Features that don't drive adoption are costs, not benefits.

---

User experience research consistently shows:

The paradox of choice:
More options often reduce satisfaction. Users prefer clear, simple choices.

Cognitive load:
Complex systems require mental effort. Users abandon complex processes.

Error rates:
Complexity increases errors. Errors in money systems are costly and scary.

Trust:
Simple, predictable systems build trust. Complex, opaque systems erode it.

Suitable for: Mass retail
```

Suitable for: Business users, power consumers
```

Suitable for: Specialists, professional users
```

Users should understand what money will do before it does it.

Good UX at any level:

"This payment will complete on [date] if [condition].
If [condition] is not met, funds return to you."

Clear, specific, predictable.
```

Bad UX (complexity hidden):

"Payment submitted."
[User doesn't know what conditions apply]
[Unexpected behavior occurs]
[Trust eroded]

Design principle: If programmability can't be made visible and understandable to users, that level may be too high for that user base.

Higher programmability creates more ways for things to go wrong:

• Errors are familiar (insufficient funds, limit exceeded)

• Recovery is straightforward

• Support teams can help

• Errors may be novel and confusing

• Smart contract errors may be irreversible

• Support teams may not understand

Design implication: Higher programmability requires proportionally higher investment in error handling, user education, and support infrastructure.

---

Step 1: Define the use case precisely
        What problem are you solving? For whom?

Step 2: Identify minimum required conditions
What must money enforce? Be specific.

Step 3: Map conditions to programmability level
What's the lowest level that enables requirements?

Step 4: Assess user sophistication
Can users handle this level?

Step 5: Evaluate stakes and risk tolerance
What happens if something goes wrong?

Step 6: Compare to alternatives
What level do successful competitors use?

Step 7: Start lower, prove need before adding
Launch simple, add complexity with evidence
```

Was this right?

• Payments don't need Level 5

• Speed and cost matter more than programmability

• Simpler = more secure

• Complex DeFi can't be built on XRPL

• Some use cases go to Ethereum instead

• But XRPL wasn't designed for that

---

Recommendation: Start at Level 1-2, with clear upgrade path.

Recommendation: Match level to target market.

Recommendation: Level 3-4 for defined workflows.

---

✅ Higher programmability means higher risk: Security incidents correlate with complexity.

✅ Successful implementations often use minimal programmability: JPM Coin, most CBDCs, many stablecoins.

✅ User adoption inversely correlates with complexity: Simpler systems get more users.

✅ Level matching matters: Mismatched implementations struggle.

⚠️ Optimal level for specific use cases: Best practices still emerging.

⚠️ Whether upgrade paths work: Can Level 2 CBDCs add Level 3 later?

⚠️ Long-term evolution: Will expectations shift toward more or less programmability?

📌 Building Level 5 when Level 2 suffices: Unnecessary risk.

📌 Assuming users want programmability: They usually want outcomes, not features.

📌 Competitive programming-up: Racing to add features competitors add regardless of user need.

The right level of programmability is almost always lower than what's technically possible. Start simple, prove value, add complexity only when justified by evidence. Most money use cases need Level 1-3, not Level 5. Over-engineering is the greater risk than under-engineering—you can always add features, but removing complexity from a deployed system is painful.

---

Apply the programmability selection framework to evaluate three different programmable money designs.

Part 1: Framework Application (60%)

• One CBDC (real or proposed)
• One stablecoin or DeFi protocol
• One enterprise or B2B application

1. Define use case precisely
2. Identify minimum required conditions
3. Map to programmability level
4. Assess user sophistication
5. Evaluate stakes and risk tolerance
6. Compare to alternatives
7. Determine: Is the implemented/proposed level appropriate?

Document your analysis with specific justification for each step.

Part 2: Level Mismatch Analysis (25%)

• Assess whether actual/proposed level matches optimal level
• If mismatched, explain why (over-engineering, under-engineering, different use case than stated)
• Recommend adjustments with justification

Part 3: Design Recommendations (15%)

• Three design principles for programmability level selection
• One example of good level matching and why
• One example of poor level matching and why
• Recommendations for avoiding common mistakes

3-4 hours

This deliverable develops practical skill in applying programmability assessment frameworks—essential for evaluating any programmable money implementation, whether as investor, designer, or analyst.

---

A central bank is designing a retail CBDC for a population of 50 million. What programmability level is most appropriate for the initial launch?

A) Level 5, to ensure maximum future flexibility
B) Level 1-2, prioritizing simplicity, security, and adoption for mass market
C) Level 4, to compete with DeFi protocols
D) Level 0, because programmability is never appropriate for national currency

Correct Answer: B

Explanation: Mass retail CBDC needs simplicity for adoption, security for national currency stakes, and familiarity for diverse users. Level 5 (A) creates unnecessary risk; national CBDCs don't compete with DeFi (C). Level 0 (D) fails to capture basic programmability benefits (limits, compliance). Level 1-2 matches user sophistication, risk tolerance, and use case requirements. Additional features can be added after successful basic deployment.

---

Which of the following is the strongest indicator that a programmable money implementation is over-engineered?

A) The technology uses blockchain rather than traditional database
B) Features are being used by all users regularly
C) Features exist that users don't use, while adding security attack surface
D) The implementation took longer to develop than competitors

Correct Answer: C

Explanation: Over-engineering is specifically characterized by features that add complexity and risk without proportional usage or value. Unused features that add attack surface are the definition of over-engineering. Blockchain choice (A) is architectural, not inherently over-engineering. High usage (B) indicates appropriate engineering. Development time (D) might indicate thoroughness or complexity but doesn't define over-engineering.

---

As programmability level increases from Level 2 to Level 4, what generally happens to user adoption in mass-market retail contexts?

A) Adoption increases because users want more features
B) Adoption stays constant because technology is transparent to users
C) Adoption tends to decrease due to increased complexity, cognitive load, and error risk
D) Adoption becomes unpredictable with no general pattern

Correct Answer: C

Explanation: Research consistently shows complexity reduces mass-market adoption. Higher programmability means more concepts to learn, more possible states, more error types, and less predictability. While sophisticated users may value features, mass retail prioritizes simplicity. The inverse relationship between complexity and mass-market adoption is a consistent pattern across financial services.

---

XRPL's deliberate limitation of programmability (Hooks rather than Turing-complete smart contracts) represents:

A) A technical limitation that Ripple couldn't overcome
B) A strategic choice optimizing for speed and security over maximum programmability, appropriate for payment use cases
C) A mistake that should be corrected by adding full smart contract capability
D) A temporary measure until better technology is available

Correct Answer: B

Explanation: XRPL's design is a deliberate architectural choice, not a limitation. By constraining programmability, XRPL achieves faster settlement and smaller attack surface—priorities for payment use cases. This means it can't compete for complex DeFi, but that's not its target market. The choice is appropriate for XRPL's positioning; adding full programmability would change the security and speed tradeoffs that define its value proposition.

---

When applying the programmability selection framework, which question should be asked FIRST?

A) What programmability level do competitors use?
B) What is the maximum programmability technology can achieve?
C) What is the use case precisely, and what conditions must money enforce?
D) What programmability level sounds best in marketing?

Correct Answer: C

Explanation: The framework starts with precise use case definition and minimum required conditions. Everything else follows from understanding what problem you're solving. Competitor analysis (A) is Step 6, not first. Technical capability (B) defines ceiling but not appropriateness. Marketing considerations (D) should follow, not lead, design decisions. Starting anywhere else risks building for the wrong requirements.

---

For Next Lesson:
Phase 1 complete. Phase 2 begins with Lesson 8, exploring specific applications of programmable money—starting with programmable monetary policy and what happens when central banks can code their intentions into currency.

---

End of Lesson 7 and Phase 1

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

---

• Previous: Lesson 6 - Current Implementations
• Next: Lesson 8 - Programmable Monetary Policy (Phase 2 begins)
• Course Overview: Course 64 - Future of Programmable Money
• Track: CBDC (Capstone Course)

---

Phase 2 (Lessons 8-14) explores applications and implications—what programmable money enables and what it threatens.