Interledger Protocol: Open Standards for Cross-Network Payment Routing

Moving money between two banks is straightforward. Moving money between a bank account, a mobile money wallet, and a blockchain is not. Each network speaks a different language, settles on a different timeline, and trusts a different set of intermediaries. The Interledger Protocol (ILP) was designed to solve exactly this: a packet-based routing protocol that moves value across any combination of ledgers without requiring them to share infrastructure, trust models, or even asset types.

Originally published in 2015 by Stefan Thomas and Evan Schwartz while at Ripple, ILP has evolved into an open standard maintained by the Interledger Foundation, a nonprofit backed by over $100 million in grant funding. The protocol is now in its fourth major version (ILPv4) and underpins projects ranging from mobile money interoperability in Africa to a proposed W3C web standard for content monetization.

How ILP Routes Payments Across Networks

ILP borrows its core architecture from the internet itself. Just as TCP/IP routes data packets between networks without requiring every router to understand every application, ILP routes payment packets between ledgers without requiring every connector to interface with every settlement system. The protocol stack has five layers, modeled on RFC 1122.

This layered design means that adding a new payment rail to the ILP network requires only a settlement engine adapter at the bottom layer. The routing, transport, and application layers remain unchanged.

Payment Packets

ILPv4 defines three packet types, all encoded using ASN.1 Canonical Octet Encoding. An ILP Prepare packet contains an amount (unsigned 64-bit integer), an expiration timestamp, a 32-byte SHA-256 execution condition, a destination address, and end-to-end encrypted data. Critically, Prepare packets carry no source address: each hop identifies the sender from the authenticated bilateral channel, which limits information leakage across the network.

Payments flow in two phases. The Prepare packet travels forward from sender through connectors to the receiver. Each connector adjusts the amount (applying exchange rates and fees) and shortens the expiry, but must not modify the condition, destination, or encrypted data. When the receiver validates the packet, it returns an ILP Fulfill packet containing the 32-byte preimage of the condition. This flows backward through the connector chain, triggering sequential balance credits at each hop. If anything fails, an ILP Reject packet propagates backward instead, and no balances change.

Inspired by Lightning: ILP's conditional transfer mechanism uses the same cryptographic primitive as HTLCs on the Lightning Network: SHA-256 hash conditions with preimage fulfillments. The key difference is that ILP applies this pattern across heterogeneous networks rather than within a single blockchain's payment channel network.

Connectors and Routing

Connectors are the routers of the ILP network. Each connector maintains bilateral accounts with its peers and a routing table mapping ILP address prefixes to those peers. Routing uses longest-prefix matching, exactly like IP routing. The Connector-to-Connector Protocol (CCP) handles route broadcasting and discovery between peers.

ILP addresses are hierarchical, dot-separated strings following an allocation scheme. Production addresses use the g. prefix (global), while test networks use test. and private subnets use private.. A typical production address looks like g.us.acmebank.acmecorp.sales.199. Child nodes receive their addresses dynamically from parent connectors via the Interledger Dynamic Configuration Protocol (ILDCP).

Connectors take on delivery-window risk: they incur outgoing obligations before receiving confirmation of incoming obligations. This risk is mitigated by keeping individual packet amounts small, setting tight expiry windows, and maintaining bilateral credit limits. If a connector's peer exceeds its configured maximum balance, the connector rejects further packets with a T04 (Insufficient Liquidity) error until the peer settles.

The STREAM Transport Protocol

STREAM (Streaming Transport for the Real-time Exchange of Assets and Messages) sits at the transport layer and handles the mechanics that senders and receivers care about most: breaking large payments into many small ILP packets, encrypting end-to-end data, managing exchange rate discovery, and multiplexing multiple concurrent streams over a single connection.

All STREAM data is encrypted with AES-256-GCM using a key derived from a shared secret via HMAC-SHA256. Fulfillment generation is deterministic: both sender and receiver can independently compute the correct preimage from the shared secret and the encrypted packet data, eliminating the need for out-of-band coordination during the payment flow.

STREAM connections support bidirectional money and data transfers through multiplexed streams. Client-initiated streams use odd identifiers (1, 3, 5) while server-initiated streams use even identifiers (2, 4, 6), with a default maximum of ten concurrent streams per endpoint. This design enables use cases like payment streaming, where continuous micropayments flow in real time as a service is consumed.

Settlement Without Bridges

One of ILP's most important design decisions is how it handles settlement. Unlike cross-chain bridges that lock assets on one chain and mint wrapped tokens on another, ILP connectors settle bilaterally with their direct peers using whatever mechanism both parties agree on. There are no wrapped tokens, no shared smart contracts, and no multi-signature validator committees.

Settlement engines are modular adapters that execute actual value transfers on underlying networks. A connector settling with a bank might use ACH or SWIFT. A connector settling with a crypto exchange might use on-chain Bitcoin transactions or Lightning payments. As bilateral obligations accumulate from packet flows, each connector configures a settlement threshold that triggers actual settlement when reached.

This bilateral model eliminates the single points of failure that have plagued blockchain bridges. The history of bridge exploits demonstrates the fragility of shared custody models. With ILP, each party trusts only its direct peers, and settlement for one account cannot depend on the status of any other account, preventing cascading failures.

Open Payments: The Application Layer

While ILP handles routing and STREAM handles transport, applications need a way to discover wallets, negotiate amounts, and authorize payments. Open Payments is the HTTP-based API standard that fills this role, replacing the earlier Simple Payment Setup Protocol (SPSP) with a full-featured authorization and payment initiation framework.

Open Payments introduces wallet addresses: public, URL-based account identifiers (like https://wallet.example/alice) that serve as payment endpoints without exposing sensitive account details. The API supports grants (delegated access to accounts), quotes (exchange rate and fee discovery), and both incoming and outgoing payment resources. Applications interact with these resources via standard REST calls, making integration familiar to any web developer.

The standard reached API version 1.3.0 in May 2026 with support for directed identity (creating non-interactive grants via JWK without wallet addresses) and encrypted data exchange. The Interledger Foundation maintains SDKs in JavaScript and Go, with a 2026 Accelerator Program funding additional language implementations.

Design principle: Open Payments treats sending a payment like sending an email. The sender needs only the recipient's wallet address, just as email requires only an address. The underlying infrastructure handles routing, currency conversion, and settlement without either party needing to know what systems the other uses.

Comparing Cross-Network Payment Approaches

ILP is not the only protocol attempting to solve cross-network payment interoperability. Several alternatives exist, each with different design philosophies and tradeoffs.

Circle's CCTP solves a narrower problem with high efficiency: moving USDC between blockchains without wrapped tokens. CCTP V2, launched in March 2025, supports fast finality across 13+ EVM chains and Solana. But it handles only one asset on one type of network. ILP handles any asset across any network type, at the cost of requiring a connector infrastructure that does not yet exist at scale.

Atomic swaps share ILP's hash-timelock heritage and achieve true trustlessness, but they require both parties to be online, both assets to support hashlocks, and typically involve on-chain transactions on both sides. ILP trades some trustlessness (you trust your direct connector peers) for dramatically broader reach and lower latency.

ILP and ISO 20022 Alignment

The question of how blockchain-native protocols interact with traditional financial messaging standards is increasingly important. ILP has taken concrete steps toward ISO 20022 alignment. The Mojaloop Foundation submitted a change request to integrate ILP data elements into the ISO 20022 standard, which was formally approved by the standard's governing body. This means ILP payment data can be represented within ISO 20022 message formats, enabling interoperability with the global financial messaging infrastructure that SWIFT and major banks are migrating to.

The two standards operate at different layers. ISO 20022 defines what data accompanies a payment (structured message formats for beneficiary information, travel rule compliance data, remittance details). ILP defines how to route and settle the payment across networks. Combined, they offer a path where a payment initiated via an ISO 20022 message could be routed through ILP connectors, settling on whatever underlying rail is most efficient for that particular corridor.

Adoption and Implementation

Mojaloop and Financial Inclusion

The most significant production deployment of ILP's principles is Mojaloop, an open-source instant payment platform originally released by the Bill & Melinda Gates Foundation in October 2017. Mojaloop implements ILP's conditional transfer model in its Financial Service Provider Interoperability API (FSPIOP), enabling real-time payments between different mobile money providers, banks, and fintech services within a country.

Mojaloop is live in production in Rwanda, Liberia, and The Gambia, with Tanzania's Bank of Tanzania running transactions on the platform. These deployments connect populations that historically lacked access to interoperable digital payment infrastructure, advancing the financial inclusion goals that motivated ILP's design.

Rafiki: The Reference Implementation

Rafiki is the Interledger Foundation's open-source reference implementation, designed for licensed Account Servicing Entities such as banks, mobile money operators, and payment processors. It implements ILP, Open Payments, and Web Monetization out of the box, providing a deployment-ready stack for organizations that want to join the Interledger network.

As of mid-2026, Rafiki is at version 2.4.0-beta with support for Open Payments API v1.3.0. A major architecture redesign is underway targeting high-performance, high-scalability deployments. The software ships as containerized services (auth, backend, frontend) deployable via Docker Compose or Kubernetes. The codebase is Apache 2.0 licensed and actively maintained, with monthly community calls and an ongoing security audit.

Web Monetization

Web Monetization is a proposed web standard that uses ILP and Open Payments to stream micropayments from website visitors to content creators. A website adds a single HTML element pointing to a wallet address, and the visitor's browser (via an extension) streams small payments in real time while the visitor browses.

The standard is published by the W3C Web Platform Incubator Community Group (WICG) and is actively being developed, though no mainstream browser has implemented native support yet. The earlier commercial implementation through Coil, a subscription service that streamed ILP micropayments to websites, shut down in March 2023 after struggling to reach critical mass with roughly 10,000 users. The Interledger Foundation continues advancing the standard through its specification work and browser extension development.

Implementation Challenges

Despite its elegant architecture, ILP faces significant adoption hurdles. The protocol's value depends on network effects: a connector network becomes useful only when it connects enough diverse payment rails to justify the integration cost. Today, no major commercial bank or global payment processor has publicly deployed ILP at production scale outside of the Mojaloop context.

Specific challenges include:

• Connector economics: running an ILP connector requires bilateral peering agreements, liquidity management, and regulatory compliance in every jurisdiction where settlement occurs. The operational burden is comparable to running a correspondent banking node.
• Liquidity fragmentation: each connector must maintain settlement capacity on every underlying rail it supports. A connector bridging ACH, SWIFT, and Lightning needs liquidity positions on all three.
• Regulatory ambiguity: ILP connectors that move value between fiat and crypto rails may require money transmitter licenses, and the regulatory classification of packet-routed payments remains unclear in most jurisdictions.
• Trust assumptions: while ILP eliminates systemic single points of failure, each sender must trust their connector to forward Fulfill packets honestly. This bilateral trust model is stronger than bridge security but weaker than atomic settlement.

The Interledger Foundation has invested over $21 million across 271 projects in 42 countries to build out the ecosystem. The 2026 Open Payments Accelerator Program and fellowship grants ($92,000 per fellow) continue this approach, funding implementations in underserved markets where the existing payment infrastructure gap makes ILP's value proposition strongest.

Connecting Bitcoin L2s to Traditional Payment Networks

ILP's ledger-agnostic design has direct implications for Bitcoin Layer 2 protocols. A settlement engine for a Bitcoin L2 would allow ILP connectors to route payments into and out of Bitcoin-native networks using the same protocol that connects to bank rails and mobile money. The sender does not need to know whether the recipient's funds settle on ACH, a blockchain, or a mobile money ledger.

This aligns with how Spark approaches payment infrastructure. Spark already supports instant transfers and stablecoin payments on a Bitcoin Layer 2 with Lightning compatibility. An ILP connector interfacing with Spark could expose Spark wallets to the broader Interledger network, enabling a user to receive a payment that originated from a bank account or mobile money wallet and settles as Bitcoin or USDB on Spark, with no changes to the sender's experience.

The distinction between payment messaging and settlement is fundamental here. ILP handles the messaging and routing. Spark (or any other network) handles the settlement. The separation means neither protocol needs to compromise its design to accommodate the other.

Developers building on Bitcoin Layer 2 infrastructure can explore Spark's SDK and documentation for integrating instant settlement capabilities into payment applications. For a working example of a consumer wallet built on Spark, see General Bread.

The Road Ahead for Interledger

ILP represents a bet that payments will eventually be routed like internet packets: across heterogeneous networks, through competing intermediaries, with end-to-end encryption and no requirement for a single governing entity. The protocol's technical foundations are solid, its specs are mature (ILPv4 has been stable since 2019), and its ISO 20022 alignment positions it to interoperate with the messaging standards that global banks are adopting.

The open question is adoption. ILP needs connectors willing to invest in bilateral peering, liquidity, and compliance. The Mojaloop deployments in Africa demonstrate that this model works when the alternative is no interoperability at all. Whether it can compete with established payment network infrastructure in developed markets, where ACH, SEPA, and card networks already function, remains to be proven. The most likely path to broad adoption runs through corridors where existing rails are expensive, slow, or absent: exactly the cross-border payment gaps that both ILP and Bitcoin Layer 2s are designed to fill.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.