JIT liquidity, maker/taker reversal, and the Carbon protocol

JIT liquidity has been a heavily discussed topic in the last few months, to the point that Dan Robinson, the key designer behind Uniswap v3, dedicated his valuable 15 minutes at Ethereum Paris to this topic. The most interesting part of this phenomenon is that it is an emerging property of the system — Uniswap v3 was not at all designed to operate that way. This week, Carbon was released (full disclosure: whilst Mark Richardson deserves 100% of the credit for designing Carbon, I have been involved in the process), and Carbon is taking JIT liquidity’s maker/taker reversal to the next level.

Before we go into details, we define a few terms that are important in the remainder of this note

• JIT liquidity is the phenomenon that liquidity is contributed only after a trade order has been submitted to the mempool, and the contribution is executed before the trade is executed, diverting a significant amount of the trade fees to the JIT liquidity provider
• A maker order is an offer to the market to enter into an exchange of tokens at a fixed price; this offer is open to the market, and can be executed by anyone up to the point it is either cancelled or filled
• A taker order is the action of executing (or at least trying to execute; the maker order may disappear before execution) an existing maker order

In traditional financial markets, market makers usually “make markets” by displaying maker orders: they present their customers a bid and and an ask price, either permanently and updated in real time on an electronic system, or upon request. The latter is less and less common, but it is still important for illiquid assets where updating the prices in real time is too expensive, and where stale price quotes expose the market maker to undue risks.

Traditional AMMs operate in the same way. In fact, traditional AMMs are the ultimate “makers”: they operate off a fixed (bar liquidity additions and withdrawals) supply and demand curve that is determined by the AMM’s invariant function (see theammbook.org, chapter 3.2 for details).

Uniswap v3, JIT liquidity and the maker/taker reversal

A few months after Uniswap v3 had started operating, this changed with the arrival of “JIT market makers”. They operate in the following manner: the monitor the mempool, and whenever they see an attractive Uniswap v3 transaction — often a transaction at a price that they can arbitrage against another venue, in a size sufficiently large to pay for the associated costs — they add liquidity into the respective bucket(s). Detailed operations are roughly as follows

1. An attractive transaction is identified in the mempool, ie a transaction that can be arbitraged in the mempool; say it is buying ETH for USD
2. A transaction for the arbitrage transaction is prepared, but not yet been submitted to the mempool; this is buying USD for ETH
3. Ditto a large liquidity contribution into the respective bucket, ideally giving the JIT operator close to 100% of the liquidity in the bucket
4. Ditto a loan for ETH and USD to finance (2) and (3); this loan must be secured against a pool of assets as flash loans do not work in this scenario
5. Ditto a liquidity withdrawal that undoes (4)
6. The transaction is submitted in an atomic MEV-package in the order flash loan (4), liquidity provision (3), arbitrage transaction (2), original transaction (1), liquidity reversal (5)

Net/net that leaves the JIT liquidity provider with the arbitrage profits as well as almost 100% of the fees. Alternatively, the JIT liquidity provider may hold inventory like a traditional market maker, in which case step (2) is replaced with an inventory transaction.

The important effect of what is happening here is what we refer to as the maker / taker reversal: in this scenario, the original makers (the LPs of the AMM) have been pushed out of the deal — their collateral is not (significantly) touched, and they don’t receive any (significant) fees. The original taker — the trader submitting the transaction — has become a maker: they are giving the JIT liquidity provider the option to swoop in as the ultimate taker.

Now there is a rather intensive discussion going on whether, in aggregate, JIT liquidity provision is good or bad. I do not want to weigh into this debate other than (a) saying that whether good or bad, it is here to stay as this particular bell cannot be unrung, and (b) discuss its uncontroversial consequences:

1. For liquidity providers, this is generally bad; at the very least, on the same amount of liquidity (and IL) they receive less fees; also there is a risk that they mostly get the “toxic” flow that the JIT MMs do not want
2. For traders, in the first order this is good: they were willing to trade at a certain slippage level, and the JIT liquidity has reduced that slippage, possible substantially
3. For JIT MMs, this is unquestionably good, otherwise they would not engage in those transactions

As second order effect, it is possible that because of (1), the liquidity providers withdraw entirely from the market. In this case the market collapses, which ultimately is bad for (2), and not great for (3) who end up without a previously profitable business.

The maker/taker reversal in Carbon

Carbon, by design, exhibits the same maker/taker reversal we see in JIT liquidity provision, except that there is no liquidity provider who is getting hosed. We will provide here a short overview of how Carbon works. For more details, please see Carbon Litepaper and Carbon Whitepaper.

In Carbon, end users contribute their orders into an active online order book. Those orders can be at-the-money or out-of-the-money, or even in-the-money when immediate execution is paramount — this is entirely up to the user. Market makers (and any other market participants) can then swoop in and execute the orders they like, typically once those orders have moved into the money.

This keeps all of the good parts of the JIT flow above, but it offers a number of important improvements:

• Carbon no longer relies on an initial liquidity providers, which in turn means the system cannot be brought down by them leaving
• Users do not risk being subject to a sandwich attack (because makers can’t be sandwiched), and neither are market makers, due to the asymmetric liquidity in Carbon (see section 3.4 of the Whitepaper)
• User orders stay live for as long as the user wants, either until canceled or filled, or with a time limit attached

Conclusion

We have argued here the JIT liquidity provision — an emergent property rather than a design feature of Uniswap v3, is here to stay, but that it comes at a systemic risk when the non-JIT liquidity providers get too bad a deal. We have also shown that the Carbon protocol by design creates a transaction flow very similar to JIT liquidity provision, except that it no longer relies on the liquidity providers that get the bad end of the deal in a JIT liquidity context, and therefore the system is by design not at risk of them leaving. It will be interesting to see how the systems compare in real life when the Carbon system becomes live.

JIT Liquidity

Image credit: pexels:water-drop-220211