Closed jtse0 closed 2 years ago
According to the whitepaper:
We have some leeway in implementation, but need to make sure it's fair, and presented to the community. We may want to set the number of jurors based on the size of the existing pool.
A fixed time is good, so that the winner can trigger release of funds after a set time, and we don't have to worry about implementing some kind of service that handles dispersal.
After some discussion, we can probably solve the problem of 0 votes by judging in favor of the buyer, at least in the case of a chargeback. This doesn't work as well for escrow. Another possible option is to fall back to Admin decision in this case - we could have a special group of accounts that get to break ties. This may be the simplest initial solution.
The offline discussion goes on before implementation.
After discussion, this ticket will only focus on the unambiguous situation where a winning decision can be clearly decided. Another ticket will be created for handling situations where there is a tie. Work on this ticket can proceed.
Voting needs to be clarified before we implement functions related to voting in the SlmJudgement contract.
Perhaps we can also add a voting period that is set in place to allow jurors to vote. If that time ends and there have not been sufficient votes to meet the minimum voting requirements, then a new batch of jurors will be selected to continue voting to hopefully meet the minimum requirement to complete the dispute vote process.
This kind of ties into issue related to voting incentives: https://github.com/SolomonDefi/solomon-monorepo/issues/123