Interledger Protocol (ILP)

What Is the Interledger Protocol?

The Interledger Protocol (ILP) is an open protocol for sending payments across different payment networks and ledgers. Just as the Internet Protocol (IP) routes data packets between networks regardless of their underlying technology, ILP routes value packets between financial systems regardless of whether those systems are banks, blockchain networks, mobile money platforms, or digital wallets.

ILP is not a blockchain, a token, or a payment network itself. It is a protocol layer that sits above individual payment rails and enables them to interoperate. A sender on one network can pay a receiver on a completely different network, with connectors in between handling the currency conversion and routing. The protocol uses conditional transfers secured by cryptographic conditions to ensure that payments either complete fully or fail without any party losing funds.

Stefan Thomas and Evan Schwartz created ILP at Ripple Labs in 2015. Since 2019, the independent Interledger Foundation has maintained and governed the protocol. The current version, ILPv4, is optimized for high-throughput routing of small-value packets: an approach the designers call "penny switching."

How It Works

ILP uses a layered architecture inspired by the internet protocol stack. Each layer handles a specific responsibility, and together they enable end-to-end value transfer across heterogeneous networks.

The Four-Layer Stack

The ILP architecture consists of four layers:

1. Application layer (Open Payments, SPSP): defines how senders and receivers exchange the information needed to initiate a payment, such as the receiver's ILP address and a shared secret
2. Transport layer (STREAM): breaks a payment into many small ILP packets, manages delivery, and handles quoting and streaming payments
3. Interledger layer (ILPv4): routes individual packets hop-by-hop through connectors from sender to receiver
4. Link layer (ILP-over-HTTP): defines how adjacent nodes communicate and settle bilateral balances

ILP Packets

ILPv4 defines three packet types that form a request-response cycle, similar to how HTLCs work in payment channel networks:

• Prepare: the request packet containing the destination ILP address, amount, an execution condition (SHA-256 hash), an expiry timestamp, and optional application data. Connectors forward this packet hop-by-hop toward the receiver.
• Fulfill: the success response containing a 32-byte preimage that satisfies the SHA-256 condition. This travels back along the exact same path, and each connector along the route settles its leg of the transfer.
• Reject: the error response returned when a payment cannot complete due to expired timeouts, insufficient liquidity, or routing failures.

# Simplified ILP packet flow
Sender → [Prepare] → Connector A → [Prepare] → Connector B → [Prepare] → Receiver
Sender ← [Fulfill] ← Connector A ← [Fulfill] ← Connector B ← [Fulfill] ← Receiver

# ILP address format (hierarchical, like IP)
g.us-bank.alice
g.eu-wallet.connector1.bob

Connectors

Connectors are the routing nodes of the Interledger network. Each connector maintains direct peering relationships with other nodes and forwards ILP packets between them. Key responsibilities include:

• Currency conversion: each peering relationship operates in a single currency, so a connector bridging two peers with different currencies performs the exchange
• Risk management: connectors maintain bilateral balances with each peer and enforce credit limits to cap exposure
• Route propagation: connectors exchange routing information using the Connector-to-Connector Protocol (CCP), similar to how internet routers share BGP tables

Because ILP splits payments into many small packets, the risk at any single hop is minimal. If a connector fails to forward a Fulfill packet, the sender loses only the value of that one small packet, not the entire payment.

STREAM Protocol

STREAM (Streaming Transport for the Real-time Exchange of Assets and Messages) is the transport layer that makes ILP practical for real payments. Rather than sending a single large packet, STREAM breaks a payment into many small ILP packets and sends them in bulk. This provides:

• Rate discovery: STREAM probes the path to determine the current exchange rate
• Chunked delivery: large payments arrive as many small, low-risk transfers
• Streaming payments: continuous flows of value, useful for payment streaming and micropayments
• End-to-end encryption: application data within packets is encrypted between endpoints

Settlement

ILP deliberately separates clearing from settlement. The ILP packet flow functions as clearing: it tracks who owes whom. Settlement happens outside the protocol entirely, on whatever system the two peers agree to use. This could be a payment channel, a bank transfer, a blockchain transaction, or even physical cash. This separation is what allows ILP to connect fundamentally different financial systems without requiring them to share infrastructure.

ILP vs. Other Cross-Network Approaches

Several technologies address the problem of moving value across network boundaries. ILP takes a distinct approach compared to each.

ILP vs. Atomic Swaps

Atomic swaps use hash-time-locked contracts to exchange assets directly between two parties on different blockchains. Both sides lock funds, and revealing a shared secret completes both legs simultaneously. ILP takes a different approach: instead of locking large amounts atomically, it routes many small packets through a chain of connectors. This reduces per-packet risk and supports multi-hop, multi-currency paths that atomic swaps cannot handle natively.

ILP vs. Lightning Network

The Lightning Network routes payments through payment channels backed by on-chain Bitcoin transactions. It uses HTLCs for trustless multi-hop routing within a single asset (bitcoin). ILP uses connectors with bilateral credit rather than payment channels, supports any currency or asset type, and settles on any underlying system. Lightning prioritizes trustless, decentralized Bitcoin payments. ILP prioritizes connecting diverse financial systems regardless of their trust model.

ILP vs. Cross-Chain Bridges

Cross-chain bridges move tokenized assets between specific blockchain networks, typically requiring custom smart contracts on each chain. ILP is a universal routing protocol that connects not just blockchains but also banks, mobile money platforms, and traditional payment rails. Bridges transfer assets between two specific networks. ILP routes value across an open graph of any connected network.

Use Cases

Cross-Border Payments

Traditional cross-border payments rely on chains of correspondent banks, each adding fees, delays, and settlement risk. ILP can connect the sender's domestic payment system to the receiver's domestic system through one or more connectors, reducing intermediaries and enabling near-instant settlement. The Interledger Foundation has funded cross-border payment projects in over 40 countries, including remittance corridors in Latin America and financial inclusion initiatives in Africa.

Web Monetization

Web Monetization is a proposed W3C standard built on ILP that enables real-time micropayments to web creators. Instead of relying on advertising or subscriptions, a browser extension streams tiny payments to websites as users browse. STREAM makes this feasible by sending sub-cent payments continuously without per-transaction overhead.

Open Payments

Open Payments is a standard built on ILP and the GNAP authorization framework. It allows third-party applications to initiate payments and access transaction data from a user's wallet with their consent. Payment service providers that implement Open Payments can interoperate without direct integrations, creating an open ecosystem similar to what open banking aims to achieve but across all types of payment systems. For a deeper look at how Open Payments works, see the Open Payments and Interledger research article.

Financial Inclusion

ILP can bridge mobile money systems, credit union ledgers, and digital wallets that otherwise have no way to interoperate. Projects like the People's Clearinghouse in Mexico use ILP to connect rural credit unions to the broader financial system, enabling members to send and receive payments without requiring integration with centralized banking infrastructure.

Key Implementations

Rafiki

Rafiki is the open-source reference implementation of the ILP stack. It provides account servicing entities (banks, wallets, mobile money operators) with a complete Interledger node, including an ILP connector, Open Payments API, authorization server, and integration with TigerBeetle for high-throughput accounting. Rafiki is the recommended starting point for any organization looking to join the Interledger network.

Payment Pointers and Wallet Addresses

ILP uses human-readable identifiers for receiving payments. Originally called Payment Pointers (e.g., $wallet.example.com/alice), these are now referred to as wallet addresses in the Open Payments standard. They resolve to HTTPS endpoints that provide the ILP address and shared secret needed to initiate a STREAM connection, similar to how domain names resolve to IP addresses.

Risks and Considerations

Connector Trust

Unlike trustless systems such as the Lightning Network, ILP connectors operate on bilateral credit. Each connector trusts its peers up to a configured credit limit. If a connector is malicious or goes offline, it could fail to forward Fulfill packets, causing the sender to lose the value of in-flight packets. The penny-switching model mitigates this by keeping individual packet values small, but it does not eliminate the trust requirement entirely.

Limited Adoption

Despite being available since 2015, ILP has seen relatively modest adoption compared to blockchain-native solutions. The shutdown of Coil in March 2023, which was the most visible consumer-facing ILP application, reduced the protocol's public profile. Current adoption centers on development-stage projects, financial inclusion initiatives, and the Interledger Foundation's grant recipients rather than large-scale production deployments.

Settlement Dependency

ILP handles clearing but leaves settlement to external systems. This means the protocol's guarantees depend entirely on the settlement mechanisms chosen by each pair of peers. If settlement fails or is delayed, connectors accumulate risk. The protocol does not enforce settlement frequency or method, so participants must carefully manage their bilateral relationships.

No Native Asset or Incentive Layer

ILP has no native token or built-in economic incentive for running connectors. Connectors earn revenue from the spread between buy and sell rates on currency conversions, but there is no protocol-level fee market or staking mechanism. This keeps the protocol simple but means connector operation depends on external business models.

Why It Matters

The global payments landscape remains fragmented across hundreds of incompatible networks: SWIFT, ACH, SEPA, mobile money systems, blockchain networks, and proprietary wallet platforms. ILP offers a protocol-level solution to interoperability that does not require all participants to adopt a single ledger or trust a central operator. For projects building cross-network payment infrastructure, including Bitcoin Layer 2 solutions like Spark that aim to bridge value across different systems, ILP's design principles of ledger-agnostic routing and packet-based value transfer provide a useful reference architecture. To explore how modern payment systems are converging across rails, see the research on payment network interoperability standards.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.