InterLedger Protocol (ILP)
InterLedger Protocol (ILP)

The InterLedger Protocol (ILP) is the creation of two Ripple engineers – Stefan Thomas and Evan Schwarz. Their ‘invention‘ is a curious beast which has become part of W3C (as the Interledger W3C Community Group). The website offers a bare minimum of information and most people seem to associate ILP with blockchains.

In the view of Enterprise Times this may be to underestimate its potential role which could become a financial disintermediator with significant impacts on the finace sector in its broadest sense.

What is the Interledger protocol?

According to it is “The Protocol for the Internet of Value”. As such ILP represents an open suite of protocols for connecting ledgers of all types (see also: A digression: what is the ILP or Interledger Protocol?). These can vary:

  • from digital wallet
  • to national payment systems
  • to blockchains
  • to nominal (or other) ledgers in accounting systems.

The idea is that ILP will make it easier to transact, no matter where one lives or what type of money is in use. The idea is that transferring some unit of value should be as easy as sending an email today, albeit with the caveat that this involves money.

The Interledger Protocol looked at more deeply

In their original paper Thomas and Schwarz posited: “Digital payment systems use ledgers to track accounts and balances and to enable local transfers between their users. Today, there are few connectors facilitating payments between these ledgers and there are high barriers to entry for creating new connections. Connectors are not standardized and they must be trusted not to steal the sender’s money.

In this paper, we present a protocol for interledger payments that enables anyone with accounts on two ledgers to create connections between them. It uses ledger provided escrow—conditional locking of funds—to allow secure payments through untrusted connectors. Any ledger can integrate this protocol simply by enabling escrowed transfers. Unlike previous approaches, our protocol does not rely on any global coordinating system or ledger for processing payments — centralized or decentralized.

Unlike previous approaches, this protocol requires no global coordinating system or blockchain. Transfers are escrowed in series from the sender to the recipient and executed using one of two modes. In the Atomic mode, transfers are coordinated using an ad-hoc group of notaries selected by the participants. In the Universal mode, there is no external coordination. Instead, bounded execution windows, participant incentives and a “reverse” execution order enable secure payments between parties without shared trust in any system or institution.

It is this last paragraph (in fact the second in the original paper) which is instructive. ILP does not depend on blockchain technology, though it can exploit blockchain distributed ledgers if so wished.

Where might the Interledger Protocol take enterprises?

Sending money today within any single payment system is relatively simple. It can be fast and inexpensive, fast and expensive or slow and expensive – depending on the payment system. Typically something like CHAPS or BACS falls into the single payment system. Arguably, something like the Single Euro Payments Area (SEPA) is the same.

However, moving money between systems is almost always cumbersome, often slow and invariably costly, if it is possible at all. SWIFT, VISA and MasterCard clear payments between networks, say between the UK and the US or the Euro area. These are examples of costly (think of the many cost slices payees and recipients incur), slow networks, albeit with benefits.

Yet all modern business have to possess ledgers for their accounting. Those ledgers are automated by the likes of SAP, Oracle and Sage (to name but three). Sage, for example, estimates the value of business transferred per year as being close to US$3T, and that from a vendor which specialises in SMEs. What the equivalent totals for SAP and Oracle might be is unknown.

Now introduce ILP and consider the implications if your nominal ledger can reliably interwork, via ILP, with my nominal ledger. Rather than write a cheque or make an authorisation on my bank to transfer money from my bank to SWIFT to your bank and thence into you ledger, this could be far simpler with ledger to ledger processing.

But what about the value?

There are, arguably, two facets to this important question: value and dependability.

The ILP concept envisaged by Thomas and Schwarz dives deep into notaries and concepts of trusted (escrow) transfers for dependability. “A connector is a system that facilitates interledger payments by coordinating book transfers on multiple ledgers. Connectors can also translate between different protocols used by these ledgers. … Ledger-provided escrow guarantees the sender that their funds will only be transferred to the connector once the ledger receives proof that the recipient has been paid. Escrow also assures the connector that they will receive the sender’s funds once they complete their end of the agreement. … If any of the checks fail, or if an abort condition … is fulfilled, the transfer is aborted and the escrowed funds are returned to their originator.

The value part requires banks to still exist (though perhaps doing less and would be able to charge less), or at least some ‘place’ where deposits are possible. When Company A pays Company B it cannot be just a matter of book (ledger) entries. A transfer of mutually recognised value (assuming that Company A’s debits do not exactly match Company B’s credits for each other) must occur.

What does this mean

The conceptual implications are various and profound.

To start with; ledgers exist. They are common to all companies. The ability to ignore, but later incorporate blockchain mean businesses do not have to wait for proofs that blockchain value will ever materialise.

Next consider the likes of SAP or Oracle or Sage. Each has millions of customers (Sage claims >6M in over 20 countries). Imagine one of these made ILP a standard part of its nominal ledger product and then opened up a ‘transfer operation’ – in effect a transient clearing house between Sage customer ledgers. Such an entity could disintermediate many existing operations. It would not even be expensive to create or operate. It could earn its credibility with time.

Now imagine  if SAP could talk to Oracle to Sage. It would be even better if, say, most ERP vendors came aboard.

In case you think this all utterly unrealistic, have a look at Adrian Hope-Baillie’s site. In his latest addition, dated June 2nd, he refers to a demonstration of a single payment traversing numerous payment networks in seconds.

The basics, the ledgers, are in place. The Interledger Protocol exists. All it needs is some initiative, from a Sage, an SAP, an Oracle or other accounting vendor – or all together. The disintermediating impact could stun.

Previous articleCheck Point discloses four LinkedIn vulnerabilities
Next articleIBM X-Force sees record numbers of attacks
Avatar photo
Charles Brett is a business/technology analyst consultant. His specialist areas include enterprise software, blockchain and enterprise mobility tech (including metering). Specific industry sectors of interest and experience include finance (especially systems supporting wholesale finance), telecommunications and energy. Charles has spoken at multiple industry conferences, has written for numerous publications (including the London Times and the Financial Times). He was the General Chair of the bi-annual High Performance Systems Workshop, 2005. In addition he is an author and novelist. His Technology books include: Making the Most of Mobility Vol I (eBook, 2012); Explaining iTunes, iPhones and iPads for Windows Users (eBook, 2011); 5 Axes of Business Application Integration (2004). His published novels, in the Corruption Series, include: The HolyPhone Confessional Crisis, Corruption’s Price: A Spanish Deceit and Virginity Despoiled. The fourth in The Corruption Series - Resurrection - has is now available. Charles has a B.A. and M.A in Modern History from the University of Oxford. He has lived or worked in Italy, Abu Dhabi, South Africa, California and New York, Spain, Israel, Estonia and Cyprus.


Please enter your comment!
Please enter your name here