A digression: what is the ILP or Interledger Protocol?

The Interledger Protocol sounds unglamourous. Sometimes referred to as the ILP, an undated paper by two Ripple employees, Stefan Thomas and Evan Schwarz, proposed it. The ILP has moved beyond Ripple and is now part of W3C, as the Interledger W3C Community Group.

In a relatively short time, it has moved from idea to serious consideration. One measure of this is a recent Bank of England (BoE) Proof of Concept. In this the BoE examined its applicability for one of its key market operations.

Ergo, in this digression, ET examines, for those who do not know, what the ILP is and how its proposers consider it might work. It draws on publicly available documentation as a scene setter for future analyses.

The ILP core

At its core, Interledger is a web protocol for routing payments across independent networks. It is a technology approach which has never existed before.

Its purpose is humdrum but enterprise critical. ILP aims to:

• deliver the payment speed and certainty necessary to service high volumes of all sizes and types of payments
• making these cost-effective for customers
• providing a profitable mechanism for financial institutions, specifically banks.

In theory, the ILP provides the same benefits as other blockchain systems, including the certainty and auditability of transactions. ILP proponents claim it adds advantages that traditional blockchains cannot offer, such as scalability, privacy and interoperability:

• horizontal scalability: no limits to transaction processing to meet customer demand.
• complete transaction privacy: transaction data remains private to only the transacting parties.
• Interoperability between independent networks
• utilization of existing ledgers, systems of record and currencies.

To Ripple, as the originator, the appeal was obvious. All banks and payment providers — from the smallest to the largest — can leverage the ILP’s open protocol to power payments across networks globally. The Interledger Protocol can work with any new network or system, regardless of its underlying technology (including, but not restricted to blockchains).

Essential concepts and component for the ILP

On the Interledger.org web site there is a description of how it would work. The central functions of the Interledger protocol are ‘addressing hosts’ and ‘securing payments across different ledgers’. The Interledger protocol treats each Interledger payment as an independent entity unrelated to any other Interledger payment. There are no connections or channels (virtual or otherwise).

Each host sending and receiving Interledger payments has an Interledger module that uses the addresses in the Interledger header to transmit Interledger payments toward their destinations. Interledger modules share common rules for interpreting addresses. The modules (especially in connectors) also have procedures for making routing decisions and other functions.

Interledger modules reside in hosts and connectors in the Interledger system. The payments are routed from one Interledger module to another through individual ledgers based on the interpretation of an Interledger address.

The Interledger protocol uses ‘transfer holds’ to ensure that senders’ funds are:

• either delivered to the destination account
• or returned to the sender’s account.

How ILP should work?

Its various steps (shown diagrammatically in the Interledger.org diagram above and described verbatim below) include:

1. The sending application uses a higher-level protocol to negotiate the address, an amount, and a cryptographic condition with the destination. It calls on the Interledger module to send a payment with these parameters.
2. The Interledger module prepares the ILP packet, chooses the account to send the local ledger transfer to, and passes them to the local ledger interface.
3. The local ledger interface creates a local ledger transfer, including the cryptographic condition, then authorizes this transfer on the local ledger.
4. The ledger puts the sender’s funds on hold — it does not transfer the funds to the connector — and notifies the connector.
5. The connector host’s local ledger interface receives the notification and passes it to the Interledger module.
6. The connector’s Interledger module extracts the ILP packet and determines that it should forward the payment. The Interledger module calls on the destination ledger’s local ledger interface to send the second transfer, including the same condition as the sender’s transfer.
7. The local ledger interface creates a local ledger transfer, including the cryptographic condition, then authorizes this transfer on the local ledger.
8. The ledger puts the connector’s funds on hold — it does not transfer the funds to the destination — and notifies the destination host.
9. The destination host’s local ledger interface receives the notification and passes it to the Interledger module.
10. The Interledger module extracts the ILP packet and determines that the payment is for an application in this host. It passes the transfer data to the application.
11. The destination application receives the notification and recognizes that funds are on hold pending the condition fulfillment. It checks the details of the incoming transfer against what was agreed upon with the sender. If checks pass, the application produces the condition fulfillment and passes it to the Interledger module.
12. The destination’s Interledger module passes the fulfillment to the local ledger interface.
13. The local ledger interface submits the fulfilment to the ledger.
14. The destination ledger validates the fulfilment against the held transfer’s condition. If the fulfilment is valid and the transfer is not expired, the ledger executes the transfer and notifies the destination host and the connector.
15. The connector’s local ledger interface receives the fulfillment notification and passes it to the Interledger module.
16. The connector’s Interledger module receives the fulfillment and passes it to the local ledger interface corresponding to the source ledger.
17. This ledger interface submits the fulfilment to the source ledger.
18. The source ledger validates the fulfilment against the held transfer’s condition. If the fulfilment is valid and the transfer is not expired, the ledger executes the transfer and notifies the connector and the sender’s host.
19. The sender’s local ledger interface receives the fulfillment notification and passes it to the Interledger module.
20. The sender’s Interledger module receives the fulfillment notification and passes it to the application.
21. The sender’s application receives the fulfilment notification and reacts accordingly.

What does it mean

The purpose of the ILP is to enable hosts to route payments through an interconnected set of ledgers. The ILP achieves this by passing the payments from one Interledger module to another until the destination is reached, along with roll-back where transfer conditions fail.

Global payment demands aren’t just increasing, they are changing. For example, retail and corporate customers envisage ever greater needs to send international low-value payments on demand and/or in real time. This needs to occur across a variety of networks with absolute certainty.

Today’s financial infrastructure does not make this easy. In consequence, banks face ever more competitive pressures from alternative payment providers as PayPal, Transferwise, CurrencyFair, Dwolla, Stripe, Intuit and others.

But consider: if an Interledger capability exists, could it produce a disintermediation effect that applies both within the financial sector and extends far beyond. After all – what is a ledger? And who owns them? The key may rest upon who provides the ILP ‘notary’.