Interledger Protocol (ILP) and XRPL | XRPL Interoperability | XRP Academy - XRP Academy
3 free lessons remaining this month

Free preview access resets monthly

Upgrade for Unlimited
Skip to main content
advanced50 min

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 routing

This 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:

  1. XRPL ESCROW (for larger payments)

  2. PAYMENT CHANNELS (for streaming)

  3. 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
  1. NETWORK AGNOSTICISM
  1. STREAMING PAYMENTS
  1. ROUTING EFFICIENCY
  1. SCALABILITY
  1. 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):

  • 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

1

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.

2

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.

3

Adoption is limited but real:

Mojaloop deployments prove ILP works. But crypto users prefer bridges, and traditional finance prefers existing systems.

4

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.

5

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. ---