Skinny Shadow Sparrow
Medium
The _stake function in the contract processes staking operations and calculates earningPower using the earningPowerCalculator.getEarningPower() function. However, the current implementation does not validate if the _delegatee is eligible before performing other operations in the function. If the _delegatee is ineligible, subsequent operations should not occur.
This issue could lead to unintended side effects, such as updates to state variables and incorrect deposit creation, even when the _delegatee is ineligible.
Causes Uneligible delegate to totalEarningPower and totalStaked to be incorrectly updated !!!!
- totalStaked and totalEarningPower are updated incorrectly: These global variables will reflect a higher staking value than what is actually eligible, leading to inaccurate accounting. Per-depositor tracking is also affected: Variables like depositorTotalStaked and depositorTotalEarningPower will overstate the depositor's contribution, even though the delegatee is ineligible.
- Unnecessary Token Transfers The _stakeTokenSafeTransferFrom call will still execute, transferring tokens from the depositor to the DelegationSurrogate.
Funds get locked: Since the delegatee is ineligible, the staked tokens are effectively locked with no earning power or rewards, resulting in user dissatisfaction. Gas Wastage: Users will incur gas fees for a transaction that ultimately does not fulfill their intent. 3. Misleading Deposit Records An entry is added to the deposits mapping even though the _delegatee is ineligible:
Misleading Data: The system records a deposit as valid, but the associated earning power will be 0 if _delegatee is ineligible. This creates a false impression that the staking process succeeded.
https://github.com/sherlock-audit/2024-11-tally/blob/main/staker/src/GovernanceStaker.sol#L470-L502 https://github.com/sherlock-audit/2024-11-tally/blob/main/staker/src/BinaryEligibilityOracleEarningPowerCalculator.sol#L81-L88
Manual Review