Used for HTTPS-based destination discovery, shared-secret exchange, payment pointers, and the separation between user-facing setup and ILP/STREAM transport
Key takeaways from primary sources
Interledger is most useful as a payment-architecture decomposition, not as a single network. The architecture RFC is explicit that Interledger is neither a blockchain nor a central service, but a standard way to bridge financial systems through layered protocols.
The core ILPv4 move is to treat payments as packets forwarded across bilateral accounts, while settlement and rebalancing happen separately through whatever ledger or channel each pair of peers chooses. That keeps the interoperability layer narrow and pushes many other features to the edges.
Connector risk management is central to the design. ILPv4 is optimized for large volumes of low-value packets, short expiries, local forwarding decisions, and end-to-end condition/fulfillment logic so that intermediaries do not need global price knowledge or open-ended exposure.
The layer split is the most durable analytical insight: underlying ledgers settle bilateral obligations, link protocols carry packet and settlement information, ILP forwards value packets, STREAM handles end-to-end transport/chunking/encryption, and SPSP exposes a minimal HTTPS discovery/setup layer for applications.
STREAM matters because it turns ILP from a bare packet-forwarding primitive into a usable end-to-end transport for streaming payments, larger chunked payments, and attached data. It is effectively a transport layer for money and messages rather than a simple invoice format.
SPSP matters because it makes user-facing payment setup legible as its own control plane. Payment pointers, HTTPS lookup, destination-account disclosure, and per-query shared-secret handoff sit above ILP/STREAM rather than being hidden in one wallet product.
Specific source signals worth retaining
The architecture RFC is the best source for the Internet-style layering and the strong rule that settlement of one bilateral account must not depend on any other account.
The ILPv4 RFC is the best source for packetized low-value transfers, bilateral balances, connector roles, and the shift away from ledger-enforced escrow toward packet forwarding plus external rebalancing.
The STREAM RFC is the best source for multiplexed money/data streams, chunking, flow control, connection migration, and shared-secret-based end-to-end authentication/encryption.
The SPSP RFC is the clearest source for how user-facing discovery and setup work in practice through payment pointers and HTTPS, rather than through direct exposure of ILP internals.
Why this entry belongs in the corpus
Interledger gives the payments cluster a strong lower-layer comparison point beneath Open Payments, x402/L402, machine-payments APIs, and merchant-facing rails like OrcaRail.
It makes a crucial split explicit: payment routing, endpoint transport, destination discovery, and actual settlement are different layers, and many later payment protocols only make sense when that decomposition is visible.
The durable insight is that interoperable payments need not mean one shared settlement network. Interledger instead treats interoperability as packet forwarding across bilateral trust links, with end-to-end setup and chunking layered above and settlement abstracted below.