10**6 is too small for RATIO_BASE

[code423n4]

Lines of code

https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/plugins/utils/Ratio.sol#L6

Vulnerability details

Impact

RATIO_BASE is set as 10**6, and limit of participations is also around 10**6.
RATIO_BASE should be bigger than square of the limit of participations.

Proof of Concept

Currently, RATIO_BASE is set as 10**6.
https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/plugins/utils/Ratio.sol#L6

In the contract MajorityVotingBase, we can easily guess that the limit of participations is around 10**6 (= RATIO_BASE).
https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/plugins/governance/majority-voting/MajorityVotingBase.sol#L536

For example, let's say that the creator of Voting DAO wants to separate 1/2001 and 1/2002 in the voting ratio.
In other words, "1 yes, 2000 no" is executable and "1 yes, 2001 no" is non-excutable.
So voting ratio should be bigger than 1/2002 and smaller than 1/2001.
Since both 1/2001 and 1/2002 are inside the range (499/1000000, 500/1000000), there is no proper ratio.

Tools Used

(Nothing, just looking the code on VSCode)

Recommended Mitigation Steps

We can set RATIO_BASE as 10**12. Then, the creator can separate every two different fractions with denominators less than 10**6.

[0xean]

The same is true for any value that is selected for RATIO_BASE, its a design choice about how much precision is required and therefore best as QA

[c4-judge]

0xean changed the severity to QA (Quality Assurance)

[c4-judge]

0xean marked the issue as grade-c