Open hats-bug-reporter[bot] opened 2 months ago
It doesn't matter who the creator of the market is, there's nothing to be gained or exploit through this frontrun
So there wouldn't be an issue with whom is being the market creator, but you could use this to prevent someone from creating a market with some specific outcome token name.
A proposed fix would be to check if the question already exists and only create it if it doesn't exist (there is no problem if 2 markets have the same question, actually this could happen naturally when a question is used in 2 conditional markets with different underlyings).
Well actually this is already was askRealityQuestion does. So there is no problem there, if you frontrun the TX, the same market would be created.
As per contest rules, are excluded:
Github username: -- Twitter username: -- Submission hash (on-chain): 0xa3d4e5242323ee490da9b267496747be8cba6ec6bc304ffa57160a721a7d3581 Severity: low
Description: Description
When a market is created through the factory contract, the factory contract generates parameters that are subsequently used to create a unique identifier, known as
question_id
, in the Reality.eth contract. This identifier is derived deterministically based on input parameters such as the market's name, outcomes, and configuration. As a result, this process creates a potential frontrunning risk, where a malicious actor can submit an identical transaction before the original transaction is mined.If a malicious actor successfully submits the same transaction first, the Reality.eth contract recognizes the
question_id
as already existing. Consequently, the legitimate transaction is reverted due to the uniqueness constraint of thequestion_id
. This allows a malicious actor to effectively "steal" the market creation, causing disruption and preventing legitimate users from creating their intended markets.Attachments
It is recommended to introduce a mechanism that ensures the uniqueness of each market creation transaction in a way that is not predictable by external observers. This could involve incorporating user-specific nonces, unpredictable identifiers, or additional entropy into the market creation process. Such changes can mitigate the risk of frontrunning and ensure that the market creation process remains secure and reliable.