Czar102 - Vote manipulation and griefing in AdvancedDistributor

[sherlock-admin]

Czar102

medium

Vote manipulation and griefing in AdvancedDistributor

Summary

Upon a change in the vote factor, claims initialized in the past have a past vote factor counted in.

Vulnerability Detail

If the vote factor is changed, it can be increased or decreased. If it is increased, users who claimed for the first time (initialized their claim) are at an unfair loss, since addresses that initialized the claim later will get more votes per tokens.

On the other hand, if the vote factor is decreased, users who haven't initiated the claim yet will be at a disadvantage – they won't be able to receive as good rate as previously.

NOTE: The last option also presents a griefing attack in case of any contracts derived from CrosschainMerkleDistributor which allows anyone to initialize any existing distribution record. Hence, the griefer can call this function before the decrease of the vote factor, can initialize other addresses' claims in order to lower their votes. This can be done, for example, to have a larger effective impact on vote results, because less vote tokens will be in circulation.

Impact

Depending on the time of initialization (which sometimes can be done maliciously by external parties), the voting power for claims of the same size may differ.

Code Snippet

  function _initializeDistributionRecord(
    address beneficiary,
    uint256 totalAmount
  ) internal virtual override {
    super._initializeDistributionRecord(beneficiary, totalAmount);

    // add voting power through ERC20Votes extension
    _mint(beneficiary, tokensToVotes(totalAmount));
  }

Tool used

Manual Review

Recommendation

Instead of using an ERC20 token balances mapping to store the voting balance, override the balanceOf(address voter) function to return tokensToVotes(records[voter].total).

Duplicate of #55