The veRAACToken contract's increase() function lacks MAX_TOTAL_SUPPLY
validation, allowing users to bypass the global supply cap. By creating small locks and then increasing them, an attacker can exceed the intended maximum total locked amount of tokens, potentially disrupting the protocol's tokenomics and governance power distribution.
The veRAACToken
contract implements a vote-escrowed token system where users can lock RAAC tokens to receive voting power. To prevent excessive token concentration and governance risk, the contract enforces two key limits:
MAX_LOCK_AMOUNT (10M tokens): Maximum amount per individual lock
MAX_TOTAL_SUPPLY (100M tokens): Maximum total voting power
However, while these limits are checked in the lock()
function, they are not properly enforced in the increase()
function:
The vulnerability stems from the fact that while lock()
enforces the MAX_TOTAL_SUPPLY limit, increase()
allows users to bypass it. Consider this scenario:
The protocol has 95M tokens already locked (close to MAX_TOTAL_SUPPLY
of 100M)
A user attempts to lock 10M tokens directly via lock()
- this correctly reverts due to exceeding MAX_TOTAL_SUPPLY
However, the same user can:
First create a small lock of 1M tokens (which passes the MAX_TOTAL_SUPPLY
check as 95M + 1M < 100M)
Then call increase()
with 9M tokens to grow their lock to 10M
Since increase()
lacks the MAX_TOTAL_SUPPLY
check, the total locked amount grows to 105M, breaking the protocol's supply cap
i'm using foundry for test , to integrate foundry :
run :
add this to hardhat.config.cjs
:
run :
comment the test/unit/libraries/ReserveLibraryMock.sol
as it's causing compiling errors
inside test folder , create new dir foundry
and inside it , create new file baseTest.sol
, and copy/paste this there :
now create a pocs.sol
inside test/foundry
, and copy/paste this there :
here a a test shows how we can use increase()
to grow a lock beyond the MAX_TOTAL_LOCKED_AMOUNT limit :
Users can exceed the MAX_TOTAL_SUPPLY
limit, breaking a core invariant of the system
This allows accumulating more voting power than intended, potentially enabling governance attacks
Foundry
Manual Review
consider checking against MAX_TOTAL_SUPPLY
amount in the increase()
function as well
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.