Multi-Purpose Tokens (MPTs) - The New Standard
Learning Objectives
Explain the MPT architecture and how it differs from trust lines
Configure MPT properties at issuance and holder levels
Evaluate the advantages of MPTs for RWA tokenization
Determine when to use MPTs versus trust lines
Assess MPT adoption status and ecosystem readiness
Trust lines have worked well for 13+ years, but they were designed for a different era—primarily for cross-currency payments and market making. As tokenization of real-world assets became a focus, several pain points emerged:
TRUST LINE LIMITATIONS FOR RWA:
1. Account-Level Properties:
1. Rippling Complexity:
1. Floating-Point Representation:
1. Mental Model:
MPTs address these limitations while maintaining XRPL's native compliance capabilities.
---
MPT STRUCTURE:
- Unique MPTokenIssuanceID
- Asset-specific metadata
- Issuance-level properties
- Maximum amount cap
- Reference to MPTokenIssuanceID
- Holder's balance
- Holder-specific properties
- Locked amount (if applicable)
KEY DIFFERENCE FROM TRUST LINES:
Trust Line: Bilateral relationship between issuer and holder
MPT: Issuer creates issuance, holders receive tokens against it
ISSUANCE-LEVEL SETTINGS:
- Hard cap on total supply
- Fixed at creation
- Cannot be increased
- Percentage fee on transfers
- Paid to issuer
- Enables revenue model
- Decimal places for token
- Fixed at creation
- Determines precision
- Asset description
- External URI
- Compliance information
HOLDER-LEVEL SETTINGS:
- Current balance
- Fixed-point representation
- No rounding surprises
- Portion that cannot be transferred
- Vesting schedules
- Collateral locks
- Frozen status
- Authorization status
REPRESENTATION COMPARISON:
- Can represent very large/small values
- Potential rounding in calculations
- Example: 0.1 + 0.2 might not exactly equal 0.3
- Precise decimal representation
- No rounding surprises
- Better for financial calculations
- But: More limited range
- Most RWA use cases work fine with either
- Fixed-point preferred for regulatory reporting
- Financial institutions may prefer MPT precision
---
MPT COMPLIANCE FLAGS:
- Issuer can lock tokens in holder accounts
- Vesting schedules
- Collateral management
- Cannot transfer locked portions
- Same as trust line RequireAuth
- Issuer must authorize each holder
- KYC/AML enforcement
- Tokens can be placed in escrow
- Time-locked transfers
- Conditional delivery
- Whether token can be traded on DEX
- Can restrict to P2P only
- Compliance control
- Whether holder-to-holder transfers allowed
- Can restrict to redemption only
- Issuer can retrieve tokens
- Same as trust line clawback
- Must enable at creation
MPT FREEZE MECHANISM:
- Freeze specific holder's MPTs
- Same effect as trust line freeze
- Holder can only send to issuer
- MPTs don't have global freeze currently
- Must freeze individually
- Or disable transfers at issuance level
MPT AUTHORIZATION:
1. Issuer creates MPTokenIssuance with lsfMPTRequireAuth
2. Holder creates empty MPToken position
3. Issuer verifies holder (off-chain KYC)
4. Issuer authorizes holder's MPToken
5. Holder can now receive tokens
SAME COMPLIANCE OUTCOME AS TRUST LINES
Different implementation, same security model
SCENARIO: ISSUER WITH MULTIPLE FUNDS
- Single issuer account
- ALL tokens have same RequireAuth setting
- ALL tokens have same freeze capability
- Workaround: Multiple issuer accounts (complex)
- Single issuer account
- Fund A: RequireAuth, Clawback enabled
- Fund B: No auth required, no clawback
- Fund C: Different transfer restrictions
- Each issuance independent
MPT CONCEPTUAL MODEL:
"Issuer creates a tokenized asset class"
"Holders receive units of that asset"
"Properties defined per asset, not per relationship"
vs. Trust Lines:
"Holder agrees to trust issuer"
"Balance represents mutual relationship"
"Rippling connects multiple relationships"
FOR INSTITUTIONS:
MPT model more intuitive
"Token" vs. "Trust Line"
Easier to explain to compliance/legal
RIPPLING ELIMINATION:
- Must configure NoRipple properly
- Unexpected balance changes possible
- Complex payment path routing
- No rippling concept
- Balances change only via explicit transactions
- Simpler accounting
- No unexpected position changes
---
USE TRUST LINES WHEN:
1. EXISTING INTEGRATION:
1. RIPPLING NEEDED:
1. EXTREME VALUES:
1. MAXIMUM COMPATIBILITY:
USE MPTs WHEN:
1. NEW PROJECT:
1. MULTIPLE TOKEN TYPES:
1. PRECISION MATTERS:
1. INSTITUTIONAL PREFERENCE:
1. LOCK FUNCTIONALITY:
TOKEN STANDARD DECISION:
Trust Lines MPTs
Existing integration ✓ Better
Rippling needed ✓ Required ✗ Not available
Multiple token types ✓ Better
Per-token properties ✓ Better
Fixed-point precision ✓ Better
Maximum compatibility ✓ Better
Lock functionality ✓ Available
New RWA project ✓ Recommended
MPT AMENDMENT STATUS (December 2025):
- Status: ACTIVATED
- Enables basic MPT functionality
- Create, transfer, configure
- AMM integration for MPTs
- DEX order book improvements
- Wallet support expansion
- Documentation maturation
ECOSYSTEM SUPPORT:
- xrpl.js library
- XRPL node software
- Core protocol operations
- Wallet interfaces
- Block explorers
- Development tools
- Documentation
- AMM liquidity pools
- Advanced DEX features
- Cross-MPT operations
MPT ADOPTION STATUS:
- MPTs are production-ready
- Core functionality works
- Use for new tokenization
- Trust lines still fully supported
- No migration pressure
- Can evaluate MPTs for new tokens
RECOMMENDATION:
New RWA tokenization → Consider MPTs first
Existing trust line tokens → Keep unless compelling reason
// MPTokenIssuanceCreate Transaction
{
"TransactionType": "MPTokenIssuanceCreate",
"Account": "rIssuer...",
"AssetScale": 2, // 2 decimal places
"MaximumAmount": "1000000000", // 1 billion max
"TransferFee": 100, // 0.1% transfer fee
"Flags": {
"tfMPTCanLock": true,
"tfMPTRequireAuth": true,
"tfMPTCanClawback": true,
"tfMPTCanTransfer": true,
"tfMPTCanTrade": true
},
"MPTokenMetadata": "7B226E616D65223A2254424..." // JSON metadata in hex
}
```
// Step 1: Holder creates MPToken position
{
"TransactionType": "MPTokenAuthorize",
"Account": "rHolder...",
"MPTokenIssuanceID": "000000ABC123..."
}
// Step 2: Issuer authorizes (if RequireAuth)
{
"TransactionType": "MPTokenAuthorize",
"Account": "rIssuer...",
"MPTokenIssuanceID": "000000ABC123...",
"MPTokenHolder": "rHolder..."
}
// Step 3: Issuer sends tokens
{
"TransactionType": "Payment",
"Account": "rIssuer...",
"Destination": "rHolder...",
"Amount": {
"mpt_issuance_id": "000000ABC123...",
"value": "1000"
}
}
```
MPTs represent a genuine improvement for RWA tokenization with per-issuance properties, fixed-point precision, and simpler mental model. For new projects, MPTs are the recommended choice. For existing trust line projects, there's no pressure to migrate—both standards coexist and both work well.
Create decision matrix comparing trust lines vs. MPTs for 3 hypothetical tokenization scenarios, with detailed justification for each choice.
Time investment: 1.5 hours
1. What is the primary architectural difference between trust lines and MPTs?
Answer: B - Trust lines are bilateral issuer-holder relationships; MPTs are issuer-created assets that holders receive tokens against
2. An issuer wants different compliance settings for different token types. Which is better?
Answer: B - MPTs (per-issuance properties allow different settings per token type)
3. Why might fixed-point representation matter for institutional adoption?
Answer: C - Eliminates potential rounding issues in financial calculations and regulatory reporting
4. Should an existing trust line token project migrate to MPTs?
Answer: C - No pressure to migrate; both standards coexist; evaluate for new tokens only
5. What's the current status of MPT ecosystem support?
Answer: B - Core functionality live; tooling support expanding but verify specific tool support before assuming availability
End of Lesson 8
Key Takeaways
MPTs are designed for RWAs
: Per-issuance properties, fixed-point precision, and lock functionality address trust line limitations for tokenization.
Same compliance capabilities
: Authorized holders, freeze, and clawback work similarly to trust lines—no compliance compromise.
No rippling complexity
: MPTs don't have rippling, eliminating unexpected balance changes and simplifying accounting.
Ecosystem maturing
: Core functionality is live; tooling support is expanding but not yet universal.
Decision framework
: New projects → MPTs recommended; existing trust lines → keep unless compelling reason to migrate. ---