Core Contracts

Summary

The RAAC Governance Contract calculates quorum dynamically using the current total voting power and a mutable quorum parameter. Since there is no snapshot of the quorum at the time of proposal creation or during the voting period, the contract owner can lower the quorum requirement after votes have been cast. This can retroactively change the outcome of a proposal that was defeated solely due to not meeting the original quorum threshold. This issue is a known problem that OpenZeppelin has addressed in their governance library by implementing a snapshot mechanism.

Vulnerability Details

• Dynamic Quorum Calculation:
  The contract calculates quorum by multiplying the total voting power from the veRAAC token with the current quorum percentage (quorumNumerator) and dividing by a fixed denominator. The logic follows the formula:
  quorum() = (totalVotingPower * quorumNumerator) / 100
  This means that the required number of votes is recalculated based on the latest value of quorumNumerator.

• Mutable Governance Parameter:
  The contract allows the owner to update key parameters, including the quorum numerator, via the setParameter function. Lowering the quorumNumerator after votes have been cast directly reduces the quorum threshold for all proposals, including those that have already been voted on.

• Lack of Snapshot Mechanism:
  There is no mechanism to record the quorum requirement at the time of proposal creation or during the voting period. Without this snapshot, proposals are continuously evaluated against the current quorum value, allowing changes in the quorum to retroactively affect proposal outcomes.

• Known Issue Addressed by OpenZeppelin:
  This vulnerability is a known issue in governance designs that calculate quorum dynamically. OpenZeppelin has addressed this problem in their governance library (e.g., GovernorVotesQuorumFraction) by incorporating a snapshot mechanism to lock in the quorum requirement at the time of proposal initiation.

• Potential Exploitation:
  An owner or malicious actor could lower the quorum requirement after a proposal has been defeated solely due to insufficient quorum, thereby enabling its execution despite the initial vote outcome.

Impact

• Retroactive Proposal Execution:
  Proposals that were initially defeated because they failed to meet the quorum can become eligible for execution if the quorum parameter is lowered post-vote. This undermines the original voting outcome.

• Centralization Risk:
  The contract owner’s ability to change key parameters like quorumNumerator introduces a risk of centralization, potentially allowing unilateral changes to governance outcomes.

• Governance Integrity:
  The vulnerability compromises the integrity of the governance process by enabling manipulation of proposal results and undermining the collective decision-making process.

Proof of Concept (POC)

1. Initial Setup:

   • Assume the total voting power is 1,000,000 tokens.

   • With a quorumNumerator of 4, the required quorum is calculated as:
     (1,000,000 * 4) / 100 = 40,000 votes.

2. Proposal Creation and Voting:

   • A proposal is created with the above quorum requirement.

   • The proposal receives 30,000 votes in favor, which is below the required quorum of 40,000 votes, so it is initially marked as defeated.

3. Parameter Update:

   • The contract owner calls the function:
     setParameter(GovernanceParameter.QuorumNumerator, 3),
     which lowers the quorum requirement.

   • With the updated parameter, the new quorum is recalculated as:
     (1,000,000 * 3) / 100 = 30,000 votes.

4. Retroactive Effect:

   • When the proposal’s state is re-evaluated using the new quorum, it now meets the threshold with its 30,000 votes.

   • As a result, a proposal that was originally defeated due to insufficient quorum becomes eligible for execution.

Tools Used

Manual review

Recommendations

• Implement a Quorum Snapshot:
  Modify the contract so that the quorum requirement is recorded at the time of proposal creation or when the proposal enters the voting period. This snapshot should be used for evaluating the proposal outcome, regardless of subsequent changes to the quorum parameter.

• Restrict Parameter Changes:
  Consider implementing restrictions that prevent lowering the quorum requirement if there are active or recently concluded proposals that could be affected. Alternatively, require a governance vote or introduce a delay for any changes to such critical parameters.

• Adopt Proven Governance Models:
  Leverage established governance frameworks like OpenZeppelin’s GovernorVotesQuorumFraction, which include mechanisms to snapshot total voting power and quorum percentages at proposal initiation, ensuring consistent evaluation throughout the proposal’s lifecycle.