ERROR:__main__:{'code': -32000, 'message': 'first run for txIndex 275 error: insufficient funds for gas * price + value: address 0x9D8e2dc5615c674F329d18786D52A F10a65Af08b have 241395854351228173 want 241436981652380070'} Halts at block: https://etherscan.io/block/15538730 Tx causing the break (payment from block builder to fee receipient): https://etherscan.io/tx/0xdc8a049e7a122eebd33833627bcb1c2dc0fa57515d7273d70b73a742753f9d71

Given the limited capacity we have, it’s best to push mev-inspect-py and the dashboards depending on it to a contributor / community maintained work stream. We would like to give a grant for the grantee to complete the following tasks in the next 2-3 months (in order of priority): Debug and fix critical bugs that stop the listener from moving forward Currently, we modified it (only in prod) to skip over blocks with errors as a hacky fix but ideally we fix issues that cause it to halt in the first place Ensure mev-inspect data <> dune export tool works Currently, as long as the listener is running, it exports that data into dune’s s3 but like mentioned above, if it stops so does the export tool Create a dashboard on Dune that looks similar to mev-explore as an example to showcase how the community can use the data to create dashboard. (we will deprecate mev-explore after this, and point any post-merge graphs to this Dune dashboard)

TBD What are some good heuristics to identify "arb flow" inspect can pickup arb bots that execute atomic complete swap cycles, compile their addresses for any given pool and filter that out as arb flow? but what about stat arb? are single swaps that take advantage of deviation from external "true price" to be accounted for as well? how does this change for assets that don't exist on CEXs or just have a single pool on-chain (all flow is non-arb flow?) What does arb/non-arb volume breakdown for any given pool tell us?

Design goal: Let people delegate their funds (stables/ETH) and donate the yield Plug into as many yield sources w/ sufficient TVL Something like https://rdai.money/, more flexible Proposed Architecture: accept arbitrary token -> swap for stablecoin -> tokenize stablecoin 1:1 -> deposit stablecoin into vault -> yToken held by proxy -> bot harvests yield and sends to donation add For ETH, BTC and stables

Primer Process Aside from the EOA initiating the transaction itself, we check for balance changes for the contract (in the to field of the tx) that executes the arb/liquidation but also proxy contracts that can be identified by looking at the delegate calls (if any) in the tx traces. Types of traces (by action_type): Call, which happens when a method on the same contract or a different one is executed. We can identify the input parameters in each instance by looking at this trace. Self-destruct, when a arbitrage contract destroys the code at its address and transfers the ETH held in the contract to an EOA. Common pattern among searchers given gas refunds. Create, when a contract deploys another contract and transfers assets to it. Reward, pertaining to the block reward and uncle reward, not relevant here.

Source: https://github.com/taarushv/eth2-mev-rewards/blob/main/final-eth2-mev-calc.ipynb Assumptions Average MEV per block/slot: 0.18 ETH Lower bound of ETH staked: 524288 ETH Upper bound of ETH staked: 10M ETH Not including tx fees The mean/long term case

Setup Mock relay, Containers of mev-geth mining instances, Mock simulation Checklist [ ] Logic testing [x] correct block formation / ordering [x] correct auction winner [ ] correct bundle atomicity

TL;DR + code script: https://gist.github.com/taarushv/36f783aea9b28a725c5f5300d27f926a Note: Just thinking outloud with this, probably missing a bunch of improvements/probable attack vectors, do comment and lmk! Goals: Enable pursuit of multiple MEV opportunities within the same block. For example, if there's a position on aave that can be liquidated and an arbitrage opportunity on ETHUSD across DEXs, currently searchers can send two bundles to the relay but only one of them will be chosen and mined based on the seal bid. The other opportunity could persist to the next block and be captured by the next miner or it could simply be sniped by a tx in the same block but originating from the regular TxPool. Create two classes of bundles bundles that indicate that they would like to be on the top of the block (and bid appropriately) or be pruned/rolled over if they don't get that index