Trust Lines and Issued Currencies - The Foundation | Tokenization on XRPL | XRP Academy - XRP Academy
3 free lessons remaining this month

Free preview access resets monthly

Upgrade for Unlimited
Skip to main content
intermediate60 min

Trust Lines and Issued Currencies - The Foundation

Learning Objectives

Explain the trust line model and how it differs from other tokenization approaches

Configure trust line properties for different tokenization requirements

Implement compliance features including freeze, clawback, and authorized trust lines

Evaluate counterparty risk inherent in the trust line model

Determine when trust lines are appropriate versus MPTs or other approaches

XRPL's tokenization model is fundamentally different from Ethereum's:

  • Issuer deploys smart contract

  • Contract tracks all balances

  • Anyone can receive tokens (unless coded otherwise)

  • Holder doesn't explicitly consent to hold

  • Holder creates trust line TO issuer

  • Trust line is bilateral agreement

  • Holder explicitly opts in to holding

  • Holder sets maximum they'll accept

The Key Insight: On XRPL, you can't receive tokens you haven't agreed to hold. This prevents spam and creates explicit counterparty relationships.


TRUST LINE CREATION:

1. Holder decides to trust Issuer
2. Holder sends TrustSet transaction
3. Trust line established with parameters:
4. Issuer can now send tokens to Holder
5. Holder can send tokens to others (with trust lines)

TRANSACTION STRUCTURE:
TrustSet {
  "TransactionType": "TrustSet",
  "Account": "rHolder...",
  "LimitAmount": {
    "currency": "USD",
    "issuer": "rIssuer...",
    "value": "10000"
  }
}
ISSUER ACCOUNT FLAGS:

- Issuer must approve each trust line
- Enables KYC/AML at protocol level
- Holder creates trust line but can't receive until authorized

- Halts ALL trading of issuer's tokens
- No holder-to-holder transfers
- Emergency response capability

- PERMANENTLY gives up freeze ability
- Cannot be reversed
- Signals commitment to decentralization

- Enables clawback capability
- MUST be set before any trust lines created
- Cannot be enabled after first issuance
TRUST LINE PROPERTIES:

Limit: Maximum tokens holder accepts (holder-controlled)
Balance: Current token amount
Quality In/Out: Exchange rate adjustment for rippling
No Ripple Flag: Prevents balance changes from rippling
Authorized: Whether issuer approved this trust line
Frozen: Whether this specific trust line is frozen
  • Tokens created by sending from issuer to holder
  • Currency code identifies asset (USD, EUR, GOLD, TBILL)
  • Standard: 3-character codes
  • Hex: 40-character for longer names

CRITICAL CONCEPT:
Same currency code from different issuers = different tokens
USD from Issuer A ≠ USD from Issuer B
Issuer is always part of token identity
```


AUTHORIZED TRUST LINE FLOW:

1. Issuer enables RequireAuth flag
2. Holder creates trust line
3. Trust line exists but NOT authorized
4. Holder CANNOT receive tokens yet
5. Issuer verifies holder off-chain (KYC)
6. Issuer sends TrustSet with authorized: true
7. Holder can now receive tokens
8. Issuer can later revoke authorization

- Securities requiring accredited investor verification
- Tokens limited to specific jurisdictions
- AML/KYC compliance
- Restricted distribution during lockup
  • Freezes single trust line
  • Holder can only send to issuer (redeem)
  • Cannot send to other holders
  • Cannot receive more tokens

USE: Suspected fraud, court order, investigation


  • Freezes ALL trust lines for currency
  • No holder-to-holder transfers
  • Emergency halt capability

USE: Security breach, regulatory order, major issue


  • Permanently gives up freeze ability
  • Cannot be reversed
  • Signals "unstoppable" token

WARNING: Cannot respond to court orders, fraud, sanctions
```

CLAWBACK CAPABILITY:

- AllowTrustLineClawback enabled BEFORE first trust line
- Cannot enable after any trust lines exist

- Issuer retrieves tokens from any holder
- No holder consent required
- Tokens disappear from holder's balance

- Court order requiring asset seizure
- Sanctions compliance
- Error correction
- Fraud recovery

UNIQUE TO XRPL:
No other major public blockchain has native clawback
Ethereum requires smart contract implementation
Genuine competitive advantage for compliance

  1. Issuer will redeem tokens for underlying asset
  2. Issuer maintains proper reserves
  3. Issuer won't abuse freeze/clawback powers
  4. Issuer will comply with legal obligations
  5. Issuer will remain solvent
  • Value of underlying asset
  • Issuer solvency
  • Issuer honesty
  • Legal enforceability
  • Redemption capability
  • Transparent ownership records
  • Predictable transfer mechanics
  • Automated compliance features
  • Immutable transaction history
ISSUER DUE DILIGENCE:

LEGAL: Licensed? Clear jurisdiction? Legal recourse?
OPERATIONAL: Track record? Audited reserves? Redemption process?
TECHNICAL: Key management? Multi-sig? Insurance?
COMPLIANCE: KYC/AML processes? Freeze/clawback policies documented?

RIPPLING:
Allows trust line balances to shift through intermediate 
accounts during payments, enabling cross-currency transactions.

Example:
Alice (USD) → Bob (USD/EUR) → Carol (EUR)
Bob's USD increases, EUR decreases automatically

  • Market makers provide liquidity
  • Cross-currency payments happen automatically
  • No active participation required from intermediaries
  • Prevents trust line from being used in rippling
  • Isolates token position
  • No unexpected balance changes

RECOMMENDATION FOR RWA:
Always set NoRipple for RWA tokenization
Prevents unexpected position changes
Simplifies accounting and compliance

IMPLEMENTATION:
TrustSet with Flags: tfSetNoRipple
```


CHOOSE TRUST LINES IF:
□ Existing system uses trust lines
□ Need rippling functionality
□ Extreme value ranges required
□ Maximum compatibility important

CHOOSE MPTs IF:
□ Starting fresh
□ Multiple token types from same issuer
□ Per-token properties needed
□ Precision critical (fixed-point math)
□ Simpler model preferred

FOR MOST NEW RWA TOKENIZATION:
MPTs are likely better choice
But trust lines remain fully supported
Both achieve compliance goals
```



Create configuration guide for hypothetical tokenized asset including issuer settings, trust line parameters, and compliance workflow documentation.

Time investment: 2.5 hours


1. Fundamental difference between Ethereum and XRPL token holding?
Answer: B - XRPL requires explicit holder opt-in via trust line creation

2. Configuration for responding to court orders while maintaining holder trust?
Answer: B - Enable clawback, keep freeze capability, document clear policies

3. What does Alice actually have with 1000 TBILL tokens from an issuer?
Answer: B - A claim on the issuer for represented value, dependent on issuer reliability

4. Why set NoRipple flag for RWA tokenization?
Answer: B - Prevents trust line balances from changing unexpectedly due to payment routing

5. Will freeze capability hurt or help institutional adoption?
Answer: C - May reassure regulated institutions who want compliance capability


End of Lesson 7 - Beginning of Phase 2: XRPL's Tokenization Infrastructure

Key Takeaways

1

Trust lines are bilateral agreements

: Explicit opt-in from holders prevents spam and creates clear counterparty relationships.

2

Compliance features are native

: Authorized trust lines, freeze, clawback built into protocol—no smart contract needed.

3

Counterparty risk is explicit

: Trust line tokens are claims on issuers, not self-custodied assets.

4

NoRipple is essential for RWAs

: Prevents unexpected balance changes from payment routing.

5

Trust lines vs. MPTs

: Trust lines for existing integrations; MPTs often better for new RWA projects. ---