The Staking
contract has two functions that use strict equality checks which could potentially lead to issues:
Dangerous Strict Equality in claimRewards()
Function: The claimRewards()
function contains a check where it compares lastClaim[msg.sender]
to 0
. This is considered dangerous because if lastClaim[msg.sender]
is not initialized properly or if there's any rounding error during calculations, it might not be exactly equal to 0, leading to unexpected behavior. It's generally safer to use less than or greater than comparisons when dealing with floating-point numbers or values that can have small variations due to arithmetic operations.
Dangerous Strict Equality in deposit(uint256)
Function: The deposit(uint256)
function checks if the balance of loveToken
in the stakingVault
address is exactly equal to 0. This could be problematic if there are any pending transactions or if the balance was previously set to a value close to zero but not exactly zero due to gas costs or other factors. A safer approach would be to check if the balance is less than a certain threshold instead of checking for exact equality.
Locked Claims: If the claimRewards()
function uses strict equality to check whether a user has already claimed rewards
, it could result in locked claims
. Users who are eligible to claim rewards but whose lastClaim
timestamp is slightly off due to rounding errors or initialization issues might be unable to do so. This could lead to frustration among users and potential loss of trust in the platform, as well as missed opportunities for earning rewards.
Prevented Deposits: In the case of the deposit(uint256)
function, if the balance check is too strict, legitimate users might be unable to deposit
tokens. For example, if the balance is very close to zero but not exactly zero due to gas costs or pending transactions, the function will reject the deposit. This could deter users from participating in the staking
process altogether, reducing the liquidity and utility of the contract.
manual review
To mitigate these risks, consider using less than or greater than comparisons with appropriate thresholds or ensuring proper initialization of variables before performing strict equality checks.
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.