A maker may monitor the mempool for an upcoming tradeValid() transaction which indicates an interest from a taker but then front-runs the forthcoming acceptTrade() transaction to cancelOffer() to grief the taker.
This causes a DoS on the taker without tangible benefit to the maker.
Evaluate to determine if this is a concern. Reconsider the design to see if there is a way to commit and reveal a trade where it is not possible to cancel the offer once trade is revealed and locked.
Handle
0xRajeev
Vulnerability details
Impact
A maker may monitor the mempool for an upcoming tradeValid() transaction which indicates an interest from a taker but then front-runs the forthcoming acceptTrade() transaction to cancelOffer() to grief the taker.
This causes a DoS on the taker without tangible benefit to the maker.
Proof of Concept
https://github.com/code-423n4/2021-04-redacted/blob/2ec4ce8e98374be2048126485ad8ddacc2d36d2f/Beebots.sol#L578
https://github.com/code-423n4/2021-04-redacted/blob/2ec4ce8e98374be2048126485ad8ddacc2d36d2f/Beebots.sol#L611
https://github.com/code-423n4/2021-04-redacted/blob/2ec4ce8e98374be2048126485ad8ddacc2d36d2f/Beebots.sol#L619
Tools Used
Manual Analysis
Recommended Mitigation Steps
Evaluate to determine if this is a concern. Reconsider the design to see if there is a way to commit and reveal a trade where it is not possible to cancel the offer once trade is revealed and locked.