Dria

Summary

The last validator has an incentive to send in score values which guarantees them to get all available rewards (numGenerator x validatorFee), instead of scoring the responses objectively. In general, it pays off to wait to see other validators' submissions and only then craft your own scores (make them close to the mean of seen scores) in a way that increases the reward payoff

Vulnerability Details

Let's say there is 1 generator and 10 validators. The 10th validator to submit scores is guaranteed to maximize rewards simply by providing the mean of the 9 previously provided scores. Then again, 9th validator increases their chances to get rewards by providing the mean of the 9 previously provided scores. Obviously, all validators have a disincentive to submit scores early but have an incentive to submit scores as late as possible, ideally to be the validator that triggers the validation finalization.

Impact

There are 2 major impacts:

• validators are not scoring the responses objectively, but in a way that increases their chances of winning rewards

• there might be late submission races where all validators wait as long as possible and then race to try to do the last validation submission. This could include gas bidding wars (on chains where front-running is possible) and other economically inefficient outcomes

Tools Used

Manual review

Recommendations

Design changes are required to solve this issue. One approach could be using a commit-reveal scheme - ie. using 2 phases for validation. In 1st phase, validators commit to their scores, but scores are not visible to other validators. When enough commitments are collected, the next phase starts where validators reveal their scores. This approach would introduce scoring fairness and avoid late submission races