Grant Application: Research on uncaptured backrunning opportunities for privately submitted transactions

Grant Title:

Research on uncaptured backrunning opportunities for privately submitted transactions.

Author:

EigenPhi

contact at [eigenphi.io]

About You:

As a technology company focused on analyzing and researching transaction data on the blockchain, EigenPhi is committed to providing the best analytical tools for tackling emerging financial problems in the blockchain world with state-of-the-art data science approaches. Especially when it comes to economic attacks on protocols, our analysis based on real-time liquidity - token flow data - will allow us to draw transparent and credible conclusions and assist in effective decision-making.

We have launched a token-flow-oriented data platform, EigenPhi, with dashboards covering the main MEV types (Arbitrage & Sandwich), Lending, Liquidation, and Flashloan, and EigenTx, an on-chain transaction analysis and visualization tool to improve the efficiency of data analysis for professional DeFi users.

To further leverage the value of our tools, we use them to investigate the problems DeFi protocols concern and specific cases that occur, and we expect to benefit stakeholders and interested parties as a result.

Additional Links:

Website: eigenphi.io

Twitter: EigenPhi

Grant Category:

MEV Data research

Grant Description:

MEVblocker is leading the market of MEV-protection RPCs.
It has generated the most amount of rebates to its users, at the time of writing >800 ETH.
Unfortuntaely some users and projects are losing on the opportunity to re capture their transaction’s back-running opportunity and therefore the value is captures by MEV bots instead of being captured by the user in the form of a rebate.

This grant is offering to conduct an analysis aiming to quantify the value of “lost back-running value” in a given set of transactions privately-submitted by Maestro and Unibot.

  • Dataset: list of transactions made from the router contract addresses associated with Maestro and Unibot, and submitted through Flashbots. Current analysis will focus on transactions made in the month of November 2023.
  • Methodology:
    • Every AMM pool interaction contained within the transactions of the data set will be identified
    • Backrunning resulting from the MEVshare auction will be detected and ignored
    • The pool will be monitored for backrunning happening in the same block and the following block.
    • The value of the backrunning trades will be counted

Grant Goals and Impact:

The analysis results will help to compare the efficiency of capturing backrunning rebates by MEVblocker vs MEVshare.

Milestones:

  • Conduct the analysis
  • Share numeric results and visualizations with the CoW team
  • Potentially - collaborate on publishing the results in a shared post/paper

Grant Timeline:

10 working days

Funding Request:

2000 xDAI

Gnosis Chain Address (to receive the grant):

0x20Fd2beC717c8544f209C4c50EE31F8bDaC134B4

3 Likes

Thanks for your proposal! Interested to see your research on MEV Data and see how it can help improving MEVblocker. I’m supporting this proposal.

Agree with @Chim9 . This is valuable research and will help inform DAO strategy.

Hi Guys, here is the final result of the grant. Please feel free to leave your comments and questions.

Uncaptured MEV Analysis of Private Transactions for CowSwap

  • Time Period: Nov 1, 2023 to Nov 30, 2023
  • Router Contracts Included in the Analysis: Maestro, Unibot, 0xAPI
  • Number of Privately Submitted Transactions via Flashbots: 649,309
  • Number of Transactions Found as Signal Transactions in the Dataset: 5,486
  • Number of Arbitrage MEV Transactions Triggered from Signal Transactions: 5,828

Data Results

All the CSVs can be downloaded here: 2024 Result: Uncaptured MEV Analysis of Private Transactions for CowSwap - Google Drive

  • All_Private_Transactions_Maestro_Unibot_0xAPI.csv
    • All privately submitted transactions via Flashbots routing from Maestro, Unibot, 0xAPI, queried from https://dune.com/queries/3288196/5504857
    • Router contract address:
      • Maestro: 0x80a64c6d7f12c47b7c66c5b4e20e72bc1fcd5d9e
      • Unibot: 0x3999D2c5207C06BBC5cf8A6bEa52966cabB76d41
      • 0xAPI: 0xdef1c0ded9bec7f1a1670819833240f027b25eff
  • Signal_Transactions_Raw.csv
    • All signal transactions triggering arbitrage opportunities found in the All_Private_Transactions_via_Flashbots.csv
    • 5,828 records, including duplicate user transactions as different signal transactions for multiple arbitrage transactions.
    • Columns
      • User’s transaction: user_tx, block_number, user_tx_index, project
      • MEV transaction: mev_type, mev_tx, revenue, profit, cost, mev_block_number, mev_block_timestamp, mev_tx_index, from_address, to_address, builder, builder_label, builder_reward
  • Signal_Analysis_Results.csv
    • Overview of the revenue, cost, profit, and counts of arbitrage transactions, as well as the counts of signal transactions

Signal Transactions

  • Signal transactions refer to transactions that trigger or create opportunities for MEV transactions. Specifically, we define “signal transaction” as the last transaction involving any of the pool’s balance changes before the arbitrage takes place.
  • A single user’s transaction in the order flow may trigger multiple MEV opportunities and become signals for different types of MEV.

Arbitrage Classification Definition

  • bundled backrun arbitrage in the same block: refers to when the arbitrage transaction and the user’s privately submitted transaction occur in the same block height, and the arbitrage transaction immediately follows the user’s privately submitted transaction, meaning the transaction index of the arbitrage transaction equals to the transaction index of the user’s privately submitted transaction plus one.
  • unbundled back-run arbitrage in the same block: refers to when the arbitrage transaction and the user’s privately submitted transaction occur in the same block height, but they are not atomically bundled together, i.e., the transaction index of the arbitrage transaction is larger than the transaction index of the user’s privately submitted transaction plus one.
  • arbitrage at top of next block: refers to when the arbitrage transaction occurs as the first transaction in the next block height after where the user’s privately submitted transaction occurs, i.e., the block number of the arbitrage transaction equals the block number where user’s privately submitted transaction occurs plus one. The transaction index of the arbitrage transaction is 0 in the block.
  • arbitrage not at top of next block: refers to when the arbitrage transaction occurs in the next block height (but not as the first transaction) after where the user’s privately submitted transaction occurs, i.e., the block number of the arbitrage transaction equals to the block number where user’s privately submitted transaction occurs plus one. Still, the transaction index of the arbitrage transaction is larger than 0 in the block.
  • other arbitrage: refers to other arbitrage transactions that occur not in the same nor in the next block, i.e., the block number where the arbitrage transaction happened is larger than the block number where the user’s privately submitted transaction occurs plus one.

Q&A

  1. Methodology for classifying arbitrage value as “revenue/cost/profit”

We calculate the MEV value as “revenue/cost/profit” based on the balance change of all addresses in the identified arbitrageur accounts (usually the “from” and “to” addresses of the arbitrage transaction, as well as some fund collection addresses).

  • revenue = ∑ ((token_in_amount - token_out_amount) * token_price_in_usd)
  • cost = (gas_fee + miner_tip) * eth_price_in_usd
  • profit = revenue - cost;
  1. What is included in “Other arbitrage”?

They are arbitrages happening in the following blocks (but not in the same or the next block), i.e., the block number where the arbitrage transaction happened is larger than the block number where the user’s privately submitted transaction occurs plus one.

  1. Which router address is used to classify “0xAPI” transactions?

0xdef1c0ded9bec7f1a1670819833240f027b25eff

1 Like