“Imagine something like Uniswap or Curve, but on XRPL!”
This is a brief high-level proposal for implementing Automated Market Makers (AMMs), specifically Constant Function Market Makers (CFMMs), directly on the XRPL. The ideas presented below are neither innovative nor original. But I believe they would represent a valuable addition to XRP.
The main benefit of the proposal is the creation of decentralized autonomous swap pools. This functionality would in turn significantly reduce the barrier of entry and would allow anyone to participate in global liquidity pools, similar to how Uniswap is operating on Ethereum (sans the on-chain fee hilarity…).
I believe having this functionality native to the XRPL would contribute towards the vision of XRP as recently laid out by David Schwartz:
My personal vision for XRP, since 2013 or so, was this idea of deep, open, public pools of liquidity that anyone, anywhere could contribute to and draw off of — a global market for assets that someone happens to already have exactly where someone else happens to need them to be. — David Schwartz
The actual implementation requires adding some transaction types to the protocol. Figuring out all the details is a task that remains to be done.
What is a Constant Function Market Maker?
A very nice description of CFMMs can be found in this Medium post by Dmitriy Berenzon. Some academic reading can be found here. For the purpose of this proposal, I will summarize only the key insights.
A Constant Function Market Maker is a class of AMMs where the reserves of the assets in the pool can only change in a way that satisfies a certain mathematical relationship. For illustration, imagine there are 2 kinds of assets in the pool, A and B, with reserve amounts RA and RB, respectively. Assuming zero fees for simplicity, the pool can change its composition by a transaction only if the following relationship holds,
Here ϕ is the trading function that is kept constant (hence the constant in the name), and ΔA and ΔB are the changes in the reserve amounts.
A very common CFMM is the so-called Constant Product Market Maker,
In this equation I have introduced percentage fees through ɣ = 1- fee that is added to the reserves. I have also explicitly assumed that asset A is added to the pool and asset B is withdrawn, so that the sign of the Δ’s is positive.
The ratio of both assets defines the relative price of both assets. One can quickly see that if the trade is small (compared to the liquidity — amount of assets in the pool), the price of the swap is very close to the current price defined by the reserve ratio. Bigger trades incur a degree of slippage that can be visualized by a hyperbola (image taken from the Medium article by D. Berenzon).
In this model, even though the slippage can be large for trades comparable to the liquidity you cannot run out of an asset as the price of the one being withdrawn (bought) increases towards infinity.
Benefits
There are many benefits of having CFMMs on the XRPL as first class citizens, but in my view the following below are key.
1. Democratizing and bootstrapping liquidity
As we have seen, bootstrapping liquidity through order-book based exchanges has been a challenging task, especially on the DEXes.
- Running a bot to send orders to the decentralized order book on the XRPL requires a decent level of technical expertise and is therefore representing a significant barrier of entry that prevents most XRP holders to participate.
- Even if one has that kind of technical expertise, there is significant risk involved in the trading strategy the bot would be executing.
- The risk is also a function of the amount of assets that one can afford to bring to the order book.
CFMMs eliminate all of the above, making the XRPL truly a level playing field for all kinds of liquidity providers. Every passive XRP holder would be encouraged to lend their assets to pools.
2. Reduced transaction volume and faster exchange
It is known that the XRPL is flooded by OfferCreate and OfferCancel transactions. This is one of the foreseen use cases, but it does not seem very efficient to me. For any given closed ledger, there are typically just a handful of payment transactions included. The majority of the transactions are just manipulating the decentralized order book one way or the other, with the occasional actual trade thrown in.
CFMMs sidestep the synthetic order book creation. Trades execute instantly. Liquidity can be added or removed instantly.
Of course, arbitrageurs would continue to use any imbalance in the price to their favor with the usual added benefit of equilibrating the pool with the environment. However, the number of transactions on the XRPL required to do that would be greatly reduced.
3. Path independence
The price of an asset on the order book depends on many factors, such as depth, liquidity, and trading history, but most of all, it depend on the responses of participants. In case of the XRPL DEX the responses are not very swift as they are limited by the ledger close time.
CFMMs are path-independent. The trade price depends only on the quantities involved (trade size & pool liquidity), significantly simplifying the trading strategy considerations.
Possible high-level implementation
This below outlines a proposed high-level implementation. There may be better implementations possible with improved properties, semantics, and terminology. This proposal is only focused on the overall concept.
3 new transaction types are added to the XRPL protocol: poolDeposit, poolWithdraw, and poolSwap.
As their names indicate, the first one is used to deposit two assets into the pool, the second one is used to withdraw assets from the pool, and the last one is used to perform a trade. I will not elaborate here on the technicalities of these transactions, but one can reasonably expect the following properties:
- poolDeposit
Parameters: Specifies the amount of assets to deposit into the pool. These amounts need to conform to the current pool ratio. There are many possible parameterizations here, I would propose to choose one that promotes clarity.
Effects: If valid and accepted into the ledger, the specified amount of assets is transferred to the pool reserve amounts.
- poolWithdraw
Parameters: Specifies the amounts of assets to withdraw from the pool. These amounts need to conform to the current pool ratio, are limited by the contributed liquidity (with fees), and should be parameterized the same as in poolDeposit for consistency. Specifying a very large amounts signals the intent to withdraw all the contributed liquidity.
Effects: If valid and accepted into the ledger, both assets are attributed to the source account according to the requested and/or maximum amount.
- poolSwap
Parameters: The asset and the amount that will be deposited into the pool for executing the automated swap.
Effects: If valid and accepted into the ledger, the counter-asset from the pool will attributed to the source account sending this transaction and the pool reserve amounts will be adjusted as required by the formula.