When trying to run things locally, I’m seeing a few errors of the kind:
2025-03-25 11:48:31,078 - ERROR - Unexpected error during transaction bundle simulation: expected a bool, int, byte or bytearray in first arg, or keyword of hexstr or text
2025-03-25 11:48:32,531 - INFO - RESULT WAS [{‘output’: ‘0xd81b2f2e0000000000000000000000000000000000000000000000000000000066ace926’, ‘stateDiff’: {‘0x34e72f7e50e25f771ac1d2f514752a12ab1e9e82’: {‘balance’: ‘=’, ‘code’: ‘=’, ‘nonce’: {‘*’: {‘from’: ‘0x40’, ‘to’: ‘0x41’}}, ‘storage’: {}}}, ‘trace’: , ‘vmTrace’: None}]
Is this expected? Could this be due to the node I’m using? Which one have you tried? I’m running a reth archive node
I believe with this error the script is never finishing (it’s been running for half an hour and seems to be stuck in some loop). Specifically the block range I am testing is 20226516 - 20226518. Even in the default range the script seems to be in an endless loop.
Another thing I noticed while reviewing the code, is that all the simulations seems to be implicitly done on the latest block (ie now) since the block number of the target block is not specified in the trace_callMany arguments (cf. trace_callMany RPC Method | Ethereum Documentation). I would assume this to render all simulations failed in practice?
Heya all!
The fix is already made by Friday 18.04.2025.
The node is still under maintenance, so the fix is still in “theory” state.
Will be back with an update and commit. Hope the node will be re’synced shortly
Given the high turn-around time on this grant (and the time we have been trying to complete it), I wonder if it’s not more beneficial for all sides to close this grant uncompleted.
If you’re stating that transaction 0xd789…fcb6f86 should be flagged under CiP-40 (as defined by the RFP scope), I would appreciate a full technical audit outlining which specific part of the protocol logic was violated. You previously committed to providing objective feedback — yet this has not been completed to date, in your final review.
From my side, all requirements discussed in the RFP and our prior communications have been fully implemented:
Simulation is executed at the block level using trace_callMany, including stateDiff tracking,
Backrun segments are verified for inclusion and refund correctness post-target transaction,
The transaction in question was correctly identified, simulated, and logged, with no objective violations detected.
If your current expectations differ from the original spec or CiP-40 interpretation — please outline them explicitly. Otherwise, the tool fulfills the technical scope it was funded for.
Should you believe this grant should be closed regardless of delivery, you are of course free to initiate a DAO governance vote. I will likewise reserve the right to publish a full technical report and timeline of the grant, should this become a matter of public interest.
Unless a specific, documented CiP-40 violation is demonstrated or a vote concludes otherwise, I consider this grant technically fulfilled.
I’m sorry to hear that the protocol violation is not clear. Let me give you a full technical audit of a rule violation example (there should be many in this particular block):
The original RFP describes the logic of the greedy algorithm (milestone 2)
Simulate each bundle with the target transaction at position p.
If successful, note the payment to the builder; if not, disregard the bundle.
Order bundles by descending payment value.
Then,
Record the block state s post-application of the target transaction at position p.
For each sorted bundle, simulate only the backrun segment at position p+1.
If successful, update s with the new state post-simulation, adjust p, and log the backrun transaction hash; if not continue with next bundle.
And finally
Verify the inclusion of each logged transaction hash within the target block, followed by a refund transaction to the specified recipient.
However, in the raw bundles table on Dune we for instance find 0x9e5ad33f494848d2984f39b18d9f3f0bc2b45a2e5a6773a54484cef90b0b7d12, which would have paid 0.21 ETH to the builder. In order to maximise user refunds this transaction should have been applied before 0xaef0524ca47f89620cf694b428a08ee5a6b01214e8559d74874c2093c86d7b6f, since it pays (and therefore refunds) more. It passes simulation (https://www.tdly.co/shared/simulation/057c42d4-05ae-4f73-b733-ab43ba964319) on the target block, however this hash was not included in the target block. This is a violation.
Regarding closing this grant uncompleted: Given the amount of guidance that was required to date, the time that has passed since the work started and the state that the script is currently in, I’m unfortunately not going to be able to support it further.
I will defer to the grant committee to decide if/how to proceed with it. I can confirm that milestone 1 has been delivered.
Correct me if I’m wrong — but you’ve just cited a transaction as proof of violation that… was never even submitted to MEV Blocker?
I ran a Dune query against mevblocker.raw_bundles for block 20226516 (see attached screenshot, link below). Your suggested transaction (neither second one) —
0x9e5ad33f494848d2984f39b18d9f3f0bc2b45a2e5a6773a54484cef90b0b7d12
— simply doesn’t exist in the recorded bundle feed.
So unless the tool is now expected to detect and simulate hypothetical, never-submitted bundles, we’re moving far outside the RFP scope and into the realm of post-facto theorycrafting.
The tool delivered:
Block-level simulation with trace_callMany,
Post-target state diffs,
Refund evaluation of real MEV Blocker bundles,
not imaginary what-ifs that never touched the relay.
If this is about avoiding payout, please just say so. But continuing to delay with “violations” that aren’t even present in the feed is wasting everyone’s time.
You’re free to initiate a closure vote/partial compensation or propose refund adjustments — but let’s be clear:
the current logic fulfills the RFP spec.
The rest is just political smoke.
First, we want to thank you for the time and effort you’ve invested in working on the grant to build an open-source tool for verifying MEV Blocker transactions. We recognize that building novel infrastructure can be complex and that challenges often arise during development.
That said, after multiple check-ins and an extended timeline, the Grants Committee—based on the technical review led by @fleupold — has concluded that Milestones 2 and 3 have not been completed to a level that meets the expectations defined in the original RFP and grant agreement.
While we acknowledge the progress that was made, we believe the committee has provided ample time, feedback, and support throughout the grant process. At this stage, and in accordance with T&C, the committee intends to close the grant with only Milestone 1 considered complete and paid out. The closure of the remaining milestones will be submitted to a Snapshot vote among committee members for ratification.
We sincerely appreciate your engagement with the DAO and encourage you to stay involved in the ecosystem. If you have any additional materials or clarifications you’d like us to consider before the vote, please feel free to share them here.
