Liquid Staking

Summary

The implementation of the LSTRewardsSplitter contract utilizes a burn function on the lst token to remove tokens from circulation as a form of transaction fee during the reward distribution process. However, the lst token does not include an implemented burn function, which will result in transaction reverts and disrupt the intended economic mechanisms within the contract. This report outlines the critical issues related to this missing functionality.

Vulnerability Details

The line IStakingPool(address(lst)).burn(amount); in _splitRewards as shown below assumes that the lst token conforms to the implementation of the burn function. However, the lst token does not directly implement a burn function and also does not inherit one from any of its parent classes. Also the deployed stLink contract that it represents does not define an implementation for the burn function as well, here is a quick link to verify https://etherscan.io/address/0xb8b295df2cd735b15be5eb419517aa626fc43cd5#writeProxyContract.

Impact

The performUpkeep and splitRewards functions of the splitter will revert whenever _splitRewards tries to call the non-existent burn function which will affect the intended functionality of burning the liquid staking tokens when the fee.receiver == address(lst). Burning tokens serves a dual purpose of facilitating transaction fees and managing token supply. Without a functioning burn method, the contract's economic model is compromised, preventing the intended deflationary pressure on the token supply that could increase the value of remaining tokens.

Tools Used

Manual Code Review

Recommendations

• To add burning functionality, you can extend it with ERC20Burnable extension in OpenZeppelin Libraries.

• Create a custom implementation for the burn function.