Interoperability with Liquidity Pools / AMMs

[leighmcculloch]

Update 2021-11-03: Liquidity pools / AMMs were introduced to Stellar in Protocol v18 via CAP-38.

@nickgilbert suggested we think about how this payment channel design could interact with liquidity pools to hold the assets in the payment channel in a liquidity pool.

How could we support holding the assets of the payment channel in a liquidity pool for the duration of the channel?

[leighmcculloch]

I'm not sure how we could do this without there being some minimum amount guaranteed at withdrawal.

However, I think we could have payment channels support deposit to and withdrawal from liquidity pools as coordinated activities, and if there are pool shares in the disbursement at close, the participants can then withdraw the original assets using the pool shares after the channel closes.

This idea requires support for transferrable pool shares, which I believe is not currently supported by CAP-38.

[accordeiro]

Just adding a bit more context here for others, I think the main rationale here is that "locking" funds in a liquidity pool is better than simply "locking" them in a Payment Channel: by locking funds, in theory you're losing money due to inflation, whereas in a liq pool you're accruing interest.

I think this is a good problem to solve, but I'm not sure this is the layer in which we'll solve it. I would love to keep the PC protocol as simple as possible, since even at its essence it already has a non-trivial number of possible states.

A "simple" way to solve this one abstraction layer above would be to instead of locking MyUSD in the Payment Channel, the two parties could issue pMyUSD assets that represent MyUSD in a liquidity pool. After channel close, there could be a redeeming process, that we could potentially standardize as its own SEP (or tweak SEP-6/24 for that).

[leighmcculloch]

locking MyUSD in the Payment Channel, the two parties could issue pMyUSD assets that represent MyUSD in a liquidity pool

There's risk here, there's no guarantee you will get enough MyUSD out of the pool to swap back against pMyUSD because there's no guarantee you get more MyUSD out of the pool than you put in.

A liquidity pool is two assets, e.g. AAA and BBB. If the rate is 1:2 and you put in 100 AAA and 200 BBB, there's no guarantee you get 100 AAA out, you might get out less AAA and more BBB. This means the payment channel can't make guarantees about AAA alone. For the payment channel to be guaranteed it has to be a lockup of both assets, i.e. the pool share asset.

The way I see this working is both parties deposit AAA and BBB into the liquidity pool, then open a payment channel with the pool share asset. The exchange payments using the pool share. At close, they get pool shares out and can withdraw AAA and BBB from the liquidity pool.

However, as noted above, this requires pool shares to be transferrable which they aren't in CAP-38, but may be in the future.

[nickgilbert]

Some initial ideas/use cases:

1. Payment channel lock up is by nature unproductive its essentially collateral. So by depositing collateral into a pool so that it earns yield for both parties is a useful capability. There are lots of interesting defi use cases like this including self repaying loans, which is not directly applicable to payment channels per se, but you could think of a number of models where custodial providers / remittance companies funded themselves from yield on user deposits using pools instead of trying to earn spreads at user expense.

2. AMM pools essentially give a synthetic midpoint between 2 assets and smooth out gains and loses, so a pool share can be thought of as a synthetic asset combining both. You deposit 10USDC/1800ARST to start and it only looses value half the rate of 3600ARST. This lets you split the currency risk in a corridor between 2 parties by trading the synthetic and dampen by using the less volatile asset.

3. Related to the above expanding quantity of assets in a pool along the lines of balancer opens up the possibility of using pool shares along the lines of what facebook proposed with Libra, or more importantly what Keynes proposed with Bancor.