In the lock function, the veRaacToken contract checks whether totalSupply() + amount exceeds MAX_TOTAL_SUPPLY. However, totalSupply() refers to the total supply of veRAAC tokens (which represent voting power), not the raw RAAC tokens locked. Since voting power is time-weighted and decays over time, a small RAAC amount locked for a long duration can generate a voting power value that exceeds the cap.
The bug is caused by comparing the sum of the new lock amount to the veRAAC token supply cap without considering the conversion rate between RAAC tokens locked and the veRAAC tokens minted (which depends on lock duration).
For instance, if MAX_TOTAL_SUPPLY is 100M veRAAC and a user locks a small amount of RAAC (say 1,000 tokens) for the maximum duration, the calculated voting power might be disproportionately high. If many users do this, the aggregate veRAAC supply could exceed 100M, violating protocol constraints.
This miscalculation allows the total veRAAC supply to surpass the intended maximum limit. As a result, users might receive more voting power than the protocol intends, which could distort governance influence and reward distribution.
Adjust the check to convert the RAAC lock amount into its corresponding veRAAC value based on the lock duration before comparing against MAX_TOTAL_SUPPLY. This might involve using the same formula as in the voting power calculation (e.g., linear scaling by duration) to ensure the comparison is accurate.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.