Friday, November 22, 2024
Home > News > Ethereum News > Just-In-Time Liquidity: How MEV Can Enhance DeFi on Ethereum

Just-In-Time Liquidity: How MEV Can Enhance DeFi on Ethereum

What is MEV?

Behind the scenes of most major blockchains, shadowy super-coders and the bots they build are using the transparency of blockchains and the transaction fee market to their advantage. By watching a database of all pending and unconfirmed transactions called the mempool, the bots are able to pay higher transaction fees to slip in their own transaction in an order that is profitable, often at the expense of decentralized finance (DeFi) users.

This article originally appeared in Valid Points, CryptoX’s weekly newsletter breaking down Ethereum 2.0 and its sweeping impact on crypto markets. Subscribe to Valid Points here.

According to the Ethereum Foundation, Maximal Extractable Value (MEV) is the catch-all phrase for “the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding and changing the order of transactions in a block.” More specifically, arbitrage, liquidations, frontrunning and sandwich attacks are all forms of MEV in its current state.

MEV is not inherently bad and exists in any transaction fee market-driven chain with open access to the mempool. Decentralized exchanges and lending protocols even rely on MEV to arbitrage pools and liquidate undercollateralized loans in a competitive and efficient manner. The ability to order transactions within a block also casts a dark cloud over MEV because searchers are able to front run buy orders just to simultaneously sell on the trader after the order goes through. Searchers may earn an extra percent on the transaction, but it is completely at the expense of the trader who overpaid for the asset they received.

Concentrated liquidity and MEV

Flashbots, a development organization focused on mitigating the negative externalities of MEV, co-hosted a Twitter Spaces with the Uniswap team in late January to talk about “Just-In-Time” (JIT) Liquidity Provision, an increasingly popular MEV strategy. Just as it sounds, MEV “searchers” scour the mempool for large pending exchange swaps and provide liquidity to the associated pool before the swap is confirmed. This allows the searcher to gain a large cut of the trading fees only to subsequently pull that liquidity out in the same block.

This MEV tactic has proven more profitable on concentrated liquidity decentralized exchanges like Uniswap v3. Version 3 allows liquidity providers to supply capital within certain price ranges, theoretically improving trading depth around current prices and increasing fees for active liquidity providers. MEV searchers deploy their LP within a tight price range of the trade, taking up a significant amount of the trading fees and making the transaction worthwhile.

The strategy employs a non-atomic approach to MEV where searchers are exposed to delta risk, the chance that an asset drops in price. Therefore, the searcher must have some short-term outlook on the market because their portfolio was rebalanced from the trade, and future price volatility could quickly take away the profits made via trading fees.

Potential benefits and drawbacks of increasingly sophisticated MEV

The Uniswap team foresaw the potential of JIT liquidity on v3, but wanted to see how the strategy affected traders and liquidity providers in actuality. Should the tactic come to be a net negative for the protocol’s users, Uniswap considered implementing capital punishments for liquidity providers that deposited and withdrew liquidity in the same block. However, JIT liquidity has been largely positive for traders who have seen increased liquidity in their trading range, minimizing slippage.

The product lead at Flashbots, Robert Miller, posted an insightful thread on JIT liquidity and an on-chain reference example. Miller highlighted the benefits JIT liquidity brings to traders and how it differs from sandwich attacks, even while it employs a similar strategy. Furthermore, LPs have been able to remain profitable even despite JIT liquidity. Because the MEV searcher cannot utilize this strategy in a single atomic transaction, it is not risk-free and may not fit the bots risk profile.

A large concern is that MEV will continue to benefit the few at the expense of everyday DeFi users. Passive liquidity provision will continue to become more difficult if JIT liquidity strategies prove profitable, and trading on DEXs will be less desirable if users are being frontrun and sandwich-attacked. We run into some of the same problems as we see in traditional finance, with order flow selling and high-frequency trading.

However, at both the protocol and application level MEV can and is being mitigated. Flashbots has brought the misunderstood sector to light and is building products to combat the drawbacks felt by everyday users. For example, an off-chain marketplace where searchers can compete for transaction order ensures that on-chain gas wars become less likely. Over the next several months we may get a clearer picture of who is affected by MEV and how users can protect themselves.

Pulse check

The following is an overview of network activity on the Ethereum 2.0 Beacon Chain over the past week. For more information about the metrics featured in this section, check out our 101 explainer on Eth 2.0 metrics.

(Beaconcha.in, BeaconScan)

Disclaimer: All profits made from CryptoX’s Eth 2.0 staking venture will be donated to a charity of the company’s choosing once transfers are enabled on the network.

Validated takes

  • A Coinbase engineer has assured users the exchange is working on a solution for staking service client concentration. BACKGROUND: The conversation around client diversity continues to heat up as Prysm-style validators take an increasingly large cut of block production. Community members look to hold staking providers like Coinbase and Kraken accountable for the health of the network. Large exchanges are in control of around 30% of validators and have heavily leaned on the usage of Prysm, adding unnecessary risk to the network.
  • The Ethereum Foundation released a breakdown of validator distribution thresholds in light of client diversity issues. BACKGROUND: Ethereum’s multi-client nature allows the network and validators to protect themselves against software failures. Ideally, no client would be run on over 33.3% of the network’s validators, assuring that a bug within any of the several clients could not disrupt finality. However, if a client makes up over 66.6% of the network like Prsym, it has the potential to finalize bugs and cause avoidable chain splits down the road, financially punishing anyone using the majority client.
  • OpenSea ended January with over $4.9 billion in NFT trading volume on Ethereum for the month. BACKGROUND: Non-fungible token trading came back with a vengeance in January, with OpenSea volume 44% higher than the previous most-active month. While we are only one month into the new year, OpenSea is on pace to bring in nearly $1.5 billion in revenue during 2022. The figure is even more impressive when accounting for the $900 million in volume done on recently launched platform, Looksrare.
  • Blockscan introduced off-chain wallet-to-wallet communication on Etherscan. BACKGROUND: Communication between wallets has been very difficult and has required on-chain transactions in the past. Blockscan allows wallet users to remain anonymous but also to reach out and respond to other wallets within the Etherscan website.

Factoid of the week

https://explore.flashbots.net/

Open comms

Valid Points incorporates information and data about CryptoX’s own Eth 2.0 validator in weekly analysis. All profits made from this staking venture will be donated to a charity of our choosing once transfers are enabled on the network. For a full overview of the project, check out our announcement post.

You can verify the activity of the CryptoX Eth 2.0 validator in real time through our public validator key, which is:

0xad7fef3b2350d220de3ae360c70d7f488926b6117e5f785a8995487c46d323ddad0f574fdcc50eeefec34ed9d2039ecb.



Source