Liquid Staking
Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Lack of slippage protection mechanism when interacting with Staking Pool

dimah7

Vulnerability Details

When users interact with the Staking Pool, through the Priority Pool by calling functions like PriorityPool::executeQueuedWithdrawals(), deposit(), depositQueuedTokens(), performUpkeep(), claimLSDTokens() or StakingPool::burn() there is a call at some point to:

function getSharesByStake(uint256 _amount) public view returns (uint256) {
uint256 totalStaked = _totalStaked();
if (totalStaked == 0) {
return _amount;
} else {
return (_amount * totalShares) / totalStaked;
}
}
​
function getStakeByShares(uint256 _amount) public view returns (uint256) {
if (totalShares == 0) {
return _amount;
} else {
return (_amount * _totalStaked()) / totalShares;
}
}

These functions are used to calculate the amount of liquid staking tokens that corresponds to an amount of shares or the opposite. As can be seen the returned value is heavily reliant to variables like totalStaked and totalShares. They are also retrieved when distributing rewards and fees:

function _updateStrategyRewards(uint256[] memory _strategyIdxs, bytes memory _data) private {
...
if (totalFeeAmounts > 0) {
uint256 sharesToMint = (totalFeeAmounts * totalShares) /
(totalStaked - totalFeeAmounts);
_mintShares(address(this), sharesToMint);
...

Here minting new shares ensures that the system fairly reflects the fees distributed. However currently the protocol lack slippage protection mechanism. This could lead to fund loss from slippage when core functions are called as the provided formula or variables are manipulatable while users transactions are pending in the mempool by depositing, burning or donating for instance.

Tools Used

Manual Review

Recommendations

When introducing shares to a prootcol having min expected amount variables are obligatory. Allow users to specify a slippage tolerance when interacting with the forementioned functions

Updates

Lead Judging Commences

inallhonesty Lead Judge
about 1 year ago
inallhonesty Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Appeal created

dimah7 Submitter
12 months ago
inallhonesty Lead Judge
12 months ago
inallhonesty Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.