The topic on the Plugin Architecture and Ledger Integrations got a bit unwieldy and stale since the summit so I am kicking off something new here to get feedback on some ongoing discussion that has been happening on Slack and in other channels.
Firstly, I’d suggest that anyone new to the concept of “settlement” look at the IL-RFC 32 on Peering, Clearing and Settlement which has some non-technical detail on why you need separate payments, clearing and settlement layers in ILP.
Also, be aware that IL-RFC 32 may need to be updated based on the outcome of the discussion regarding whether to track net balances or separate Payable and Receivable balances.
I considered making a blog post of this but I’m keen to hear back from people with questions or comments so please fire away below.
The goal here is to level-set. Our design will be based on some assumptions so we should all agree on what those are.
Why do we need settlement?
Two reasons:
-
We need a separate settlement layer because we explicitly want ILP to provide an inter-networking layer over multiple existing networks. This is somewhat unique to ILP and is less about the traditional concept of settlement and finality and more about inter-networking. In the early days of developing ILP we focused primarily on this characteristic of the layers below ILP so we called this the “Ledger Layer” (because Interledger was inter-networking ledgers).
-
The more traditional reason for having a separate settlement layer is due to the fact that settlement is the process of achieving finality for a payment. Payments are really just messages that establish financial obligations between the participants. Settlement is the process by which these are discharged finally and irrevocably. (Some useful definitions in the BIS Glossary)
Expanding on this second reason it is important to note that almost all payment networks have separate payment and settlement systems.
In the extreme case (usually for high value payments) settlement is done on a Real Time Gross basis. This means that settlement is performed for each payment at the same time as the payment. So it is natural to ask, why not simply use settlement systems for all payments (ignoring the inter-networking rationale for now) and avoid the complexity of having two systems?
The answer is well illustrated when looking at Bitcoin and Lightning. The cost of a settlement transaction is high and often, in order to achieve the safety guarantees expected from a settlement system, they are slow too (e.g. Bitcoin). To support smaller payments it’s necessary to layer a new system (e.g. Lightning) on top of the settlement system that is designed with different characteristics that compromise some of robustness of the settlement system for the sake of performance and cost.
Thesis:
For any system that executes financial transactions atomically and durably between distributed participants; as the value of a transaction decreases, the ratio of the cost to the value increases.
As a result payments systems use aggregation and netting to reduce the number of transactions required to settle a batch of payments. I.e. Lots of payments and fewer settlements means lower costs per payment.
This means that payments systems are generally designed to provide liveness guarantees rather than safety guarantees and will favour eventual consistency between participants (using reconciliation, clearing etc) over atomicity and durability.
Sidebar: What this also means is that a system that is used for payments of a particular value might need a new payment system layered over it in order to viably support smaller payments. i.e. A payments system can be used as the settlement system for another payment system (usually designed for even faster or even smaller payments).
This implies that the differing characteristics of payment and settlement systems are relative, not absolute. For a payment system like ILP, where there is a great variety of settlement systems we need to support, some of which may even be fast and cheap low value payments systems themselves.
Optimizing Settlement
In exchange for layering a payments system on top of a settlement system we must make some compromises and our goal in designing the architecture is to minimise the effect of these.
-
Locked Up Liquidity: Because we have capital that is moving in the settlement layer at a different rate to the payments being made there is a delay between a recipient of a payment getting paid and having the capital they are owed available to settle another outgoing payment. Therefor the cost of participating in the settlement system is directly related to the amount of capital required and the time that it is locked up.
-
Settlement Risk: Participants in the payment system are creating financial obligations with one another but these are not guaranteed to be paid until settlement has occurred. Therefor participants face the risk that a peer may not be able to settle them for payments they have made to them.
The cost of locking up liquidity can be offset by providing credit instead of requiring collateral. I.e. Increase risk to reduce costs. Conversely, the risk of not getting settled can be offset by requiring pre-funding. I.e. Increase costs to reduce risk.
So it should be obvious that the goals of a good settlement system are to balance and minimise these risks and costs.
To do this it is important to consider various factors that influence both the costs and the risks:
- the risk profile of the peer
- the cost of capital of the underlying asset
- the speed at which settlements can be completed
- the cost (both reputational and financial) of running out of liquidity and rejecting payments
- the cost of performing settlement transactions
- the revenue generated from processing payments
Our goal is to design a means by which this system can track the payments happenning at the ILP layer and orchestrate payments on the settlement layer so that we minimize the liquidity that is locked up but only to the point that the risk is acceptable to the node owner.
Architecture
The Interledger layer is not complex. The protocol rules are simple. Packets are exchanged between peers and the financial obligations between those peers are adjusted according to the result of that exchange.
The interface to the settlement systems that will be used by ILP nodes is also not complex, it simply needs to support sending settlements and being notified when settlements are received.
The complexity lies in the business logic that exists between the ILP layer and the settlement layer.
The Settlement Business Logic must observe changes in the balances at both the settlement and ILP layers and react to these to balance the risk and cost described previously as best they can.
This could be simple when settlement is fast and cheap (XRP Payment Channels) but gets more complex if the cost of the capital is high (XRP price goes up?), or if the cost of settlement is material, or if settlements take longer than a few seconds.
In the simple case it may be sufficient for that logic to simply track the balances at the ILP layer and trigger settlements based on pre-configured thresholds however it’s likely that in time this will need to be adaptive to a changing environment.
Summary
We build payments systems that are faster and cheaper on top of settlement systems that are slower and more expensive but safer.
We must design an integration between these systems so that we get the fastest, cheapest payments at the lowest risk but can also choose where on the spectrum we wish to operate in terms of those three dimensions.
In the case of ILP we must also design that integration so that we support the widest possible choice of settlement systems.
)
)
)
)
)