reference: RIPple, the definitive discussion (Trilema, 2013)

nazim commented

2026-03-07 02:51:18 +00:00

Contributor

Short Summary

A technical teardown of Ripple's trust model, identifying three "fatal congenital defects" that make undifferentiated, averaged trust systems fundamentally broken — with an extended analysis of lemon market dynamics (Akerlof) applied to trust networks.

Detailed Summary

Author: Mircea Popescu | Date: 2013 | Source: trilema.com/2013/ripple-the-definitive-discussion

The article identifies three fatal flaws in Ripple's design, all rooted in how it handles trust:

Fatal defect #1: Unlimited, unconditional trust. If you trust X for Y amount, X can issue infinite debt — your trust doesn't rescind when they exceed Y. You've written a blank check.

Fatal defect #2: Unremunerated trust. You provide liquidity (by trusting counterparties) but receive zero compensation. Ripple is "the only repo market in the history of finance working on 0% interest rates."

Fatal defect #3: Averaged/undifferentiated debt. If you trust both Lou Jiwei (China's finance minister) and a random stranger, Ripple treats their IOUs as fungible. Anyone who trusts the stranger can swap the stranger's IOUs for Lou Jiwei's IOUs that you hold. You end up paying for a cab with "DELLOR" bills because your boss trusted his 5-year-old daughter.

The article then applies Akerlof's lemon market theory: when buyers can't distinguish quality, sellers introduce progressively worse goods, buyers lower their price expectations, good sellers exit, and the market collapses to only the worst offerings. Ripple's trust averaging creates exactly this dynamic.

Key insight for trust systems: Trust must be differentiated — who specifically you trust, for what, and how much. Averaging, pooling, or making trust transitive without bounds destroys the information content that makes trust useful.

## Short Summary A technical teardown of Ripple's trust model, identifying three "fatal congenital defects" that make undifferentiated, averaged trust systems fundamentally broken — with an extended analysis of lemon market dynamics (Akerlof) applied to trust networks. ## Detailed Summary **Author:** Mircea Popescu | **Date:** 2013 | **Source:** `trilema.com/2013/ripple-the-definitive-discussion` The article identifies three fatal flaws in Ripple's design, all rooted in how it handles trust: **Fatal defect #1: Unlimited, unconditional trust.** If you trust X for Y amount, X can issue infinite debt — your trust doesn't rescind when they exceed Y. You've written a blank check. **Fatal defect #2: Unremunerated trust.** You provide liquidity (by trusting counterparties) but receive zero compensation. Ripple is "the only repo market in the history of finance working on 0% interest rates." **Fatal defect #3: Averaged/undifferentiated debt.** If you trust both Lou Jiwei (China's finance minister) and a random stranger, Ripple treats their IOUs as fungible. Anyone who trusts the stranger can swap the stranger's IOUs for Lou Jiwei's IOUs that you hold. You end up paying for a cab with "DELLOR" bills because your boss trusted his 5-year-old daughter. The article then applies Akerlof's lemon market theory: when buyers can't distinguish quality, sellers introduce progressively worse goods, buyers lower their price expectations, good sellers exit, and the market collapses to only the worst offerings. Ripple's trust averaging creates exactly this dynamic. **Key insight for trust systems:** Trust must be *differentiated* — who specifically you trust, for what, and how much. Averaging, pooling, or making trust transitive without bounds destroys the information content that makes trust useful.

ripple-the-definitive-discussion.pdf

25 KiB

nazim commented

2026-03-07 02:53:01 +00:00

Author

Contributor

Impact on Interaction Ledger PRD (#211)

This article provides the strongest argument for several of the PRD's design decisions — and a warning about Phase 3:

Why the ledger is per-peer, not aggregated — Ripple's fatal flaw #3 (averaging trust) is exactly what the ledger avoids. Each peer gets its own assessment, its own history, its own score. The PRD should cite this article as the prior art argument for why per-peer granularity matters.
NIP-85 compatibility warning — NIP-85 (Trusted Assertions) publishes aggregated rank scores (normalized 0-100) for pubkeys. This is structurally similar to Ripple's averaging — it collapses differentiated, per-interaction trust into a single number. The PRD claims NIP-85 export compatibility, but this article argues that the aggregation step itself destroys the valuable information. The PRD should address this tension.
Lemon market dynamics in agent trust — If agents share trust scores publicly (Phase 3 WoT), the same lemon dynamics apply: bad agents benefit from the average, good agents are undervalued, and the market trends toward adverse selection. The PRD's local-first design delays this problem but doesn't solve it for the gossip phase.
Trust must specify scope — Ripple's defect #1 (unlimited trust) warns against the PRD's current design where assessment scores are interaction-type agnostic. An agent might be trustworthy for information requests but unreliable for paid work. The PRD's "assessment is interaction-type agnostic" design choice should at least acknowledge this tradeoff.

See: #211

### Impact on Interaction Ledger PRD (#211) This article provides the strongest argument for several of the PRD's design decisions — and a warning about Phase 3: 1. **Why the ledger is per-peer, not aggregated** — Ripple's fatal flaw #3 (averaging trust) is exactly what the ledger avoids. Each peer gets its own assessment, its own history, its own score. The PRD should cite this article as the prior art argument for why per-peer granularity matters. 2. **NIP-85 compatibility warning** — NIP-85 (Trusted Assertions) publishes aggregated `rank` scores (normalized 0-100) for pubkeys. This is structurally similar to Ripple's averaging — it collapses differentiated, per-interaction trust into a single number. The PRD claims NIP-85 export compatibility, but this article argues that the aggregation step itself destroys the valuable information. The PRD should address this tension. 3. **Lemon market dynamics in agent trust** — If agents share trust scores publicly (Phase 3 WoT), the same lemon dynamics apply: bad agents benefit from the average, good agents are undervalued, and the market trends toward adverse selection. The PRD's local-first design delays this problem but doesn't solve it for the gossip phase. 4. **Trust must specify scope** — Ripple's defect #1 (unlimited trust) warns against the PRD's current design where assessment scores are interaction-type agnostic. An agent might be trustworthy for information requests but unreliable for paid work. The PRD's "assessment is interaction-type agnostic" design choice should at least acknowledge this tradeoff. See: #211

nazim referenced this issue

2026-03-07 03:54:51 +00:00

proposal: Peer Interaction Ledger #211

~~nazim referenced this issue 2026-03-07 04:53:06 +00:00~~

docs: PRD for Cobot trust infrastructure #199

~~nazim referenced this issue 2026-03-07 05:08:42 +00:00~~

docs: PRD for Cobot trust infrastructure #199

nazim referenced this issue

2026-03-07 05:16:13 +00:00

docs: PRD for Cobot trust infrastructure #199

David referenced this issue

2026-03-07 10:57:47 +00:00

proposal: Peer Interaction Ledger #211

doxios commented

2026-03-07 11:04:03 +00:00

Collaborator

How #211 handles this

Directly integrated as a design constraint. Reference [9] cites this, and the PRD explicitly addresses the three fatal defects:

Averaging/pooling trust destroys information → The ledger stores per-peer assessments, never averages. The L1/L2 walkthrough in Appendix A directly contrasts info-quality scoring (forces rationale reading) vs behavioral scoring (tempts averaging) and concludes: "recreating Ripple's fatal defect."
Per-peer differentiation is essential → The schema enforces this: each assessment is tied to a specific peer_id. No aggregation layer.
Scope-blind trust is dangerous → Addressed with a nuanced take: "The Ripple teardown warns that scope-blind trust averaging destroys information — but this applies to AGGREGATED scores, not local assessments where the agent has full rationale context." Phase 3 constraint explicitly added: "any export or sharing of assessments MUST include the rationale alongside the score. Exporting scores without rationale recreates Ripple's fatal defect."

This is the most carefully handled reference. The PRD distinguishes where the warning applies (aggregation) from where it doesn't (local assessment with full context), which shows genuine understanding rather than blanket citation.

## How #211 handles this **Directly integrated as a design constraint.** Reference [9] cites this, and the PRD explicitly addresses the three fatal defects: 1. **Averaging/pooling trust destroys information** → The ledger stores per-peer assessments, never averages. The L1/L2 walkthrough in Appendix A directly contrasts info-quality scoring (forces rationale reading) vs behavioral scoring (tempts averaging) and concludes: "recreating Ripple's fatal defect." 2. **Per-peer differentiation is essential** → The schema enforces this: each assessment is tied to a specific `peer_id`. No aggregation layer. 3. **Scope-blind trust is dangerous** → Addressed with a nuanced take: "The Ripple teardown warns that scope-blind trust averaging destroys information — but this applies to AGGREGATED scores, not local assessments where the agent has full rationale context." **Phase 3 constraint explicitly added:** "any export or sharing of assessments MUST include the rationale alongside the score. Exporting scores without rationale recreates Ripple's fatal defect." **This is the most carefully handled reference.** The PRD distinguishes where the warning applies (aggregation) from where it doesn't (local assessment with full context), which shows genuine understanding rather than blanket citation.