Liquid Staking

Summary

Potential Denial of Service (DoS) vulnerability in LSTRewardsSplitter contract's _splitRewards function due to failed transfers to contract addresses and potential restrictions from account abstraction wallets.

Relevant Link

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/lstRewardsSplitter/LSTRewardsSplitter.sol#L140
https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/lstRewardsSplitter/LSTRewardsSplitter.sol#L151

Vulnerability Details

The vulnerability occurs in the _splitRewards function, where rewards are distributed to multiple fee receivers. Since the function transfers lst tokens (an ERC677 token) to various addresses, there is a risk of DoS if any of the fee receiver addresses is a contract that does not implement the onTokenTransfer function, required for ERC677 transfers. In such cases, the transfer will fail, causing the entire transaction to revert, which prevents other fee receivers from receiving their rewards.

Additionally, some account abstraction wallets may restrict token transfers. These wallets introduce custom logic in their operations and might block or restrict the receipt of tokens due to security or design policies. This could further exacerbate the issue if the wallet of any fee receiver blocks the transfer, leading to the same transaction revert scenario and disrupting the reward distribution.

The combination of relying on external contracts and wallet designs makes the transfer process fragile, as one failure could block rewards for all recipients.

Impact

Fee receivers may be unable to claim their rewards due to failed token transfers, either because the recipient is a contract without onTokenTransfer support or due to restrictions in account abstraction wallets. This could cause partial or complete failure of reward distribution, leading to financial losses for users and disrupting the intended functionality of the protocol.

Tools Used

Manual Review

Recommendations

The protocol should adopt a pull-over-push reward distribution mechanism. Instead of pushing funds to all receivers in a single transaction, the pull pattern allows each user to independently withdraw their rewards. This minimizes risks by isolating potential failures to individual transactions, improves compatibility with a broader range of contract types and wallets, and spreads out gas costs.