As part of the post audit updates, It was noticed that we are not accounting for tie in the Frontend.
In contracts, winningChoice is now an array winningChoices, if there's more than one choice in that array, it represents a tie.
This however does not break the subgraph logic as there we still maintain one winningChoice along with tied field in Dispute entity. The tallying is done in subgraph too.
Task:
Properly display the winningChoice. Take into account tied field from disputeDetailsQuery and show the correct option.
This will affect the choice we display on Dispute Overview, along with Funding.
Still not sure how we want to deal with appeal funding in case of tie.
Open for discussion.
As part of the post audit updates, It was noticed that we are not accounting for tie in the Frontend.
In contracts,
winningChoiceis now an arraywinningChoices, if there's more than one choice in that array, it represents a tie.This however does not break the subgraph logic as there we still maintain one
winningChoicealong withtiedfield inDisputeentity. The tallying is done in subgraph too.Task:
Properly display the winningChoice. Take into account
tiedfield from disputeDetailsQuery and show the correct option.This will affect the choice we display on Dispute Overview, along with Funding.
Still not sure how we want to deal with appeal funding in case of tie.
Open for discussion.