There is room for additional validation on some state changing functions like _createLock
, _updateLock
to prevent unexpected values or states.
The main issue is that these functions rely on passed in parameters to set lock states without checking that they fall within valid ranges:
This could be triggered by incorrectly coded external contract calls to _createLock
and _updateLock
or a compromised owner account making direct calls.
Scenario
A bad actor gains access to the owner account
They call _createLock
with values:
_amount = 0
_lockingDuration = 86400 * 365 years (max uint64 number)
This creates a lock that appears to stake a very large amount due to the overflowed duration
When rewards are calculated this lock takes a very large share, breaking the distribution
Or the lock can never be withdrawn from due to the 0 amount
If invalid values are passed into _createLock
or _updateLock
, it could result in lock states that break the expected staking logic and token distribution. For example:
Locks with 0 amount, causing division by 0 errors in calculations
Locks with extremely large boost amounts, skewing distribution
Locks with expired start times, making the tokens impossible to unlock
This could prevent users from withdrawing their tokens when they expect to or cause reward calculations to drastically skew towards certain accounts.
Vs
Add validation checks in the functions for example.
This will prevent unexpected parameter values from ever putting the contract into an inconsistent state.
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.