Trust Lines as Credit Infrastructure

The technical foundation:

TRUST LINE STRUCTURE:

Basic Components:
├── Two accounts (issuer and holder)
├── Currency code (USD, EUR, or custom)
├── Balance (positive = holding, negative = owing)
├── Limit (maximum you'll accept)
└── Flags (settings like NoRipple, freeze)

CREATING A TRUST LINE:

Transaction: TrustSet
{
"Account": "rHolder...",
"LimitAmount": {
"currency": "USD",
"issuer": "rIssuer...",
"value": "1000" // Maximum you'll accept
}
}

Result:
├── Trust line created between accounts
├── Holder willing to accept up to 1000 USD from Issuer
├── Issuer can now "send" USD to Holder
├── Balance tracks how much USD Holder holds
└── Trust is one-directional (issuer doesn't automatically trust holder)

BALANCE INTERPRETATION:

From Holder's Perspective:
├── Positive balance = They hold issued currency
├── Zero balance = No outstanding IOUs
├── Negative balance = They OWE the issuer (rare, requires specific setup)
└── Balance represents claim on issuer

From Issuer's Perspective:
├── Holder's positive balance = Issuer's liability
├── Total outstanding = All holders' balances summed
├── Issuer "owes" the currency to holders
└── Redemption responsibility

EXAMPLE:

Alice trusts Bob to issue up to 1000 USD.
Bob sends Alice 500 USD (via Payment transaction).

Result:
├── Alice has trust line showing +500 USD
├── Bob has corresponding -500 USD (liability)
├── Bob "owes" Alice 500 USD
├── Alice can send this 500 USD to anyone who trusts Bob
└── Network of trust enables currency flow
```

Key differences:

COMPARISON:

┌─────────────────┬─────────────────────┬─────────────────────┐
│ Feature         │ XRPL Trust Lines    │ Smart Contract      │
│                 │                     │ Tokens (ERC-20)     │
├─────────────────┼─────────────────────┼─────────────────────┤
│ Relationship    │ Bilateral           │ Unilateral          │
│ Credit explicit │ Yes (it's credit)   │ No (just ownership) │
│ Requires setup  │ Yes (TrustSet)      │ No (permissionless) │
│ Reserve req.    │ Yes (2 XRP)         │ No                  │
│ Issuer controls │ Freeze, limits      │ If coded into token │
│ Programmability │ Limited (flags)     │ Unlimited (code)    │
│ Interoperability│ Protocol-level      │ Standard-dependent  │
│ Gas/fees        │ Very low            │ Variable (network)  │
└─────────────────┴─────────────────────┴─────────────────────┘

KEY INSIGHT:

Trust Lines:
├── "I trust YOU to owe me up to X"
├── Relationship-based
├── Explicitly credit
└── Protocol-native

Smart Contract Tokens:
├── "Contract says I own X tokens"
├── Asset-based (ownership, not credit)
├── Credit is emergent (via protocols)
└── Built on top of base layer

IMPLICATIONS:

Trust lines make credit a first-class citizen.
├── No smart contract needed for basic credit
├── But limited programmability
├── Trade-off: Simplicity vs. flexibility
└── Best for simple, bilateral arrangements
```

Understanding payment routing:

RIPPLING EXPLAINED:

What It Is:
├── Automatic balance adjustment across connected trust lines
├── Enables payment routing through intermediaries
├── Key to XRPL's original "ripple" vision
└── Can be enabled or disabled per trust line

HOW RIPPLING WORKS:

Scenario:
├── Alice trusts Bank1 for USD
├── Carol also trusts Bank1 for USD
├── Rippling enabled on both trust lines

Alice wants to pay Carol 100 USD:
├── Alice's balance with Bank1: -100 (she now owes Bank1)
├── Carol's balance with Bank1: +100 (she now holds)
├── Bank1's net position: unchanged (balanced)
├── Payment completed through Bank1 as intermediary
└── No actual movement of assets—just balance adjustments

RELEVANCE TO LENDING:

Multi-Hop Possibilities:
├── Credit could "ripple" through network
├── A trusts B, B trusts C, A can pay C
├── Creates credit network, not just bilateral
└── Original vision for global payments

WHY IT'S COMPLEX:
├── Most users disable rippling (NoRipple flag)
├── Prevents unexpected balance changes
├── Privacy and control concerns
├── Limits network payment routing
└── Feature exists but rarely used as intended

FOR LENDING:
├── Could enable credit routing in theory
├── "Alice borrows from network" via rippling
├── Practically: Too complex, unpredictable
├── Pooled lending is simpler
└── Rippling better for payments than lending

---

How trust lines could enable direct lending:

P2P LENDING VIA TRUST LINES:

BASIC MODEL:

Traditional P2P Lending:
├── Lender wants to earn yield
├── Borrower needs capital
├── Platform matches them
├── Agreement governs terms
└── Repayment over time

Trust Line Implementation:
├── Lender issues currency to borrower
├── Borrower holds positive balance (has funds)
├── Lender holds negative balance (is owed)
├── Repayment = Borrower sends back to lender
└── Balance returns to zero

EXAMPLE:

Setup:
├── Bob (lender) creates issued currency: "BOBUSD"
├── Alice (borrower) creates trust line accepting BOBUSD
├── Terms agreed off-chain: 1 year, 5% interest
└── Trust line limit set to loan amount

Disbursement:
├── Bob sends 10,000 BOBUSD to Alice
├── Alice's balance: +10,000 BOBUSD
├── Bob's total liability: -10,000 BOBUSD
└── Alice can use BOBUSD (if others accept it)

Repayment:
├── After 1 year, Alice owes 10,500 BOBUSD (with interest)
├── Alice sends 10,500 back to Bob
├── Alice's balance: 0
├── Bob's liability: 0
├── Loan complete

THE PROBLEM:

Alice needs to GET 10,500 to repay.
├── If only Bob issues BOBUSD, where does extra 500 come from?
├── Interest cannot be created from thin air
├── Requires Bob to issue more, or use different currency
└── Economic model breaks down

SOLUTION:
├── Use established currency (RLUSD, USD gateway)
├── Lender extends RLUSD trust, sends RLUSD
├── Borrower repays RLUSD from any source
├── Interest problem solved (RLUSD is fungible)
└── But then lender needs RLUSD to lend (not creating credit)
```

Why pooled lending dominates:

COMPARISON ANALYSIS:

POOLED LENDING (AAVE MODEL):
├── Lenders deposit to shared pool
├── Borrowers draw from shared pool
├── Protocol handles matching
├── Utilization-based rates
├── No direct lender-borrower relationship

TRUST LINE LENDING (P2P MODEL):
├── Lender extends credit directly
├── Borrower accepts from specific lender
├── Direct bilateral relationship
├── Negotiated or fixed rates
├── Counterparty-specific risk

ADVANTAGES OF POOLED:

1. No Matching Problem

2. Risk Distribution

3. Standardization

4. Composability

ADVANTAGES OF TRUST LINE P2P:

1. Direct Relationship

2. Simplicity

3. No Pool Risk

4. Lower Fees

VERDICT:

Pooled lending wins for:
├── Retail users (simplicity, no matching)
├── Large markets (liquidity, scalability)
├── Permissionless access (no relationship needed)
└── DeFi composability

Trust line P2P better for:
├── Known counterparties (business relationships)
├── Custom terms (negotiated deals)
├── Small groups (friends, family)
└── Privacy (no public protocol)
```

Why P2P lending without platforms struggles:

THE FUNDAMENTAL CHALLENGE:

SUPPLY-DEMAND MISMATCH:

Lender Alice:
├── Wants to lend $10,000
├── For 1 year
├── At 6% interest
├── To creditworthy borrower
└── When: Now

Borrower Bob:
├── Needs to borrow $15,000
├── For 6 months
├── Willing to pay 5%
├── Has moderate credit
└── When: Next month

Problem:
├── Amount doesn't match
├── Duration doesn't match
├── Rate doesn't match
├── Timing doesn't match
├── Credit quality unknown
└── Direct P2P fails without coordination

HOW PLATFORMS SOLVE THIS:

Pooled Lending (DeFi):
├── Many lenders → One pool
├── Pool absorbs mismatches
├── Rates adjust automatically
├── Duration flexible (withdraw anytime)
└── Protocol handles everything

P2P Platforms (Traditional):
├── Platform matches lenders/borrowers
├── Fragments loans across lenders
├── Diversification handled by platform
├── Standardized terms offered
└── Platform takes fee for coordination

TRUST LINES ALONE:

Without Platform:
├── Requires finding counterparty yourself
├── Requires agreeing on terms yourself
├── Requires managing risk yourself
├── Requires tracking repayment yourself
└── Only works with existing relationships

With Platform:
├── Platform could use trust lines as settlement
├── But then why not use pooled model?
├── Platform adds complexity trust lines don't need
└── Limited advantage over alternatives

REALISTIC USE CASES FOR P2P TRUST LINES:

Works Well:
├── Business extends credit to customer
├── Friends/family loan
├── Small business trade credit
├── Gateway extending credit to known clients
└── Institutional bilateral agreements

Doesn't Work:
├── General public lending market
├── Anonymous lending/borrowing
├── Scale beyond dozens of relationships
├── Without existing trust relationship
└── Without off-chain coordination

---

Where trust lines shine:

TRADE CREDIT ON XRPL:

CONCEPT:
Business extends credit to customers using trust lines.

TRADITIONAL TRADE CREDIT:
├── Supplier ships goods to customer
├── Invoice: "Net 30" (pay in 30 days)
├── Customer owes supplier
├── No bank involved
├── Common in B2B commerce
└── ~$3 trillion market in US alone

XRPL IMPLEMENTATION:

Setup:
├── Supplier creates issued currency (SupplierUSD)
├── Customer sets trust line accepting SupplierUSD
├── Trust limit = Credit line approved
└── Ready for transactions

1. Customer orders $10,000 of goods
2. Supplier ships goods
3. Supplier "pays" customer 10,000 SupplierUSD
4. Wait—supplier pays customer?

The Trick:
├── Customer's balance: +10,000 SupplierUSD
├── This represents: "Supplier delivered value"
├── Customer's obligation: Settle this balance
├── Settlement: Customer sends real USD (or RLUSD)
└── Trust line shows outstanding trade credit

Better Model:
├── Use standard stablecoin (RLUSD)
├── Supplier sets trust line to customer
├── Customer can "draw" RLUSD up to limit
├── Customer's negative balance = Amount owed
├── Customer repays with RLUSD from any source
└── Cleaner settlement

ADVANTAGES:

For Suppliers:
├── Clear visibility of outstanding credit
├── On-chain record
├── Can set limits per customer
├── Automates tracking
└── Lower admin cost

For Customers:
├── Flexible credit line
├── No bank intermediary
├── Real-time balance visibility
├── Simpler than traditional invoicing
└── Global accessibility

LIMITATIONS:
├── Requires both parties on XRPL
├── Customer must understand trust lines
├── Settlement still needs integration
├── Limited dispute resolution
└── Suits tech-savvy businesses
```

Financial institutions extending credit:

GATEWAY/FIAT CREDIT MODEL:

CONCEPT:
Licensed institution extends credit via trust lines.

HOW IT WORKS:

Gateway Setup:
├── Gateway is licensed financial institution
├── Has fiat banking relationships
├── Issues USD-backed tokens on XRPL
├── Maintains reserves for redemption
└── Regulated entity with compliance

Credit Extension:
├── Gateway underwrites customer
├── Sets trust line limit based on credit assessment
├── Customer can "overdraft" up to limit
├── Negative balance = Credit used
├── Interest charged off-chain or via periodic settlements
└── Traditional credit, XRPL rails

EXAMPLE:

Customer Approved for $50,000 Credit:
├── Gateway sets trust line: $50,000 limit
├── Customer draws $20,000 (negative balance)
├── Customer uses for business needs
├── Monthly: Customer repays + interest
├── Credit line revolves
└── Standard credit line, blockchain settlement

ADVANTAGES:

For Gateway:
├── Efficient credit delivery
├── Real-time visibility
├── Lower operational cost
├── Global reach on XRPL
└── Modern infrastructure

For Customer:
├── Fast access to credit
├── Transparent balances
├── International flexibility
├── Lower fees potentially
└── Modern experience

CURRENT STATE:

Limited Implementation:
├── Few gateways offer this currently
├── Regulatory complexity
├── Requires banking infrastructure
├── KYC/AML requirements
├── Business model development needed
└── Potential more than current reality
```

Informal lending groups:

CREDIT CIRCLE MODEL:

CONCEPT:
Group of trusted individuals extend credit to each other.

TRADITIONAL EXAMPLES:
├── ROSCAs (Rotating Savings and Credit Associations)
├── Lending circles
├── Family credit networks
├── Business partner credit
└── Common globally, especially in developing markets

XRPL IMPLEMENTATION:

Setup:
├── Group of 10 friends agrees to mutual credit
├── Each creates trust lines to others
├── Limit: $1,000 per relationship
├── Total credit access: $9,000 each
└── Mutual trust network established

Operation:
├── Alice needs $500, draws from Bob's trust line
├── Later, Carol needs $300, draws from Alice
├── Balances tracked automatically
├── Periodic settlement (monthly)
├── Or ongoing revolving credit
└── Social pressure ensures repayment

ADVANTAGES:

Why This Works:
├── Existing trust relationships
├── Social accountability
├── Flexible, informal
├── No intermediary fees
├── Fast access within circle
└── Already common offline—blockchain makes it trackable

XRPL Benefits:
├── Clear balance tracking
├── No disputes about who owes what
├── Transparent to group
├── Works across geographies
├── Lower friction than bank transfers
└── Programmable rules possible (with Hooks)

CHALLENGES:

Practical Issues:
├── All members need XRPL wallets
├── Requires trust line setup (technical)
├── Reserve requirements add cost
├── Cultural/education barrier
├── Scale limited (10-20 people max practical)
└── Better suited for tech-savvy groups

REALISTIC ASSESSMENT:
├── Niche but valid use case
├── Works where trust exists
├── Not replacement for institutional lending
├── Complement to formal systems
└── Could grow with better UX

---

Combining trust lines with pooled lending:

HYBRID APPROACH:

CONCEPT:
Use trust lines for settlement, pooled model for matching.

HOW IT COULD WORK:

Lending Pool Structure:
├── Protocol holds deposited RLUSD
├── Borrowers draw from pool (standard)
├── BUT: Borrower positions represented as trust lines
├── Borrower's negative balance = Amount owed to pool
└── Repayment updates trust line balance

BENEFITS:

Why Bother with Trust Lines?

1. Native Settlement

2. Familiar Credit Model

3. Compliance Features

IMPLEMENTATION SKETCH:

Protocol Setup:
├── Protocol creates issued currency: "PoolDebt"
├── Protocol holds RLUSD deposits
├── Borrowers set trust line to Protocol
└── Trust limit = Max borrow capacity

Borrowing:
├── User requests borrow of 1,000 RLUSD
├── Protocol checks collateral (separate logic)
├── Protocol "sends" 1,000 PoolDebt to user
├── User's balance: +1,000 PoolDebt (they owe this)
├── Protocol sends 1,000 RLUSD to user (actual funds)
└── Trust line tracks debt

Repayment:
├── User sends RLUSD to protocol
├── Protocol sends PoolDebt back (burns it)
├── User's PoolDebt balance decreases
├── Loan partially/fully repaid
└── Simple bookkeeping

CHALLENGES:

Complexity:
├── Two-token system (RLUSD + PoolDebt)
├── More transactions than pure pool model
├── Trust line setup required
├── May not be simpler than alternatives
└── Engineering overhead

Questions:
├── Does this actually improve anything?
├── Or just add complexity?
├── Need clear benefit to justify
└── Evaluate case-by-case
```

Reputation systems for creditworthiness:

TRUST LINE-BASED REPUTATION:

CONCEPT:
Credit history visible through trust line patterns.

ON-CHAIN CREDIT SIGNALS:

What Trust Lines Reveal:
├── Who extends credit to this account
├── What limits they've set
├── Payment history (balance changes)
├── Duration of relationships
└── Network of trust

Potential Credit Score Inputs:
├── Number of trust lines with gateways
├── Limits granted by reputable issuers
├── History of balance repayment
├── Age of trust line relationships
├── Network centrality in trust graph
└── Never defaulted vs. freeze events

BUILDING A SCORE:

Example Factors:
├── Gateway trust lines: +10 points per established gateway
├── Limit amounts: Higher limits = Higher trust
├── Repayment speed: Fast repayment = Higher score
├── Account age: Older = More reliable
├── Freeze history: Any freeze = Major penalty
└── Combine for composite score

Use in Lending:
├── Score determines max LTV
├── Score affects interest rate
├── Score unlocks larger positions
├── Build credit over time
└── Similar to traditional credit building

CURRENT STATE:

Not Implemented:
├── No standard credit scoring on XRPL yet
├── Would require analysis tools
├── Privacy concerns exist
├── Gaming potential
└── Promising idea, not reality

CHALLENGES:

Gaming:
├── Create fake trust lines to boost score
├── Collude with friends for mutual credit
├── Sybil attacks possible
├── Needs robust anti-gaming measures
└── Harder than traditional credit bureaus

Privacy:
├── Trust lines are public
├── Everyone can see credit relationships
├── Some users won't want this
├── May limit adoption
└── Privacy-preserving scoring needed

Utility:
├── XRPL-only history is limited
├── Doesn't capture off-chain activity
├── May not predict repayment well
├── Needs validation against outcomes
└── Unproven correlation to creditworthiness
```

Enterprise use cases:

INSTITUTIONAL APPLICATIONS:

CORPORATE CREDIT LINES:

Scenario:
├── Large corporation with XRPL treasury
├── Partner bank extends credit line
├── Credit accessed via trust line
├── Transparent to both parties
└── Settlement in RLUSD or fiat

Implementation:
├── Bank sets trust line: $10M limit
├── Corporation draws as needed
├── Real-time visibility for both
├── Automated compliance checks
├── Settlement per agreement
└── Efficient, transparent, auditable

TREASURY MANAGEMENT:

Multi-Entity Credit:
├── Parent company extends credit to subsidiaries
├── Trust lines represent internal credit
├── Real-time intercompany tracking
├── Simplified reconciliation
├── On-chain audit trail
└── Treasury efficiency

Liquidity Management:
├── Surplus units lend to deficit units
├── Trust lines enable instant transfer
├── Interest calculated programmatically
├── Eliminates manual processes
└── 24/7 operation

SUPPLY CHAIN FINANCE:

Letter of Credit Alternative:
├── Buyer's bank extends trust line to seller
├── Seller receives credit upon shipping proof
├── Self-executing based on conditions
├── Lower cost than traditional LC
└── Faster settlement

Invoice Financing:
├── Factor extends credit against receivables
├── Trust line represents credit facility
├── Draw against approved invoices
├── Repay as invoices collect
└── Efficient working capital

CURRENT ADOPTION:

Limited But Growing:
├── Few implementations live today
├── Institutional interest increasing
├── Regulatory clarity needed
├── Integration complexity
├── Early stage of adoption curve
└── Watch for pilot programs

---

Cost of trust lines:

XRPL RESERVE IMPACT:

CURRENT RESERVES (Subject to Change):

Base Reserve: 10 XRP per account
Owner Reserve: 2 XRP per owned object (including trust lines)

TRUST LINE COST:

Each Trust Line:
├── 2 XRP locked while trust line exists
├── Recovered when trust line deleted
├── At $1/XRP = $2 per trust line
├── At $10/XRP = $20 per trust line
└── Meaningful cost at scale

FOR P2P LENDING:

Example User with Multiple Credit Relationships:
├── 10 trust lines = 20 XRP locked
├── At $5/XRP = $100 in reserves
├── This is cost of participation
├── Limits small-value lending
└── Friction for casual use

COMPARISON:

Trust Line Cost: 2 XRP per relationship
Smart Contract (Ethereum): Gas for approval (~$5-50 depending on network)

At Low XRP Prices: Trust lines cheaper
At High XRP Prices: Trust lines expensive
Variable Cost: Uncertainty for users

IMPLICATIONS:

For P2P Lending:
├── Reserve requirement limits casual participation
├── Makes sense for substantial relationships
├── Less suited for micro-lending
├── Economic barrier to entry
└── Consider in protocol design

For Pooled Lending:
├── Users only need one trust line (to pool)
├── More efficient use of reserves
├── Pool absorbs complexity
└── Better scalability
```

Practical barriers:

UX CHALLENGES:

TRUST LINE SETUP:

1. Have XRPL wallet
2. Have sufficient XRP for reserves
3. Understand trust line concept
4. Know issuer address
5. Execute TrustSet transaction
6. Verify correct setup

For Average User:
├── "What's a trust line?"
├── "Why do I need to lock XRP?"
├── "How do I find the issuer address?"
├── "Did I do this right?"
└── Confusion and abandonment

WALLET SUPPORT:

Current State:
├── Some wallets hide trust line complexity
├── Others expose raw transactions
├── Inconsistent experience across wallets
├── No standard "set up credit" flow
└── Varies significantly

Ideal State:
├── "Accept credit from [name]" button
├── Clear explanation of terms
├── Reserve requirement shown
├── Confirmation of setup
└── Simple, like adding a contact

ONGOING MANAGEMENT:

What Users Need:
├── View all trust lines
├── See balances owed/held
├── Track credit limits
├── Manage settings (NoRipple, etc.)
├── Delete unused trust lines
└── Currently: Requires technical knowledge

FOR LENDING SPECIFICALLY:

Additional Needs:
├── Interest calculation visibility
├── Repayment tracking
├── Due date reminders
├── Collateral status (if applicable)
├── Clear loan terms display
└── Currently: No standard tooling

BOTTOM LINE:
├── Trust lines work technically
├── UX is currently poor for average user
├── Limits adoption to technical users
├── Needs significant improvement
└── Opportunity for builders
```

Decision framework:

DECISION FRAMEWORK:

USE TRUST LINES WHEN:

✓ Known Counterparty
├── You know who you're lending to/borrowing from
├── Existing relationship
├── Trust already established
└── Custom terms desired

✓ Bilateral Relationship
├── One-to-one arrangement
├── Not seeking to join pool
├── Direct accountability preferred
└── Relationship-based lending

✓ Specific Terms Needed
├── Non-standard duration
├── Custom interest calculation
├── Special conditions
├── Negotiated arrangement
└── Template doesn't fit

✓ Privacy Desired
├── Don't want to use public protocol
├── Bilateral transaction only
├── Between two parties
└── Lower visibility

✓ Trade Credit/Business
├── Supplier-customer relationships
├── Professional contexts
├── Revolving credit lines
└── B2B applications

USE POOLED LENDING WHEN:

✓ No Specific Counterparty
├── Just want to lend/borrow
├── Don't care who specifically
├── Matching handled automatically
└── Anonymous/pseudonymous

✓ Market Rates Desired
├── Want fair market pricing
├── Rate discovery through utilization
├── Competitive rates
└── Transparent pricing

✓ Liquidity Important
├── Want to exit position anytime
├── Flexibility valued
├── No lock-up
└── Active management

✓ Risk Diversification
├── Spread across many borrowers
├── Pool absorbs individual defaults
├── Lower idiosyncratic risk
└── More stable returns

✓ DeFi Composability
├── Want to use position elsewhere
├── Building strategies
├── Yield optimization
└── Integration with ecosystem

LIKELY OUTCOME:

Pooled lending for most users (80%+)
Trust lines for specific relationships (20%-)
Complementary, not competitive

---

✅ Trust lines work as credit relationships - The technical mechanism functions. Credit can be extended and tracked on-chain.

✅ Unique to XRPL - No other major blockchain has this native primitive. It's a genuine differentiator.

✅ Suits specific use cases - Trade credit, known counterparty lending, and institutional arrangements can use trust lines effectively.

⚠️ Scale potential - Can trust line-based lending grow beyond niche use cases? Unclear.

⚠️ UX improvements - Will tooling improve enough for mainstream adoption? Depends on development.

⚠️ Institutional adoption - Will institutions actually use trust lines for credit? Promising but unproven.

🔴 Assuming trust lines replace pooled lending - They serve different purposes. Pooled lending dominates for good reasons.

🔴 Ignoring UX barriers - Current complexity limits adoption. Can't just build it and expect users.

🔴 Over-engineering - Adding trust line complexity where simple pools work better wastes effort.

Trust lines are a unique and valuable XRPL primitive that enable credit relationships at the protocol level. However, they don't solve the matching problem that makes pooled lending dominant. Trust lines are best suited for specific use cases: known counterparties, trade credit, institutional arrangements, and community credit circles. They complement rather than replace pooled lending protocols. The challenge is identifying and building for the right use cases rather than forcing trust lines where pools work better.

---

Assignment: Design a specific trust line-based credit application, identifying target users, implementation approach, and realistic adoption pathway.

Requirements:

Part 1: Use Case Selection (20%)

• Trade credit for specific industry
• Community lending circle
• Institutional credit facility
• Gateway credit extension
• Your own concept

Justify why trust lines suit this use case better than pooled lending.

Part 2: Technical Design (30%)

• Trust line structure (currencies, limits, settings)
• Transaction flow for credit extension
• Transaction flow for repayment
• Interest handling approach
• Default/dispute handling

Part 3: User Experience (25%)

• Onboarding process
• Credit application/approval
• Drawing on credit
• Repayment workflow
• Balance monitoring

Identify UX challenges and proposed solutions.

Part 4: Adoption Strategy (25%)

• Target user identification

• Value proposition vs. alternatives

• Barriers to adoption

• Go-to-market approach

• Success metrics

• Use case fit for trust lines (25%)

• Technical soundness (25%)

• UX thoughtfulness (25%)

• Realistic adoption assessment (25%)

Time investment: 2-3 hours
Value: Forces practical thinking about where trust lines actually add value.

---

For Next Lesson:
Lesson 13 examines the EVM sidechain—how Ethereum-compatible infrastructure parallel to XRPL mainnet opens additional lending possibilities and what trade-offs are involved.

---

End of Lesson 12

Total words: ~6,400
Estimated completion time: 55 minutes reading + 2-3 hours for deliverable exercise