Interledger Protocol (ILP) and XRPL
Learning Objectives
Explain the Interledger Protocol architecture and how it differs from bridges and HTLCs
Analyze the relationship between ILP and XRPL, including historical context
Evaluate current ILP implementations and adoption status
Compare ILP's approach to other cross-chain solutions
Assess ILP's potential role in future payment infrastructure
When Ripple's founders envisioned "the Internet of Value," they imagined a world where money moves as easily as information. Just as the Internet Protocol (IP) enables data packets to flow across diverse networks, the Interledger Protocol was designed to enable value packets to flow across diverse payment systems.
The Analogy:
INTERNET (Data) INTERLEDGER (Value)
─────────────────────────────────────────────────────────────────
TCP/IP ILP
Routers Connectors
Packets Payment packets
Any network (WiFi, fiber, etc.) Any ledger (blockchain, bank, etc.)
End-to-end delivery End-to-end payment
Best-effort routing Best-price routingThis vision—payments flowing seamlessly across banks, blockchains, and payment networks—remains compelling. But the reality of ILP adoption has been more complex than the vision suggested.
ILP Stack:
INTERLEDGER PROTOCOL STACK
┌─────────────────────────────────────────────────────────────┐
│ APPLICATION LAYER │
│ SPSP (Simple Payment Setup Protocol) │
│ - Payment initiation │
│ - Invoice/payment request handling │
│ - Human-readable payment addresses │
└────────────────────────────┬────────────────────────────────┘
│
┌────────────────────────────┴────────────────────────────────┐
│ TRANSPORT LAYER │
│ STREAM Protocol │
│ - Chunked payments (packetization) │
│ - Bidirectional communication │
│ - Encryption and authentication │
│ - Congestion control │
└────────────────────────────┬────────────────────────────────┘
│
┌────────────────────────────┴────────────────────────────────┐
│ INTERLEDGER LAYER (ILPv4) │
│ - Packet format (ILP Prepare, Fulfill, Reject) │
│ - Addressing (ILP addresses) │
│ - Routing │
│ - Conditional transfers (HTLC-style) │
└────────────────────────────┬────────────────────────────────┘
│
┌────────────────────────────┴────────────────────────────────┐
│ LEDGER LAYER │
│ Ledger Plugins (adapters for each network) │
│ - XRPL plugin │
│ - Ethereum plugin │
│ - Bank ledger plugins │
│ - Any payment system │
└─────────────────────────────────────────────────────────────┘
Payment Flow:
ILP PAYMENT: ALICE (USD Bank) → BOB (EUR Bank)
Alice has: USD in US Bank
Bob wants: EUR in European Bank
Neither bank knows the other exists.
STEP 1: ROUTE DISCOVERY
┌─────────────────────────────────────────────────────────────┐
│ Alice's ILP node queries for route to Bob's ILP address │
│ Route found: US Bank → Connector A → XRPL → Connector B → │
│ EUR Bank │
│ Exchange rate quotes obtained at each hop │
└─────────────────────────────────────────────────────────────┘
STEP 2: PREPARE PHASE (Conditional holds)
┌─────────────────────────────────────────────────────────────┐
│ │
│ Alice Connector A XRPL Connector B Bob│
│ │ │ │ │ │ │
│ │──Prepare $10──►│ │ │ │ │
│ │ (condition) │──Prepare XRP─►│ │ │ │
│ │ │ (condition) │──Prepare €──►│ │ │
│ │ │ │ (condition) │──Prepare──►│
│ │ │ │ │ €8.50 │ │
│ │
│ Each hop creates conditional hold using same condition │
│ Funds locked but not yet transferred │
└─────────────────────────────────────────────────────────────┘
STEP 3: FULFILL PHASE (Release funds)
┌─────────────────────────────────────────────────────────────┐
│ │
│ Alice Connector A XRPL Connector B Bob│
│ │ │ │ │ │ │
│ │ │ │ │◄─Fulfill───│ │
│ │ │ │◄──Fulfill───│ │ │
│ │ │◄───Fulfill───│ │ │ │
│ │◄───Fulfill────│ │ │ │ │
│ │
│ Fulfillment (secret) flows backward │
│ Each hop releases funds upon receiving fulfillment │
│ Bob receives EUR, each connector earns spread │
└─────────────────────────────────────────────────────────────┘
RESULT:
Alice paid $10 USD from US bank account
Bob received €8.50 EUR in European bank account
XRPL was used as intermediate hop (neither party needed XRPL account)
ILP Addresses:
ILP ADDRESS STRUCTURE
Format: g.{network}.{account}
Examples:
├── g.us.bank.alice (Alice's bank account)
├── g.crypto.xrpl.rUserAddr (XRPL account)
├── g.eu.sepa.bob (Bob's SEPA account)
└── g.provider.service (Service endpoint)
Properties:
├── Hierarchical (like domain names)
├── Globally unique
├── Routable (connectors know how to reach prefixes)
└── Network-agnostic (same format regardless of underlying ledger)
Connectors:
ILP CONNECTORS
Role: Route payments between networks
─────────────────────────────────────────────────────────────────
Functions:
├── Receive ILP packets from one network
├── Forward to next hop toward destination
├── Provide exchange rate quotes
├── Handle conditional transfers on each side
├── Earn spread between buy/sell rates
Types:
├── Bank connectors (bridge fiat networks)
├── Crypto connectors (bridge blockchains)
├── Hybrid connectors (fiat ↔ crypto)
└── Internal connectors (within organization)
Economics:
├── Connectors earn spread on each transaction
├── Competition drives rates toward efficiency
├── No need for pre-funded corridors (vs. traditional FX)
└── Capital efficiency through XRP as bridge asset
Packetization:
ILP PACKETIZATION (STREAM Protocol)
Why Packetize?
├── Large payments split into small packets
├── Each packet is separate conditional transfer
├── Reduces risk (small packets = small risk per packet)
├── Enables congestion control
└── Allows partial completion (pay what gets through)
Packet Flow:
Payment: $1,000 → Split into 1,000 x $1 packets
Each packet:
├── Independent conditional transfer
├── Uses same ultimate condition
├── Can take different routes
├── Fail independently
└── Aggregate to complete payment
Benefits:
├── Connector risk limited to single packet value
├── Natural load balancing across routes
├── Graceful degradation on partial failure
├── Similar to TCP packet behavior
Origins:
ILP HISTORY
2015: Ripple publishes Interledger whitepaper
Stefan Thomas, Evan Schwartz lead design
Vision: Protocol for Internet of Value
2016: ILP v1 (Atomic mode) - Required universal connector trust
ILP v2 - More practical conditional transfers
Early implementations and experiments
2017: ILP v4 (Current) - Simplified, packet-based
STREAM protocol for transport layer
Focus on simplicity over features
2018-2020: W3C Web Payments interest
Coil founded (web monetization using ILP)
Mojaloop (Bill & Melinda Gates Foundation)
2021-2024: Continued development but limited adoption
Rafiki (open-source ILP infrastructure)
Integration with various platforms
The Bridge Currency Thesis:
XRP AS ILP BRIDGE CURRENCY
Original Vision:
┌─────────────────────────────────────────────────────────────┐
│ │
│ USD ──► XRP ──► EUR │
│ │
│ Instead of needing USD/EUR liquidity directly, │
│ use XRP as intermediate step: │
│ │
│ - USD/XRP market (liquid) │
│ - XRP/EUR market (liquid) │
│ - Any currency pair possible through XRP │
│ │
└─────────────────────────────────────────────────────────────┘
Benefits:
├── N currencies need only N markets (vs. N² for direct pairs)
├── XRP settlement is fast (3-5 seconds)
├── XRP transaction cost is low (<$0.01)
├── No pre-funded nostro accounts needed
└── Capital efficient (hold XRP, not multiple currencies)
This is the foundation of Ripple's ODL (On-Demand Liquidity):
├── ILP concepts applied to real corridors
├── XRP as actual bridge asset
├── Production usage by financial institutions
└── Billions in transaction volume
Technical Integration:
XRPL AS ILP LEDGER
XRPL supports ILP through:
├── Native conditional payments (Escrow with crypto-conditions)
├── Payment Channels (for high-frequency micropayments)
├── Fast finality (enables quick packet settlement)
└── Low fees (enables small packet economics)
Implementation Options:
XRPL ESCROW (for larger payments)
PAYMENT CHANNELS (for streaming)
DIRECT PAYMENTS (trusted paths)
Rafiki:
RAFIKI - OPEN SOURCE ILP INFRASTRUCTURE
What It Is:
├── Open-source ILP node implementation
├── Developed by Interledger Foundation
├── Reference implementation for connectors
└── Enables anyone to join ILP network
Components:
├── Backend (Node.js/TypeScript)
├── Admin interface
├── Account management
├── Peering (connector relationships)
└── Telemetry and monitoring
Status: Active development, production usage growing
GitHub: interledger/rafiki
Mojaloop:
MOJALOOP - FINANCIAL INCLUSION PLATFORM
What It Is:
├── Open-source instant payment platform
├── Funded by Bill & Melinda Gates Foundation
├── Uses ILP for interoperability
└── Deployed in multiple countries
Use Cases:
├── Mobile money interoperability
├── Central bank integration
├── Financial inclusion initiatives
└── Cross-border remittances
Deployments:
├── Tanzania (pilot)
├── Rwanda
├── Various other African nations
└── Southeast Asian implementations
Significance:
├── Largest real-world ILP deployment
├── Proves ILP works for financial inclusion
├── Shows ILP viability for fiat networks
└── Not crypto-focused but ILP-compatible
Coil/Web Monetization:
COIL - WEB MONETIZATION
What It Was:
├── ILP-based micropayment system for web
├── Pay content creators while browsing
├── Streaming payments (per-second)
└── Alternative to ads
Status: Coil service shut down (2023)
Web Monetization standard continues development
Legacy:
├── Proved streaming micropayments work
├── Web Monetization API in development
├── Inspired other web payment initiatives
└── ILP infrastructure remains usable
Honest Status:
ILP ADOPTION REALITY CHECK
WHERE ILP IS WORKING:
✓ Mojaloop (financial inclusion, Africa/Asia)
✓ Ripple's ODL (conceptually ILP-aligned, XRP bridge)
✓ Research and academic contexts
✓ Developer experimentation
WHERE ILP HASN'T GAINED TRACTION:
✗ General consumer payments
✗ Crypto-to-crypto transfers (bridges dominate)
✗ Bank-to-bank (SWIFT still dominant)
✗ Web monetization (Coil shut down)
REASONS FOR LIMITED ADOPTION:
├── Chicken-and-egg: Need connectors, but connectors need volume
├── Regulatory complexity (money transmission)
├── Existing infrastructure inertia
├── Bridges are simpler for crypto users
├── Traditional finance prefers known systems
└── Complex economics for connector profitability
CROSS-CHAIN SOLUTIONS COMPARISON
ILP Bridges HTLCs
─────────────────────────────────────────────────────────────────
Trust Model Connector risk Validator/ Trustless
(per-packet) custodian (crypto only)
Routing Multi-hop Direct Direct (p2p)
Assets Any value Wrapped tokens Native tokens
Speed Fast (streaming) Medium (5-15m) Slow (coord)
Scalability High (packets) Medium Low
Complexity Medium-High Low (user) High
Adoption Limited High Very low
Use Cases Payments, DeFi, Large swaps,
micropayments cross-chain trustless needs
XRPL Integration Native support Via Axelar, Via Escrow
sidechain
```
ILP USE CASES
IDEAL FOR:
├── Micropayments (sub-cent, streaming)
├── Cross-network payments (fiat + crypto)
├── Financial inclusion infrastructure
├── Payment channel networks
├── Web monetization applications
└── High-volume, low-value transfers
NOT IDEAL FOR:
├── Simple crypto-to-crypto swaps (bridges easier)
├── Large single transfers (HTLC or bridge better)
├── Where no connectors exist
├── Situations requiring guaranteed delivery
└── Users who want simple interfaces
```
WHAT ILP OFFERS THAT OTHERS DON'T
- NETWORK AGNOSTICISM
- STREAMING PAYMENTS
- ROUTING EFFICIENCY
- SCALABILITY
- FUTURE COMPATIBILITY
// ilp-sender.js - Basic ILP payment using ilp-protocol-stream
const { createConnection } = require('ilp-protocol-stream');
const { createPlugin } = require('ilp-plugin');
async function sendPayment() {
// Create plugin (connects to ILP network)
const plugin = createPlugin();
// Connect to the network
await plugin.connect();
// Recipient's payment pointer (SPSP address)
const destinationAddress = '$wallet.example.com/bob';
// Create STREAM connection
const connection = await createConnection({
plugin,
destinationAccount: destinationAddress,
// Would normally resolve via SPSP
});
// Create a stream for sending
const stream = connection.createStream();
// Send money (amount in smallest unit)
stream.setSendMax(1000000); // 1 unit (varies by asset)
// Wait for completion
await new Promise((resolve) => {
stream.on('outgoing_money', (amount) => {
console.log(Sent: ${amount});
});
stream.on('end', resolve);
});
// Clean up
await connection.end();
await plugin.disconnect();
console.log('Payment complete!');
}
```
// Simple connector configuration using Rafiki concepts
const connectorConfig = {
// Connector identity
ilpAddress: 'g.example.connector1',
// Peering relationships
peers: [
{
id: 'upstream-connector',
ilpAddress: 'g.upstream',
relation: 'parent',
assetCode: 'XRP',
assetScale: 6,
// Connection details
endpoint: 'https://upstream.example.com/ilp" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://upstream.example.com/ilp">https://upstream.example.com/ilp ',
// Settlement config
settlement: {
type: 'xrpl',
address: 'rUpstreamAddress...'
}
},
{
id: 'peer-connector',
ilpAddress: 'g.peer',
relation: 'peer',
assetCode: 'USD',
assetScale: 2,
endpoint: 'https://peer.example.com/ilp" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://peer.example.com/ilp">https://peer.example.com/ilp ',
settlement: {
type: 'bank',
// Bank settlement details
}
}
],
// Routing configuration
routing: {
// Advertise routes we can reach
broadcast: true,
// Accept routes from peers
receive: true
},
// Rate/spread configuration
spread: 0.001, // 0.1% spread on exchanges
// Risk limits
limits: {
maxPacketAmount: 1000000,
maxBalance: 100000000
}
};
```
// payment-channel-ilp.js
const xrpl = require('xrpl');
class XRPLPaymentChannel {
constructor(client, wallet) {
this.client = client;
this.wallet = wallet;
}
/**
- Create a payment channel for ILP settlement
*/
async createChannel(destination, amountXrp, settleDelay = 3600) {
const channelCreate = {
TransactionType: 'PaymentChannelCreate',
Account: this.wallet.address,
Amount: xrpl.xrpToDrops(amountXrp),
Destination: destination,
SettleDelay: settleDelay,
PublicKey: this.wallet.publicKey
};
const prepared = await this.client.autofill(channelCreate);
const signed = this.wallet.sign(prepared);
const result = await this.client.submitAndWait(signed.tx_blob);
// Get channel ID from result
const channelId = result.result.meta.AffectedNodes
.find(n => n.CreatedNode?.LedgerEntryType === 'PayChannel')
?.CreatedNode?.LedgerIndex;
return {
channelId,
amount: amountXrp,
destination,
txHash: result.result.hash
};
}
/**
- Create a claim for off-ledger payment
- Used for ILP packet settlement
*/
createClaim(channelId, amountDrops) {
const claimData = Buffer.concat([
Buffer.from('CLM\0'),
Buffer.from(channelId, 'hex'),
Buffer.alloc(8)
]);
// Write amount as 64-bit big-endian
const amountBuf = Buffer.alloc(8);
amountBuf.writeBigUInt64BE(BigInt(amountDrops));
claimData.set(amountBuf, claimData.length - 8);
// Sign the claim
const signature = xrpl.sign(claimData, this.wallet.privateKey);
return {
channelId,
amount: amountDrops,
signature
};
}
/**
- Submit a claim to close/claim the channel
*/
async submitClaim(channelId, amountDrops, signature) {
const channelClaim = {
TransactionType: 'PaymentChannelClaim',
Account: this.wallet.address,
Channel: channelId,
Balance: amountDrops.toString(),
Signature: signature,
PublicKey: this.wallet.publicKey
};
const prepared = await this.client.autofill(channelClaim);
const signed = this.wallet.sign(prepared);
return await this.client.submitAndWait(signed.tx_blob);
}
}
// Usage for ILP:
// 1. Open channels with frequent ILP peers
// 2. Send ILP packets off-ledger with signed claims
// 3. Periodically settle claims on-ledger
// 4. Much higher throughput than on-ledger settlements
```
ILP FUTURE SCENARIOS
SCENARIO A: Financial Inclusion Success (30% probability)
├── Mojaloop expands to more countries
├── Central banks adopt ILP for interoperability
├── Becomes standard for emerging market payments
├── XRP as bridge currency in these networks
└── Significant volume but not crypto-focused
SCENARIO B: Crypto Integration Revival (20% probability)
├── Cross-chain protocols rediscover ILP concepts
├── Streaming payments gain traction (gaming, AI services)
├── ILP becomes layer under other protocols
└── Technical concepts survive, brand may not
SCENARIO C: Continued Niche Usage (40% probability)
├── Rafiki community maintains development
├── Specific use cases (micropayments, inclusion)
├── Never achieves mainstream adoption
├── Alternative approaches dominate
SCENARIO D: Protocol Obsolescence (10% probability)
├── Better alternatives emerge
├── Development slows
├── Deployments migrate away
└── Historical footnote
```
ILP AND XRPL FUTURE
STRATEGIC ALIGNMENT:
├── ILP concepts underpin ODL
├── XRP bridge currency thesis
├── Payment optimization focus
├── Financial institution relationships
POTENTIAL SYNERGIES:
├── ILP + EVM Sidechain (streaming payments in DeFi)
├── ILP + Axelar (routing optimization)
├── ILP + CBDCs (central bank interoperability)
└── ILP + Hooks (programmable routing)
INVESTMENT IMPLICATIONS:
├── ILP success validates XRP bridge thesis
├── But ILP adoption not necessary for XRP success
├── ODL can succeed without broader ILP adoption
├── Watch Mojaloop as indicator
└── Monitor Rafiki development activity
```
ILP is a technically elegant protocol that solves real problems—particularly in financial inclusion and micropayments. However, its adoption has been limited, and simpler solutions (bridges, direct transfers) dominate the crypto cross-chain landscape. ILP's concepts influence Ripple's products (ODL) even if the protocol itself isn't widely used. For investors, ILP success would be a positive signal for the XRP bridge currency thesis, but XRP's value doesn't depend on ILP becoming the universal payment protocol. Watch for Mojaloop expansion and Rafiki adoption as practical indicators.
Assignment: Evaluate ILP for a specific cross-network payment use case.
Requirements:
Remittance corridor (specific countries)
Web micropayments (streaming content)
Gaming payments (in-game purchases)
IoT micropayments (pay-per-use)
B2B cross-border payments
Map required ILP components (plugins, connectors)
Identify settlement mechanisms needed
Design packet flow for typical transaction
Specify XRPL integration points
Model connector economics (spreads, volumes)
Calculate end-user costs vs. alternatives
Assess capital requirements for connectors
Compare to bridge/traditional alternatives
Identify existing ILP infrastructure that could be leveraged
Assess regulatory requirements
Evaluate competitive solutions
Identify key success factors
Go/no-go recommendation with rationale
If go: Implementation roadmap
If no-go: What would need to change
Risk assessment
Use case clarity (15%)
Technical depth (25%)
Economic realism (25%)
Competitive analysis (20%)
Recommendation quality (15%)
Time investment: 5-7 hours
Value: Understanding ILP's practical applicability.
Knowledge Check
Question 1 of 5(Tests Knowledge):
- Interledger RFCs: https://interledger.org/rfcs
- ILPv4 Specification
- STREAM Protocol
- Rafiki: https://github.com/interledger/rafiki
- Mojaloop: https://mojaloop.io/
- ILP Developer Tools
- Original Interledger whitepaper (Stefan Thomas)
- Ripple ILP announcements
- Coil post-mortems
- XRPL Payment Channels documentation
- XRPL Escrow crypto-conditions
- XRP as bridge currency analyses
For Next Lesson:
Prepare for Lesson 14 on XRPL Hooks for Cross-Chain Logic, where we'll explore how Hooks can enable sophisticated interoperability at the XRPL protocol level.
End of Lesson 13
Total words: ~5,900
Estimated completion time: 50 minutes reading + 5-7 hours for deliverable
Key Takeaways
ILP is a protocol layer, not a bridge:
It enables routing payments across networks without necessarily wrapping assets. Think TCP/IP for money, not a specific bridge product.
XRP as bridge currency fits ILP vision:
ILP was designed with bridge currencies in mind. XRP's speed and cost make it ideal, and this thesis underlies ODL.
Adoption is limited but real:
Mojaloop deployments prove ILP works. But crypto users prefer bridges, and traditional finance prefers existing systems.
Streaming micropayments are unique:
ILP enables per-second payments—something bridges and HTLCs can't easily replicate. This has applications in web monetization, gaming, and AI services.
ILP success ≠ XRP success:
They're aligned but not dependent. XRP can succeed through ODL and other mechanisms even if ILP doesn't achieve universal adoption. ---