stake.link

Summary

In case if staker of SDLPoolSecondary will call initiateUnlock or withdraw then his effectiveBalances is decreased immediately and rewards are accrued immediately, however action is executed later. But in case of queued update, rewards are accrued only when executeQueuedOperations is called. This creates inconsistency.

Vulnerability Details

Updates from secondary chain are executed in batches. They are queued and executed right after rewards are received from primary chain. Then shouldUpdate is set to true and batch update ccip call is allowed.

When receive from primary chain is received, then it is allowed to process updates from previous batch. Then users can call executeQueuedOperations to execute their queued actions. All this function will then claim rewards for users. After update, in case if it was increase of effective balance, effective balance will be increased.

Rewards amount depends on totalEffectiveBalance and effective balance of user. So this is logical to first claim rewards using old balance and then only update it. However in case of initiateUnlock or withdraw functions there is a difference.

This 2 functions decrease effective balances right when they are called. Also they claim rewards before that using previous effective balance. But the problem is that there were no rewards destribution yet for the batch period and as result, when _executeQueuedLockUpdates function will be called, then user will get less amount of rewards as his effective balance was already decreased.

Example:

• user calls withdraw and his effective balance is decreased and rewards are claimed

• user do not receive sdl until batch is finalized

• rewards for the batch are sent and user calls executeQueuedOperations to unstake

• user do not receive part of distributed rewards, however he should as his funds were locked till the end of previous batch

Impact

User do not receive all rewards

Tools Used

VsCode

Recommendations

Pay rewards for user for all staked time.