Unfavorable actions might be executed due to the lack of deadline

[hats-bug-reporter]

Github username: @Rassska
Twitter username: m_Rassska
Submission hash (on-chain): 0x88839fabc47e6c6bd8cda12ff6ad21bc7800c14d2ee23168bfd90b810d20eb2f
Severity: low

Description:

Description

• Since, the prediction market is highly volatile in general, it's important to provide fully deterministic actions that users could leverage. Currently, Router::splitPosition(), Router::mergePositions() do not allow users to specify desired point in time from which the intention will be invalidated. This might lead to unintentional executions at a later point in time.

Unfavorable Scenario

• Bob wants to quickly split his position backed by certain outcome and sell some of the resulted ones. Note, this might be done in a single flashbots bundle to react quickly.
• However, due to a spike in gas prices on Mainnet, the tx might stay in mempool for an uncertain time.
• After some unknown amount of time, the bundle might be finally executed, however the condtions on prediction market have changed and Bob's precomputed expected value on his mev also became negative.

Mitigation Steps

• Add deadline param in:
  • Router::splitPosition()
  • Router::mergePositions()
• So that users can compute their expected values in a deterministic way regardless how active chain is.

[clesaege]

I think you were thinking of stuff like an AMM or limit order. But here splitting and merging are fully cancellable actions (if you split, you can merge back and get your underlying tokens, if you merge you can split back and get your conditional tokens), so there is no problem if they are executed after a delay (I think due to gas prices being high).

[Rassska]

But what if you have a bundle of 2 txs:

• split the position
• exchange some of the outcomes on amm

In this case, if the tx executes after some time, it might be unfavorable to split and exchange. That's why probably, it's worth to provide an opportunity for the traders to specify deadline block. On front-end side this could be defaulted by specifying type(uint256).max or 0, since the regular users won't be affected.

[clesaege]

In this case, that's on the exchange to propose a deadline.