The simple primitive that could unite the world’s payments systems

It’s impossible to predict the power of a simple idea. In its simplicity, such an idea belies its usefulness and therefor the huge number of use cases and solutions it might unlock. This is certainly the case for one of the simplest and most powerful ideas of our time, the Internet, or more specifically the Internet Protocol.

For most people the Internet is not simple. The intricacies of this system that can beam a high definition video across an ocean in real-time, simultaneously deliver a single email to a hundred different recipients spread around the world, or facilitate the instant exchange of value between two parties trading crypto-currencies, is beyond comprehension to most. But what most of us think of as the Internet is actually the complex layers of applications that have been built on top of the Internet, itself a very simple utility.

And this is no accident. Despite knowing that complex issues such as reliability and sequencing needed to be solved, the inventors of the Internet Protocol intentionally left these solutions out of the protocol specification. As RFC 791 says:

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.

It’s this quest for simplicity that has been a guiding principal in the development of the Interledger protocol. It has led us to develop a protocol that, at its core, has only two key concepts, universal account addresses and conditional payments.

Universal account addresses

The idea of universal account addresses (or ILP Addresses as we call them) is unashamedly copied from the Internet Protocol.

The first step in interconnecting nodes (or in our case, accounts) on different networks (or in our case, payment networks) is to give them all an address that is understood by all of the other nodes on the all of the other networks.

Another incredibly simple idea with far reaching consequences.

Conditional Payments

The second critical primitive is defined in the original Interledger Whitepaper but it’s only recently that the name conditional payments has begun to stick.

A conditional payment is quite simply; a payment from one account to another, on the same network, where the network suspends delivery of the payment pending the fulfillment of a condition predefined by the sender, or rolls back the payment following an expiry timeout, also predefined by the sender.

In terms of how this is implemented you can imagine a payment from Alice to Bob sent via ACH, Bitcoin, Venmo or any other payment method where Alice defines a condition, such as Bob signing a receipt, that must be met before Bob gets paid.

Alice initiates the payment by sending an instruction to the network to debit her account and credit Bob’s. But the network doesn’t immediately credit Bob’s account. It first notifies Bob that a payment is on hold for him if he can fulfill the condition that Alice has attached to the payment (a request for Bob’s digital signature on the receipt).

At this point Alice no longer has access to her money, but crucially, neither does Bob.

Alice initiates a conditional payment to Bob

As soon as Bob presents the signed receipt, the funds are released and he gets paid. Alice gets notified and gets a copy of the signed receipt (the fulfillment of the condition), so she now has non-repudiable proof that she paid Bob.

Bob claims his money by presenting the fulfillment of Alice’s condition

You can scratch around and you’ll find few payments systems that offer this kind of functionality natively. The closest thing you’re likely to find to it are escrow systems where the escrow is provided by a third party (not by the payment network itself).

The Benefits

It’s easy to see the value of a condition in the simple payment above between Alice and Bob. Both parties are protected by the network from the other behaving badly. In other words, they only need to trust the system that they already trust to hold their money.

This pattern is one of the primary motivators behind crypto-currencies and distributed ledgers where the shared network between both parties doesn’t even have an operator. Instead the trust they place in the network is based on the trust they have in the system itself, the code.

But the benefits of conditional payments extend far beyond simple on-network payments. Imagine Alice and Bob don’t share a common payment network and therefor don’t have a common anchor of trust.

Using conditional payments it’s possible to introduce one or more counter-parties to the transaction and chain these conditional payments together without requiring any party to trust anybody new.

Instead of making a conditional payment to Bob, Alice makes a conditional payment to Chloe, who is on the same network as her, but also has an account on the same network as Bob. The condition that Alice attaches to the payment must still be fulfilled by Bob so in order for Chloe to get paid she needs to pay Bob and get that signed receipt.

Alice initiates a conditional payment to Chloe who in turn initiates a payment to Bob using the same condition

As soon as Bob sees the payment pending from Chloe, he signs the receipt to claim his money and at the same time Chloe gets the receipt she needs, to claim her money on hold from Alice.

Bob uses the fulfillment of Alice’s condition to claim his money from Chloe. Chloe then uses the same fulfillment to claim her money from Alice.

Alice has her signed receipt, Chloe has presumably charged a small fee for facilitating the payment, and Bob has been paid. A payment that is almost impossible to co-ordinate today, in an autonomous fashion, without all three parties being subject to a common payment scheme, is easily accomplished because of the availability of a simple network feature, conditional payments.

Conclusion

Payment network interoperability is not as complex or as difficult to achieve as it may seem. There are valuable lessons to be learned from the architecture of the Internet and the simplicity of its underlying protocols.

Conditional payments at the network or ledger level unlock the ability to chain multiple payments together so that anyone, on any network can make a payment to anyone else on any other network.

The great pity is that the prevalence of conditional payments is very low, so while we wait for the technology to catch up (and we expect the crypto-currency ledgers to be first to the party) we need to consider how we can bootstrap this Internetwork of payment networks using some more tricks from the early days of the Internet.

Remember that little box that you connected to your phone line that went “beep bop boop” and allowed you to join the Internet without the underlying infrastructure support and without permission from the telephone company? We do, and we’ve got a few ideas about how “dial-up” Interledger access could work too. More on that soon…