Hi April,
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.
The transaction I highlighted was followed by Ethereum Transaction Hash: 0xaef0524ca4... | Etherscan which paid 0.16 ETH to the builder.
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.