Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in MEV blocker monitoring #120

Open
fhenneke opened this issue Oct 10, 2024 · 1 comment
Open

Bug in MEV blocker monitoring #120

fhenneke opened this issue Oct 10, 2024 · 1 comment

Comments

@fhenneke
Copy link
Contributor

We have noticed that MEV blocker rebates do not cause any alerts at the moment. This is probably due to a bug in how rebates of the different drivers are handled.

The code in question is

eth_kickbacks = None
for address in MEV_BLOCKER_KICKBACKS_ADDRESSES:
kickback = self.web3_api.get_eth_transfers_by_block_range(
block_number, block_number, address
)
if kickback is not None:
eth_kickbacks = kickback
break
if eth_kickbacks is None:
return False

This is wrong since if fetching transfers to the first address does not fail (i.e. kickback is not None), that value is chosen as rebate. Instead, it should should collect all transfers to rebate addresses, and return the one non-zero entry. If one of the transfer fetchings fails. If more than one entry is non-zero, there were probably more than one settlement in the block. (Adding rebates should be fine to avoid more complicated logic for mapping settlements to rebates.)

One proposal would be

        eth_kickbacks = 0.0
        for address in MEV_BLOCKER_KICKBACKS_ADDRESSES:
            kickback = self.web3_api.get_eth_transfers_by_block_range(
                block_number, block_number, address
            )
            if kickback is None:
                return False
            eth_kickbacks += kickback
@fhenneke
Copy link
Contributor Author

There seem to be other issues as well.

Transaction https://etherscan.io/tx/0x4954ba06e1e2897507d2e5aa27a856cc7931b029af022aa0fe95945497d59cde with rebate https://etherscan.io/tx/0x3836687fa55a49d1e48c9c467bbcfa24d5236b427e3287f78a325fe0c4ea1b07 should have been detected with the old code but did create an alert.

Transaction https://etherscan.io/tx/0x9bfc4f201ac2e7c94c21d7cef42870ad19e698eba3c2d196b73d06dc361a8853 with rebate https://etherscan.io/tx/0x506d7fb5d4692727b00d3f651831ffdc0989f97b49826d0cf36cf9547128f1a1 reveals that there are additional issues. Here, the rebate is not parsed correctly since it is not a safe transfer but a normal ETH transfer. The same happens for the third hardcoded rebate address, e.g. https://etherscan.io/tx/0x834fa00933fb9edbc3d3ea70d55e0a9e71af86095958a98340bbc4f9e29a12bb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant