Liquidity Pool - General Discussion

[dKrypt Live]

This general discussion is created in effort to not detract from the dedicated CAP-37 and CAP-38 conversations.

First, I would like to thank both authors for their work. Together, they have started a very important conversation that will substantially improve the ecosystem.

After reviewing both CAP's and listening to the Open Protocol Discussion, the conversation is currently focused on adapting existing technologies and little attempt to improve upon the basic mechanisms of established liquidity pool structures.

More specifically, risk of impermanent loss has not been addressed, yet this remains a primary concern to most prudent liquidity providers. Additionally, orderbook market makers are not included in the liquidity pool structure, yet they play a critical roll in the price discovery mechanism necessary for automated market makers to function. To design an optimal liquid pool, we must respect the interests of the liquidity providers, liquidity takers, and orderbook market-makers equally. Finally, there has been no conversation on leveraging the benefits of the SCP to create features other liquidity pools cannot.

Liquidity providers (LP's) are simply asset holders looking to put otherwise dormant assets to work in attempt to produce passive income. As such, LP's are already exposed to risk of asset depreciation and therefore deserve the full benefit of asset appreciation. However, impermanent loss robs LP's of their potential gains. Additionally, liquidity pools actually increase downside losses.

For instance, let's assume current market is at $0.50 USD/XLM. Jed and 9 others create an XLMUSDC liquidity pool, each initially staking 200 XLM/100 USDC for a 10% share. Total liquidity k = (2000 XLM)*(1000 USDC) = 2M.

Let's say XLM rallies to $1/XLM. To correct the liquidity pool valuation, arbitrage traders swap USDC for XLM, bringing liquidity balance to (1414 XLM)*(1414 USDC) = k = 2M. Constant product is preserved, and asset value has now been corrected. However, should Jed choose to redeem is 10% share, he would be entitled to 141.4 XLM and 141.4 USDC, currently valued at $282.84. However, had Jed simply held his funds, he would still have his original 200 XLM and 100 USDC valued at $300. By participating in the liquidity pool, Jed realized an impermanent loss of $17.16 of his $100 in potential gains. Now, 17.2% diminished returns could be acceptable if downside risk was equally reduce, but downside risk is actually increased.

Say XLM depreciates to $.25/XLM. The pool would correct to (2828.4 XLM)*(707.1 USDC) = k = 2M. Jed would now be entitled to 282.8 XLM and 70.7 USDC, valued at $141.42. Had he held his original 200 XLM and 100 USDC, is holdings would be valued at $150. Participating in the liquidity pool resulted in an additional $8.58 loss.

So, LP's stand to lose value regardless of market direction. Their downside risk is magnified, and their upside potential is marginalized. The only way for a LP to be rewarded is through earning yield from fees paid by liquidity takers, and hope there is enough volume to offset volatility losses. 

However, instead of relying on arbitrage to correct asset ratio, a better solution is to allow the automated market maker (AMM) to place "out-of-balance" assets into a liquidity reserve. In the first scenario where XLM appreciated to $1, with 2000 XLM and 1000 USDC in pool, an excess of 1000 XLM exists. Should an AMM place this excess 1000 XLM into reserve, the ratio is now corrected to market norms and available for liquidity takers at proper valuation.

While this violates the "constant product" structure since now k = (1000 XLM)*(1000 USDC) = 1M, there is fundamentally no need for k to be constants in perpetuity. Rather, k only needs to be constant momentarily when a liquidity taker executes a trade since this is the determining factor for asset conversion. In this structure, k would be held constant while trades are executed, then refreshed (if necessary) at a set time interval or if liquidity pool valuation deviates from market valuation by a predetermined threshold. By allowing for an asset reserve and variable product (m), a few unique opportunities arise. 

First, it solves the problem of impermanent loss and downside magnification. In the first scenario, with 1000 XLM in reserve and trades executed against m = (1000 XLM)* (1000 USDC) = 1M, Jed could still with draw his original 200 XLM (100 from reserve, 100 from pool) and 100 USDC from pool. In the second scenario ($.25/XLM), 500 USDC would be moved to reserve, leaving 2000 XLM and 500 USDC in pool (ratio matches market valuation, trades executed against m = 1M). Similarly, Jed would still be able to withdraw his original assets (50 USDC from reserve, 50 USDC from pool, 200 XLM from pool).

Second, these reserve assets open the possibility for single-asset staking. In the first scenario with 1000 XLM in reserve, if Denelle wanted to stake USDC only, she would be able to contribute up to 1000 USDC with the necessary 1000 XLM to be matched by the reserve. In the second scenario with 500 USDC in reserve, Denelle would be able to stake up to 2000 XLM. 

Finally, the reserve assets could also be entered into smart contract loans (as is being developed by YieldBlox). Not only would this provide an additional revenue source to LP's, but it would also create on-demand, temporary liquidity that does not have any effect on trade pool liquidity nor will it affect the orderbood price discovery mechanism. 

Moving on to determine fee structure, we must pursue a mechanism that cannot be manipulated nor dictated, and must be equitable for all parties. To that end, free market competition may offer a solution. Effectively, a "fee" structure already exists within the orderbook due to slippage. Should a liquidity pool fee ever exceed slippage loss for an equivalent trade, there is no incentive for a trader to utilize the liquidity pool. However, should pool fee be substantially less than slippage loss, LP yield will be reduced and orderbook market makers will be pressured to revise offers and reduce spread, effectively manipulating price discovery.

However, pressuring market makers to reduce spread may not be entirely evil, and could benefit the ecosystem as a whole. To this aim, it may be optimal for the liquidity pool fee to be automatically set at or a few basis points below slippage loss. Ideally, the percent difference between slippage and fees should be determined by vote, and could vary asset to asset depending on volatility (more volatile asset pairs may need spread forgiveness, where more stable asset pairs should be highly incentivized to eliminate spread).

In addition to influencing orderbook spread, a pegged fee system would also ensure traders always receive competitive rates and liquidity providers receive appreciable yield.

Finally, the answer to determining what trading pairs should be permitted is hidden in plain sight, and may be the most unique aspect of liquidity pools on the SDEX. One of the most distinctive features of Stellar is Path Payments. The ability to send any asset and have it delivered as any other asset is truly remarkable, yet often overlooked and far underutilized. However, liquidity pools offer a second life to path payments. 

Other blockchains require endless pool pairs. If a particular pair doesn't exist, a trader is force to trade in and out of multiple pools, racking up fees along the way. Stellar doesn't have this problem, Stellar actually has the most perfect solution to that problem already implemented though path payments. Reinvented as Path Pools, it would be frictionless and seamless for a trader so swap through as many pools as necessary to finally arrive at the target asset. So if that problem doesn't exist for Stellar, then the conventional endless pool pair solution is irrelevant. 

Stellar stands to benefit greatly from a reduced number of pools. Fewer pools means higher concentration of assets, and the pools are better equipped to serve their purpose. Additionally, by implementing all pools as an XLM pair only, this will benefit the entire ecosystem. With XLM present in every pool, there will only ever need to be two pool trades to complete a path payment (ABC-XLM)-(XLM-XYZ). Also, it would be easily to artificially create a representation of any trading pair, simply by dividing the XLM valuations of each asset (ABC:XYZ = ABC:XLM/XYZ:XLM). Finally, this would drive adoption of XLM as a reserve asset, helping the native token find utility within its own ecosystem.

-William Ritner

[dKrypt Live]

As I further contemplated the post, it occurred to me there is an additional opportunity to increase overall efficiency, liquidity, and yield.

In the structure proposed, if a liquidity pool became imbalanced, a portion of the appreciating asset is moved into reserve to correct the imbalance instead of allowing arbitrageurs to profit. Also discussed was limiting pool creation to XLM pairs only, meaning reserves created will either be the unique asset or XLM.

If the unique asset appreciates and is moved into reserve, there is really no additional utility for this asset other than entering it into an interest-earning loan. However, if the unique asset depreciates, then excess XLM would be moved to reserve. Because all other liquidity pools are also designed to rely on XLM, the reserved XLM from one pool could be used in another pool with and XLM deficiency.

To facilitate the movement of XLM from one pool with an excess to another pool with a deficiency, it may be beneficial to implement a global XLM-only pool. With a global XLM-only pool, deficient unique asset pools would have instant access to additional XLM needed to match single-asset stake or correct a valuation imbalance. Similarly, it would offer a repository for excess XLM to find outside use and benefit the entire ecosystem.

As the system grows and individuals stake XLM to the XLM-only pool, it may reach a point were there is always enough XLM available to provide parity to deficient unique asset pools. Essentially, new pools could be created without staking XLM at all, or single-asset contributions to existing pools could be more commonplace, all facilitated by on-demand access to the XLM needed from the XLM-only pool.

[Markus Paulson-Luna]

Now that I've had the opportunity to give this a thorough read, I've got a few points to add.

1. Your proposal, while interesting, is simply too complicated to be integrated into the Stellar Core. Among other things, it would likely require a Governance model which is impossible for the Stellar Core to support. 

2. One major concern is by removing the necessity to maintain a product constant you remove the security of a product constant model. A x*y=k model will never lose funds relative to the amount that was deposited. I'd be very hesitant to implement an unproven model that removes this security factor. The rewight function would likely be very complex and implementing it into the core would mean we may be adding unknown vulnerabilities into the entire network. That's one of the reasons that the proposed CAP's are sticking to very conservative and proven AMM models.

3. Your proposed model relies on an external pricing mechanism. This would require the stellar core to rely on an external API which is very problematic, both from a performance and security standpoint. How can you ensure that every Node validating transactions receives the same response from the API provider?

4. I don't like the idea of reducing the liquidity in a pool to combat impermanent loss. If a user wants to retain a certain amount of liquidity contributions they would have to continually withdraw and deposit assets to keep their assets in the pool rather than in reserves.

5. What happens if users contribute enough of one asset type to deplete reserves of the counter asset type? Are users who contributed the assets which were  moved to reserve now unable to withdraw those assets by burning pool tokens?

Overall your proposed system has some areas that need to be fleshed out more, but it's a great idea. I just think it's much to complicated and unproven to be added to the Stellar Core, at least right now.