SJIP: Clarify front-running on chains with private mempool

[WangSecurity]

Description

Clarify how to judge issues about front-running on chains with private mempool

Judging Guidelines PR

https://github.com/sherlock-protocol/sherlock-v2-docs/pull/52/files

Rationale

Often this type of issues gets invalidated by the community because the regular front-running is not possible with private mempool, i.e. you cannot track the mempool to execute the attack. However, this type of issues is possible as unintentional front-running, which is a constraint. Hence, this should be viewed as reason to downgrade the severity.

For example, if we have a standard front-running slippage-related issue on DEX, which deserves High severity under normal circumstances (e.g. front-running on Eth Mainnet), should be viewed as Medium on chains with private mempool (e.g. Optimism). In other words, High will be Medium, Medium will be invalid.

Additional point, for such reports to be valid, they have to explain how the issue can happen with unintentional front-running, e.g. saying "the attacker will monitor the mempool looking for the victim's transaction" is invalid.

Relevant Issue Discussions

No specific discussion

[spacegliderrrr]

If simply "attacker will monitor mempool" is written, this should not invalidate the issue. Root cause is still found and issue described would still be valid. It would happen often that a watson would not have checked/ may not know whether a certain chain has a public or private mempool. Given that the issue is still found, wrong wording should not be a reason for invalidation.

Also, would add some room for a personal opinion. In cases where the issue would usually be critical, since we do not have such severity, in the private mempool case it should still remain High, rather than get downgraded to M.

[IllIllI000]

words matter, and if you haven't identified the attack path, you haven't found a vulnerability

[WangSecurity]

@IllIllI000 is exactly correct here if the in-scope chain has a private mempool, but in the attack path, we say that the attacker has to monitor the mempool, then this attack path is not valid. Moreover, it's also a sign that the Watson may not have done a deep enough research. But would be glad to discuss this point further.

About the second point, yeah, it's fair, but we also need to remember that these are guidelines rather than the rules that we have to treat like a law/bible. So if the context allows for leaving a front-run related issue with private mempool as High, then we can go for it.

[0xHuntoor]

Additional point, for such reports to be valid, they have to explain how the issue can happen with unintentional front-running, e.g. saying "the attacker will monitor the mempool looking for the victim's transaction" is invalid.

so he mention racing condition instead of meme pool monitoring?

[WangSecurity]

Well, you could say that, but it would be better with slightly more details.

[Flashloan44]

We need to define clearly what is valid frontrunning here, if the frontrunning details says that the "transaction happened to be in the first in line to be processed". I think that could be a valid issue.

For example, liquidation bot is expected to liquidate a position in timely manner however you can't be 100% sure this liquidation bot will be the first one to be processed in the blockchain. There is a difference between "timely manner" vs "first to be processed". Due to the nature of blockchain systems, there is always only one guy winner in execution. So liquidation bot will fail and liquidation is delayed, because someone happened to be faster than him in execution. So i think this type of frontrunning should be valid, whether the chain is using private pool or not. Let me know your thoughts.

[WangSecurity]

Yeah, that's basically what the guideline clarifies. In the community judging, we often see the argument "XYZ chain has private mempool, so it's invalid", while it could be valid in a scenario that you described, i.e. due to the nature of blockchains, the attacker's txn can be executed earlier than victim's, and the issue would go through.