Ledger Adapter API

[adrianhopebailie]

@kincaid

I strongly do not think operations related to liquidity management can be cleanly abstracted to increaseLiquidity / decreaseLiquidity , and that the associated business logic will need to exist within the “ledger adapter” itself.

Can you expand on why?

This proposal simply requires the SE to understand WHEN it should request liquidity not to know HOW to make it available.

@kincaid

For unidirectional channels, one important part of “unlocking” liquidity is asking the peer to claim the outgoing channel from you to them, since you can’t. (e.g., even if you claim the incoming channel, you might have a lot locked up in the outgoing side that you want back)

How would that be handled in this framework?

The goal with this proposal is for the SE to (over time through observation or through explicit config) know with some level of accuracy how long it will take to free up liquidity and so request this if it forecasts a need to perform a settlement that may not have the necessary liquidity.

It is then up to the LA to “make it happen”, even if this means sending a message to the counter-party requesting a collaborative rebalancing of unidirectional channels.

@kincaid

Would the request timeout? Or would increaseLiquidity respond immediately, and then would the “settlement engine” poll getLiquidity until it was updated?

On Lightning, it’d be useful to have the functionality to open a direct channel with your connector. Since the time to finality is so long (60 minutes), how would that work with this API?

We anticipated all requests from the SE to the LA being async. I.e. You request that something is done and get an ACK. In parallel, notifications about changes of balance will let you know when they have been completed.

Our thinking here was that the most complex part of this process sits at the SE so, if possible, we should abstract everything else out as far as possible and only write this part once.

I recognise, especially when looking at the fees, this may be unnecessarily complex.

In that case, does an SE/LA per ledger make more sense?

Said differently, maybe we should standardise the Connector <-> SE interface?

@adrianhopebailie

Settlement Engine → Connector

• getBalance (get the current balance of the clearing account, i.e. ILP balance)
• setBalance (update the current balance of the clearing account, apply a delta)
• sendData (send a message to the Settlement Engine on the peer)
• receiveData (accept a message from the Settlement Engine on the other peer)

If so I’d strongly advocate for an interface where that component simply tracks the balances on the connector(s) per account and performs settlements as necessary and then updates that balance.

i.e. getBalance is complemented by a debounced stream of balance changes from the connector to the SE.