Malicious user can predict outcome and win all predictions

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xdfac576e411c1ebe8821865e66f24df26a1ad484c44671a60f134ed11c6901c6 Severity: high

Description: Description\ Malicious user can find answer of the prediction before condition being resolved so he can front-run resolve function to leverage its profit or reduce its loss by splitting or merging the outcome token. answer of the condition can be viewd from mempool when arbirator tries to call submitAnswer in RealityProxy, there should be a period before resoving the condition to prevent users from splitting or merging the tokens so it can't be front-runned

Attack Scenario\ Step-by-Step Scenario:

Condition Setup: A prediction market is created where users can bet on a specific condition, for example, "Will it rain in City X tomorrow?" Users buy outcome tokens for either "Yes" or "No" based on their predictions.

1 - Market Activity: Users are actively trading and holding these outcome tokens. The resolution of the condition is set to occur at a later time, based on the arbitrator's judgment. The user purchases some outcome tokens for both "Yes" and "No" to hedge their position.

2 - Arbitrator Submits the Answer: The arbitrator, responsible for resolving the condition, determines the correct outcome (e.g., "Yes, it rained") and prepares to submit the result via the submitAnswer function in the RealityProxy contract. This function is sent as a transaction and is visible in the mempool before it is confirmed on-chain.

3 - Malicious User Observes the Mempool: A malicious user monitors the mempool, where they can see the arbitrator’s pending transaction for the submitAnswer function, which contains the answer ("Yes"). Since the result is publicly visible in the mempool, the malicious user now knows the outcome ("Yes, it rained") before the condition is officially resolved on-chain.

4 - Front-Running the Resolve Function: Armed with the knowledge of the outcome, the malicious user front-runs the resolve function by submitting their own transactions before the arbitrator's transaction is confirmed. The user proceeds to: Split Tokens: They split their "Yes/No" outcome tokens, ensuring they maximize their potential payout from the "Yes" result. Merge Tokens: If they hold a large number of "No" tokens (which would become worthless), they merge these tokens with others to reduce their losses. By front-running, he can win all predictions and and participate risk free.

5 - Arbitrator’s Transaction is Confirmed: The arbitrator’s submitAnswer transaction is finally confirmed, and the condition is resolved as "Yes." By this point, the malicious user has already adjusted their holdings, benefiting from the outcome before other users could respond.

Solution:

To mitigate this vulnerability, the system should implement a lockout period after the result is submitted but before the condition is resolved. During this period:

Users should be restricted from splitting or merging tokens. This ensures that once the result is visible in the mempool, users cannot manipulate their token positions based on the outcome before the resolution is finalized.

This lockout period would prevent front-running attacks and ensure a fair market resolution process.

[xyzseer]

related to #87

[clesaege]

Similar to https://github.com/hats-finance/SeeR-PM-0x899bc13919880db76edf4ccd72bdfa5dfa666fb7/issues/87