Interledger

• Name: Interledger
• URL: https://interledger.org/developers/rfcs/interledger-architecture/
• Category: packetized payment-routing protocol suite / cross-ledger interoperability architecture / end-to-end money-and-data transport stack
• Summary: Interledger is best understood not as a single network, token, or wallet product, but as an Internet-style protocol suite for routing payments across otherwise unrelated financial systems. Its primary materials repeatedly separate five layers — underlying settlement ledgers, bilateral link protocols, the core Interledger Protocol (ILPv4), end-to-end transport such as STREAM, and application setup protocols such as SPSP. That decomposition is the real reason it belongs in the corpus: Interledger makes cross-system payments legible as bilateral account funding/rebalancing plus packet forwarding plus endpoint transport plus destination setup, instead of flattening the whole stack into one generic payments product or one shared settlement rail. This makes it a useful comparison point for Open Payments, x402/L402, OrcaRail, payment-channel networks, and open-banking-style APIs.
• What it does:
  • Defines a layered architecture for sending value across heterogeneous ledgers, banks, blockchains, payment channels, and other settlement systems without requiring them to share one common base network
  • Uses ILPv4 to forward small value packets across chains of bilateral accounts held between peers and connectors
  • Lets each pair of peers choose how to fund and rebalance their bilateral obligations using whatever underlying ledger or payment-channel arrangement they share
  • Separates connector forwarding logic from end-to-end transport, so connectors relay ILP Prepare / Fulfill / Reject packets while sender and receiver use higher-layer protocols for chunking, encryption, exchange-rate adaptation, and data carriage
  • Uses STREAM as an end-to-end transport that multiplexes money and data streams, chunks larger payments into packets, encrypts/authenticates payloads, and manages flow/congestion control
  • Uses SPSP and payment pointers as a minimal application-layer discovery/setup flow so user-facing applications can resolve a destination, obtain a shared secret, and start a STREAM connection over HTTPS
  • Explicitly follows an end-to-end principle where most complexity should live at the edges rather than inside the core packet-switching layer
• Key claims:
  • Interledger’s strongest reusable insight is architectural, not branding. The official architecture RFC says plainly that Interledger is not a blockchain, token, or central service, but a standard way of bridging financial systems through layered protocols.
  • ILPv4 matters because it narrows the interoperability core to packet forwarding across bilateral accounts. Packets of value move through connectors, while actual settlement/rebalancing happens separately below the protocol through ledgers or payment channels.
  • The bilateral-account rule is important because it constrains contagion. The architecture RFC explicitly says settlement for one account must not depend on the status of any other account, which is a clean design response to cascading-risk problems in interconnected financial systems.
  • The protocol is intentionally optimized for penny switching: large volumes of low-value packets instead of one-shot high-value delivery. That simplification removes some earlier complexity, reduces connector risk, and pushes chunking of larger payments into higher layers.
  • STREAM is a major reason Interledger is worth keeping separate from later wallet/address standards. It turns bare packet forwarding into an end-to-end transport for multiplexed money and data, with shared-secret-based encryption, chunking, acknowledgements, and flow control.
  • SPSP and payment pointers expose another distinct control surface: user-facing destination discovery and setup. The payer first learns an ILP destination account and per-query shared secret over HTTPS, then starts a STREAM connection; those steps are not baked into ILPv4 itself.
  • Interledger belongs in the active corpus because it gives the payments cluster a strong lower-layer comparison point. Many later systems standardize only authorization, wallet discovery, checkout UX, or machine-readable HTTP payment hooks, while Interledger makes packet routing, bilateral risk, endpoint transport, and setup discovery separately legible.
• Whitepaper: No canonical standalone Interledger whitepaper surfaced in this pass. The strongest primary materials were the architecture, ILPv4, STREAM, and SPSP RFCs collected in ../whitepapers/interledger-primary-sources-2026-05-15.md.
• Sources:
  • https://interledger.org/developers/rfcs/interledger-architecture/
  • https://interledger.org/developers/rfcs/interledger-protocol/
  • https://interledger.org/developers/rfcs/stream-protocol/
  • https://interledger.org/developers/rfcs/simple-payment-setup-protocol/

Internal linkages

• Closest lower-layer descendants: open-payments and payment-pointers.

• Best paid-request contrast: x402.

• Keep the comparison set tight. Interledger matters because it exposes packet routing and bilateral risk directly, not because it can be loosely grouped with every checkout or wallet-pay note.

• Last reviewed: 2026-05-29 UTC