RealityProxy.sol#resolve() - resolution of Reality answer can be halted by wealthier actors

[hats-bug-reporter[bot]]

Github username: @PlamenTSV Twitter username: @p_tsanev Submission hash (on-chain): 0x3b83e5100b023e6f8fc0e4a6e6ca562823daa062ab686a85aa1cee96d9279af9 Severity: medium

Description: Description\ The RealityProxy.sol's resolve() function is used for getting a question's answer and reporting the market's payouts to the conditional token. It fetches an answer from RealityETH which it compares to the outcomes or erros out if an answer is requested too soon and the question hasn't been reopened. However, RealityETH's implementation could allow wealthier actors or dedicated groups of actors to halt the resolving process by front-run submitting answers to Reality.

Attack Scenario\ Every market type's specific resolve function firstly fetches the answer from Reality by invoking resultForOnceSettled() on the given question id. Internally resultForOnceSettled() calls resultFor() to fetch the current best answer and has the important protection modifier stateFinalized. stateFinalized is meant to check if the question's finalize_ts has been passed, otherwise the question has not been timeout for enough time and thus reverts with "question must be finalized" The RealityETH contract also features submitAnswer which allows anybody to submit an answer to a question by paying 2 times moore than the previous bond value and increase the finalize_tsby the question's timeout. This contract structure opens up the possibility:

1. An attempt to resolve a finalized question is made
2. A wealthy actor/dedicated group front-runs the resolution and submits a new answer since the question is finalized
3. The new answer is submitted by paying the needed bond and the finalization is increased by timeout (currently 3.5 days)

The exploit's economical possibility highly depends on the question's bond which is set by the market creator. It is not far fetched to assume there would be questions with a high bond since they'd require more precise answers, but also there would be questions with lower (<0.5eth) bonds to allow more involvement. With a timeout of 3.5 days and an exponentially increasing bond price every time an answer is submitted, theoretically a wealthy attacker or a group of attackers could halt resolution of a question by approx. a month and a bit before the attack becomes infeasible to continue, depending on the initial min_bond.

With a starting bond of ~0.2, the group would need approx. 50eth to halt resolution for an entire month. Keep in mind bonds could be even lower and the price can be exponentially lower

Resolution\ There would need to be a workout to the way resolutions are fetched, since this front-running comes solely from the interaction with RealityETH. The isFinalized modifier requires that the question is not pending arbitration, so a way to fix this would for the arbitrator to atomically answer and resolve the question in order to avoid being front-ran by the griefers.

[greenlucid]

That's fine because the grief can only waste time that increases logarithmic with the resources spent. Actually this actor can delay more: create a dispute, and keep appealing it. So he could delay up to two months. Log griefs are out of scope I think

[PlamenTSV]

Didn't find anything regarding such griefs being out of scope, but the 2 month possible delay you mention adheres it even more to medium severity

[PlamenTSV]

That's fine because the grief can only waste time that increases logarithmic with the resources spent. Actually this actor can delay more: create a dispute, and keep appealing it. So he could delay up to two months. Log griefs are out of scope I think

The issue is also about the grief being able to cover enough time to abide to the 1 month freezing mentioned in the guidelines, possibly even more depending on the bond

[greenlucid]

Out of Scope

Issues about acceptable time griefs. It is possible to delay the resolution of a market by putting bonds on incorrect answers, creating disputes, making frivolous appeals. Acceptable time griefs must be in O(log cost).

[PlamenTSV]

@greenlucid How do you define an acceptable time grief, log of the cost is the amount of days deemed acceptable? And is the cost derived in eth on usd?

[PlamenTSV]

Out of Scope

Issues about acceptable time griefs. It is possible to delay the resolution of a market by putting bonds on incorrect answers, creating disputes, making frivolous appeals. Acceptable time griefs must be in O(log cost).

Replying, just to get an understanding of the OOS statement. Since the acceptable time grief is highly dependent on the minBond. If the minBond is a non-high amount, we could brick the resolution for a lot longer than the log(cost), so I am looking to understand the statement here.

[clesaege]

This is a known trade-off between speed and accuracy (contrary to Polymarket, we prefer accuracy of resolution compared to speed). If someone were to do that:

• People can put higher bonds (you don't need to just double, you can do more than double).
• Outcome tokens are still tradable so people needing liquidity right not can sell to people buying those tokens at ~0.99

This is out of scope:

• Issues about acceptable time griefs. It is possible to delay the resolution of a market by putting bonds on incorrect answers, creating disputes, making frivolous appeals. Acceptable time griefs must be in O(log cost).

Because this is a big O notation, the units used as irrelevant as long as those are linear units (days, ETH, USD).