Miner-Extractable Value, Oracle Frontrunning, and the Rise of Arbitrage Bots

In this thread, we attempt to further the discussion of a key problem in the oracle category and evolve our understanding of the space where research work has not yet answered the specific problem or question being considered.

As smart contract platforms such as the Ethereum blockchain continue to accelerate in demand and blockspace becomes increasingly scarce, new dynamics have arisen that allow specific network participants to capture value from unsuspecting users. As explored in a recent study, “Flash Boys 2.0”, this takes the form of what is known as Miner Extractable Value (MEV), which describes the opportunities that blockchain miners have to extract value from users by manipulating the order of transactions and their inclusion when mining blocks.

While miners represent the lower bound of who can profit from MEV (as they ultimately control the ordering of transactions within a block), the most common form of MEV seen today in the wild is from arbitrage bots that monitor the transaction mempool for profitable opportunities and frontrun specific transactions such as trades on a decentralized exchange (often by placing a buy order with a higher gas price ahead of the trade and selling afterwards). As a result, the original trader experiences a higher amount of slippage than normal and the arbitrage bot profits from the difference, corrupting the trading experience and siphoning value directly from users. Additionally, in the worst of cases, this can cause chain instability if the profit from MEV is higher than the block reward as miners are incentivized to orphan blocks and take the profits for themselves.

MEV tactics have also gotten more advanced in recent times, as documented in a recent article titled “Ethereum is a Dark Forest” by Dan Robinson. We are now seeing the use of generalized frontrunners that don’t look for specific transaction types (like a trade on Uniswap), but instead monitor and execute all transactions in the mempool to catch any opportunity where it is profitable to frontrun and/or replace the transaction with a copy using a higher gas price with their own address, essentially replacing the transaction and taking the profits for themselves. This has not only created difficulties for white hat hackers attempting to save user funds, but also directly raises the network’s transaction costs as arbitrage bots kick off gas price auction wars due to miners ordering transactions in a block by the highest gas price.

This generalized frontrunning of transactions is not only an issue for simple trades on decentralized exchanges but also presents an issue for other applications such as derivatives platforms which rely upon price oracle updates. These oracle updates, which also occur as on-chain transactions that go through the mempool, can be frontrun to extract value from liquidity providers within certain applications (e.g. placing a buy order on a perpetual futures contract before a price update occurs that increases the price, essentially creating risk free arbitrage). Some decentralized applications such as Synthetix have implemented a fix to this issue through fee reclamations/rebates, which create time delays in order to retroactively adjust the slippage of the trade if an oracle update occurs within that time period. However, such fixes break some forms of atomic composability and are not applicable in all situations. As a result, projects using price feed oracles also need to consider the issues caused by MEV.

While the concept of MEV is now more commonly discussed, there is still an open conversation to be had regarding potential solutions and the implications for applications and their users. Some questions include:

  • What percentage of Ethereum’s bandwidth is currently wasted due to the gas auction wars caused by frontrunning bots?
  • Are there backwards-compatible solutions to generalized frontrunning and MEV that do not require a network level hard fork to achieve?
  • How can users protect themselves from being exploited from MEV and frontrunning bots when engaging with existing smart contract applications?
  • Do any on-chain or off-chain “transaction ordering” services exist to prevent MEV and frontrunning?

I am curious about the urgency of this issue, particularly as DeFi continues to increase in total value locked, as well as any solutions that can be implemented today that can prevent the extraction of value from these arbitrage and frontrunning bots altogether.


In my opinion, MEV represents one of the most critical issues that needs to be solved to ensure smart contracts are practical and secure for mass adoption. I’ve seen different proposed solutions, like MEV auctions, but I fear that such implementations would only be re-centralizing control of transaction ordering and wouldn’t actually prevent frontrunning from occurring at all, ultimately providing no benefit to the end users or the slippage on their trades.

While it’s true that oracle updates can be frontrun in certain cases, I also think oracles can provide the solution to MEV as well. Chainlink proposes a solution called Fair Sequencing Services (FSS) where a decentralized network of oracle nodes are used to order transactions on a per-contract basis using a custom policy, such as ordering transactions by the relative time each hits the mempool. The core advantage of FSS is that not only does it prevent miners and arbitrage bots from manipulating transaction orderings, but it also can be implemented in a backwards-compatible manner, requiring no changes to the layer 1 blockchain. Additionally, it can be implemented in different ways such as monitoring transactions in the blockchain mempool itself (meaning user experience would be the same as today) or allowing users to send their transaction directly to the oracle network, providing a meta-transaction type service which can additionally save on gas costs by batching transactions. Such a solution can also be used to ensure oracle updates are prioritized before any user trades take place, preventing oracle frontrunning all together. This implementation demonstrates how oracles go beyond secure data delivery and ensure the fairness of the application itself.


This seems to be an extremely important and relevant issue, especially in light of the recent coordinated movement of capital via reddit. If MEV becomes a common practice, it is tantamount to the traders who had the closest proximity to Wall Street having a trading advantage due to T1-line latency. If arbitrage bots can manipulate order of transactions with the compliance of the miners, the market becomes susceptible to sybil attacks as well as coordinated buying attacks that could also come in the form of network spam attacks.

There would not seem to be any decentralized solutions to this problem that do not ultimately return to centralized queues, but I am still looking to see if any projects have been able to come up with a viable solution. Many have claimed to have solved this problem, but the solution fails under stress testing.


I think this approach is the most ideal solution as it won’t require a hard fork in order to implement, but can be done on a per contract basis or even to order transactions for an entire layer 2 network like a Rollup. I also like the idea that is brought up within that post regarding encrypting the transaction first, having the oracles commit to a specific transaction order, and users revealing what the transaction was only afterwards. This can ensure the oracles truly cannot manipulate the order, at least not in a way that could benefit a specific actor, unless there was additional context leaked about the transaction. It also allows for applications developers to have much more control over who is ordering their transactions rather than leaving it to the unknown miners and arbitrage bots. It seems that would provide much more accountability.

Yes, agreed I think as the issues of the traditional market becomes more well understood to more people, there will be a large push toward fair market infrasture that doesn’t give any advantage to any specific user by design. There is a large design space still to be explored in the MEV area. Though I do think using oracles provides a promising solution that could be used to order the transactions. You could consider it a shifting of MEV simply to another actor, but if the transactions are based on a commit and reveal scheme as well as the oracle’s reputation on the line, I think it would alleviate much of the issues seen today with MEV. However, I am interested to see Chainlink FSS running in-production to see how it handles a real world situation.