Bundle Status API

[zeroXbrock]

Presently, searchers on mev-share are unable to learn anything about their bundle after it is sent, other than the fact that it was received by the API. A bundle targeting a block 10 minutes in the future appears no different to the user than a bundle that gets included instantly, other than what they see on Etherscan. In situations where inclusion is prolonged (and the reason is uncertain), checking the status of your bundle is very frustrating.

The system’s UX would benefit greatly from a “status” endpoint, similar to flashbots_getBundleStats.

However, we cannot reveal to searchers whether their bundle reverted, because doing so would compromise the privacy of users. Any on-chain value can be leaked if we give searchers instantaneous feedback about whether their bundle reverted.

How can we design tracking APIs that give searchers a better UX without compromising on privacy?

[zeroXbrock]

To follow this point:

Any on-chain value can be leaked if we give searchers instantaneous feedback about whether their bundle reverted.

proof by example:

• Write a smart contract S with a function read(uint addr) that when called, reads one bit from a desired (hidden) storage/memory position and reverts if it's 1. Assume it's deployed on-chain.
• Find a pending transaction which modifies EVM state, resulting in a new state value which you want to read (e.g. a swap, which updates uniswap pool reserves)
• Send a bundle which backruns the transaction with a separate tx which calls read on S for each bit desired; can be done in parallel
• [Use bundle stats endpoint to] get revert status of each bundle
• Convert the revert responses into binary (revert = 1, succeed = 0), then cast the binary into a number (e.g. u32)
• Now that you know the exact pool values, you can infer everything you need to know to maximally exploit the user

[mteam88]

I assume one reason to call bundleStats would be to check if the bundle is still being considered for inclusion. We can't do this primarily because a bundle would not be considered for inclusion after a simulation failed. Any information about bundle status reveals things about the bundle...