MEV Potential on Chainflip

In this article, we aim to explore the MEV profile of the Chainflip AMM in comparison to existing DEXes, using Uniswapv3 as the benchmark comparison to help explain.

Defining MEV

MEV is broadly defined as methods of extracting value from users conducting transactions, in this case in an on-chain market context. Typically, MEV relies on bribing block producers to include and order transactions within a block in a certain way to benefit the actor. Typical examples of MEV include:

• Frontrunning (Frontrunning)
• Backrunning (Arbitrage)
• Sandwiching (JIT Liquidity)

The underlying logic of the Chainflip JIT AMM is based on Uniswapv3, but that is where the similarities end.

The JIT AMM exists in a totally different execution environment to Uniswapv3 and thus requires a complete analysis to understand where (if any) MEV potential exists. None of the existing MEV strategies work out of the box on Chainflip, and we will explain why here.

Breaking Typical MEV Methods

In Chainflip, all swaps are triggered by events with a non-trivial delay. Chainflip also witnesses ingress transactions by block and processes swaps made in the same block as one, meaning that Chainflip effectively ignores transaction ordering of external chains and thus eliminates MEV potential derived from transaction ordering externally. This includes typical frontrunning and backrunning of swaps in the same block, as the actor always gets the same price as their target.

We have not identified any way to profit from joining a bundled trade. Assuming that the liquidity provisioning is rational, all swappers, if anything, would want to avoid being bundled with other swaps, as that would reduce the liquidity requirements for their trade overall, and thus potentially offer a better rate. An actor could join the bundle of their target and then perform a backrun, but then they are exposed to other swaps that are also bundled and a time delay for LPs to respond to which will more often than not make it unprofitable.

Furthermore, the State Chain is a “virtual” accounting layer that executes swaps automatically without requiring secondary actions by the user. The intention is to force the deterministic ordering of transaction execution in blocks such that order updates and other extrinsics are executed, followed by swaps in a defined order, followed by signing requests. As such, all MEV strategies which rely on precisely ordering the execution of these different steps are categorically not possible in this application-specific blockchain environment. You can not bribe Chainflip validators to re-order swaps or liquidity updates in any way that gives an advantage to a particular actor. Such reordering would make the block invalid, and the Validator loses rewards and can potentially be slashed for missing an authorship slot.

The one exception to this might be a block producer delaying the witnessing of certain deposits by not including vote transactions in the block that they get to produce, thus excluding the swap as well, but there is no clear way to extract value by doing this. It would also be very easy to spot this behaviour, and solutions to prevent or penalise this are not hard to imagine.

This inherent MEV protection is one of the many benefits of running a DEX in an application-specific environment. This level of control and purpose-driven design is only possible when the consensus itself is customisable.

Liquidity Frontrunning-as-a-Service (JIT Liquidity)

The JIT AMM fundamentally relies on JIT liquidity provisioning to benefit the user. This type of JIT provisioning has occasionally been described as a “sandwich attack” in Uniswapv3 because it disadvantages other LPs by offering the user a better price on their swap than existing liquidity in the pool. We think that is not the correct characterisation, as the product’s purpose is capital-efficient swapping, and JIT liquidity serves that function extremely well.

In Chainflip we make JIT liquidity provisioning extremely easy by eliminating the need to construct these private and expensive “sandwich” transactions, and simply allow liquidity providers to submit maker-only limit orders which swaps are executed against, alongside static pool liquidity. It means that every swap, no matter how small, can benefit from JIT liquidity provisioning, rather than just the swaps big enough to justify the extreme costs of JIT liquidity provisioning through sandwich transaction bundles on Uniswap.

In each block, all extrinsics are processed before swaps are processed, meaning that all liquidity providers have an equal chance to create a competitive limit order between each 6 second block. There is no advantage to submitting your order earlier or later than other LPs, unless you wish to resubmit an order and improve your price based on observed competitive order changes in the mempool. Because all incoming deposits and scheduled swaps are known, liquidity providers can also predict the swap volume before quoting and offering a price through their orders, limiting the need for aggressive betting. LPs won’t quote more than they are willing to offer, and so should do so consistently, as liquidity orders are not free to update. Regardless, backrunning other LPs to offer the user a better price in the same State Chain block is a desirable quality of the system for the user.

The one way that an LP could bribe a Validator to benefit themselves is to get the block producer to withhold the liquidity updates of other LPs during their block. The statistical likelihood of this being successful is quite low, but if widespread enough could pose a potential issue in the market assumptions of the protocol. Based on our estimations, we don’t think it will be worthwhile developing the software necessary to pull this off given the slim margins in a competitive liquidity market, but we could be wrong. In order for this to be profitable, the delta between prices of the limit orders set in the previous block and pool range order liquidity would need to be far enough away from the “corrupt” LP’s order that the value of the profit is enough to bribe the validator with enough left over to make it worthwhile.

Once again though, Validators should be very careful about this behaviour as it is trivial to detect, and with the development of commit-reveal schemes present in other networks, could be permanently mitigated. We do not expect to see this in the wild but have set up alerts to detect it in any case.

Overall, the JIT AMM liquidity system is much more suitable for on-chain trading than existing DEXes in terms of its ability to reliably offer users good swap rates without being subject to MEV potential.

Partial Swaps & Slippage Limits

In Uniswapv3, a slippage limit exists such that if a swap drops below a user-specified rate, it is aborted. This feature is also implemented in the JIT AMM, and Fill-or-Kill has been a mandatory feature since 1.8, which retries and refunds users if swaps fall below a user defined minimum rate. This serves as the ultimate backstop to protect users.

Market Breaking Scenarios

It is worth discussing what happens when the assumption that competitive liquidity providers are operating at any given time breaks.

There are a few reasons why this might occur:

• The liquidity providers have run out of liquidity for one side of the trade. For example, someone selling massive volumes of BTC could drain the LPs of their USD supply, thus making them unable to bid competitively on the BTC.
• The LPs all collude to under-quote the price, thus giving a bad rate. This also applies to scenarios with a single LP.

The first scenario is partially addressed through our front-end quoter system, which collects quotes from active LPs and also compares it with the pool liquidity to estimate a rate based on a provided swap input. In scenarios where LPs are unable to quote a good rate, the user will see that in the calculation and can choose whether or not to proceed. These rates are not guaranteed though, but the same can be said for any DEX subject to time delay or MEV.

It is also possible to “backrun” swaps under these conditions by making a counter-trade to balance out the assets held by LPs and benefit from an unbalanced pool with arbitrage. Of course, the imbalance would need to be significant enough to warrant the price risk incurred during the scheduled swap delay, but such trades are possible and would help mitigate the first scenario.

Summary

This article should serve as a reference for anyone looking to understand the potential MEV profile of the Chainflip JIT AMM in reference to existing and novel MEV strategies. We welcome anyone interested in the subject to contact us to discuss it in detail if you have any thoughts or future ideas that you think might be relevant to this topic. As the protocol spends more time in the hands of real users and providers, we expect that new ideas will emerge which can add to this conversation.