Solving Order Flow Toxicity
How can one make a decentralized exchange protocol friendly to large non-arbitrage traders and liquidity providers rather than arbitrage traders alone? In this last post of our series, co-written with Polina Nezlobina and Nikita Zinoviev, we lay out several design principles for protocols seeking to achieve this goal. We build on the ideas discussed in parts one, two, and three of the series.
Introduction
Designers of decentralized exchange protocols face a lot of challenges. Transactions are expensive and latency is high. Trades and liquidity movements are publicly observable prior to execution, leading to a high risk of front-running, sandwich, and other market manipulation attacks. All of this makes the environment friendly to arbitrageurs and hostile to the regular market participants. On the bright side, however, decentralized protocols can benefit from a strong supply of passive liquidity available on the chain and from the order flows that are excluded from centralized markets. The key problem that decentralized protocols need to resolve is how to minimize their order flow toxicity and offer efficient execution to non-arbitrage traders.
We suggest that this can be done by offering all of the following main features:
- Gradual taking of liquidity
- Gradual making of one-way liquidity
- Two-way liquidity
- Internal price discovery
Below we discuss in greater detail each one of these features and their potential implementation.
1. Gradual taking of liquidity
On centralized exchanges, large non-arbitrage traders can minimize their price impact costs by executing trades gradually over time. To compete for this order flow, decentralized protocols need to offer a similar cost minimization mechanism. In terms of the overall price impact, several small swaps executed over time should be cheaper to a regular trader than a large instant swap.
As we discussed in detail in part two of this series, to make order-splitting work, the protocol needs to be resilient: the AMM price and available liquidity must recover quickly after each uninformed trade. The problem for protocol designers is that it is generally impossible to determine whether a trade was initiated by an arbitrageur (in which case, its price impact should be permanent) or by a regular trader (in which case, it should be transitory). The protocol should provide incentives for other market participants — either liquidity makers or takers— to push the price quickly back to the efficient level after an uninformed trade.
In centralized exchanges, this job is done by liquidity makers: they can always post new aggressive limit orders improving the current bid-ask spread. It is not however clear whether the same approach can be fully and efficiently implemented on-chain since it requires an order book with a sufficiently small tick size.
The question then becomes: Can we still rely on liquidity takers for price discovery yet resolve the problem with resilience discussed in our second post? Recall that the problem arises when an informed trader moves the AMM price by a small amount, say five basis points, and it is inefficient for arbitrageurs to move the price back given that they would incur a 30 bps swap fee doing so. Our suggested solution is as follows.
Swap fees should be fully dynamic: declining over time and increasing in the price impact of recent swaps.
With this approach, if an uninformed trader moves the price up by five basis points, it may initially be inefficient for arbitrageurs to make the reverse swap. The idea, then, is that the cost of that reverse swap should be gradually declining over time. At some point, when the fee becomes sufficiently small, arbitrageurs will push the price back to the efficient level, and the uninformed trader will be able to continue with another small swap. While this approach can be implemented in many different ways, some form of a dynamic, price impact-based, swap fee appears to be prerequisite for a highly resilient decentralized market.
To summarize, if the protocol does not allow market participants to improve the after-fee bid-ask spread, then the AMM should do it on its own whenever there are indications that the AMM price is stuck at an inefficient level. The most important indication that the spread needs to be reduced is a low trading volume. Hence the AMM’s bid-ask spread needs to be shrinking over time and increasing in the price impact of incoming swaps.
2. Gradual making of liquidity
A major (and perhaps the cheapest) source of liquidity on centralized exchanges is limit orders of directional traders. As we discussed in parts one and three of the series, regular investors who do not have private information about prices often execute their trades with limit rather than market orders. They do so to avoid walking through the book and minimize their price impact. Surprisingly, none of the major existing DEX protocols provides a convenient mechanism for executing large trades by making liquidity.
Decentralized protocols should offer a way to contribute one-way liquidity, which would only be used by swaps of a single direction. Ideally, the conversion of one-way liquidity should happen at a predictable rate over time.
Consider the following scenario. Alice wants to sell some amount of ETH for USDC. This transaction is non-urgent, but she would like to minimize her execution cost by not walking through the book. One feature that a decentralized protocol could offer is for Alice to contribute her ETH as one-way liquidity. This liquidity would be used against the incoming USDC-to-ETH swaps but not the ETH-to-USDC swaps. In other words, it would be used only against the swaps of the direction opposite to that in which Alice wants to trade.
Preferably, the AMM should position one-way liquidity so that it is converted at a reasonably predictable rate (say, 50% over a few hours). This rate, of course, cannot be completely deterministic because it would depend on the fluctuations of the actual ETH/USDC rate, as well as the volume of non-arbitrage ETH buys. The positioning of one-way liquidity would be ideally automatic since, in contrast to centralized exchanges, it would be costly for Alice to constantly reposition her liquidity after each price move.
Directional traders with large, non-urgent volumes often provide some of the cheapest liquidity, and it is important for decentralized protocols to accommodate them.
3. Two-way liquidity
One thing that the Uniswap protocol has demonstrated very clearly is that there is a lot of interest in passive liquidity provision in DeFi. It is relatively difficult to fund a market-maker in traditional finance. In contrast, in DeFi everyone can invest in one now. Uniswap v2 (and its forks) managed to attract significant amounts of capital even with a relatively inefficient market-making algorithm. At the time of this writing, Uniswap v3 has close to $725 million in liquidity in one of its DAI/USDC pairs, which on average generates only a few hundred dollars in fees per day. This demonstrates there is a strong supply of passive liquidity available for market-making even at rather modest expected rates of return.
There is currently a debate on the optimal model of such liquidity provision. In one model, which we will call dealer-like, LPs provide funds to an algorithm that aggregates all of the available liquidity and uses it for market-making. LPs essentially acquire interest in the dealer and delegate all market-making decisions to it. In contrast in the model of Uniswap v3, which we label limit order book-like, LPs choose a range of prices in which their liquidity will be active. Since two LPs can decide to provide liquidity in different ranges, their positions become non-fungible. So far, the main advantage of the LOB-like model has been its ability to accommodate concentrated liquidity. However, currently algorithms are being developed to incorporate liquidity concentration in the dealer-like model as well. Examples include DoDo’s PMM (DODO) and Maverick’s AMM (Maverick Protocol), but see our qualifications on these protocols in the next section.
A detailed comparison of the two models of two-way liquidity provision is outside the scope of this post. Let us just point out that the LOB-model leaves passive LPs more power to control their losses but that comes at the expense of potentially lower fee revenues. In Uniswap v3, once a position gets out of range it stops generating fees until the price returns to its range. In the dealer-like model, the liquidity can always be automatically shifted closer to the current price. Passive LPs can then continue earning fees but also risk a higher (and no longer impermanent!) loss if the price suddenly returns to the original range.
A useful feature to attract more liquidity in the dealer-like model is to allow LPs to make their contributions in a single token. Then, LPs who want to hold some asset, say USDT, but are afraid that it might go down in value relative to some other asset, say ETH, would be able to contribute two-way liquidity but only in USDT. If that token indeed declines relative to ETH, they should expect to make positive returns relative to holding USDT alone. In contrast in Uniswap v3, LPs who contribute liquidity only in the declining token are unlikely to see any returns since their position will simply stay out of range.
Decentralized protocols should accept two-way liquidity either in the dealer-like or LOB-like model. If in the dealer-like model, the AMM moves liquidity to follow the price, then LPs should be able to provide two-way liquidity in a single token.
Ultimately, we believe that both models of bidirectional liquidity provision are sustainable. The LOB-like model offers more return opportunities for active LPs as long as the transactions are cheap and the risk of front-running is low. On the other hand, when LP transactions, such as repositioning of liquidity, are costly or the risk of front-running is significant, the dealer-like model is more promising as it requires less active management. Crucially, however, the dealer-like model is only as good as its underlying market-making algorithm, which brings us to the last point of this post.
4. Price discovery
An internal price discovery mechanism is absolutely essential for minimizing the order flow toxicity of decentralized protocols. Protocols that rely on decentralized oracles for price discovery quickly become a front-running free-for-all. (And protocols that use centralized oracles are essentially centralized.) Internal price discovery is also generally faster than that based on external oracles and thus leads to stronger market resilience.
There should be an internal mechanism for price discovery, resistant to market manipulation attacks. This is particularly important if liquidity is managed in a dealer-like fashion.
Internal price discovery gets more complicated if at least some of the liquidity is provided in a dealer-like fashion. If the AMM moves liquidity in response to the incoming trades, then arbitrageurs might sometimes get incentives to trade against their private information and move the price away from the efficient point. Such bluffing can fool the AMM to offer a large amount of liquidity for sale at inefficient prices, which can justify for the arbitrageur their initial trades in the wrong direction. This strategy is akin to spoofing in traditional finance with the exception that the price is initially manipulated with bona fide swaps. Preventing such attacks in a decentralized protocol is complicated by two additional factors: (i) the AMM behaves in a manner completely predictable to the arbitrageur, and (ii) the arbitrageur can also manipulate the AMMs liquidity prior to the attack.
Perhaps for the reasons discussed above, we do not currently have a protocol with dealer-like liquidity and fully internal price discovery. DoDo uses external oracles hoping that front-running is not a serious issue. As of the time of this writing, Maverick has not released the details on their price discovery mechanism. This issue is less important for Uniswap v3 since its AMM does not position liquidity — this job is left to LPs. It remains to be seen if an efficient AMM can be developed with internal price discovery and automatic liquidity positioning.
Conclusion
In this series of posts, we discussed some of the main issues with decentralized exchange protocols and suggested features that can help minimize their order flow toxicity. If you made it this far, you will be interested in our next series, in which will try to build a simple AMM implementing the features discussed above and many more.
Next series: Designing a low-toxicity AMM
