ZanyBonzy - Lack of slippage control during staking in bedrock

[sherlock-admin4]

ZanyBonzy

medium

Lack of slippage control during staking in bedrock

Summary

No slippage control when staking for uniETH

Vulnerability Detail

When prefundedDeposit function is called, the function routes to the _stake function which is used to mint uniETH tokens from bedrock. The function calls the mint function passing in 0 as the minimum amount to mint. Setting the minToMint parameter to zero means that the protcol is willing to accept any and all available amount returned by bedrock, opening the protocol to sandwich attack, slippage losses. A large ETH stakeAmount could potentially mint very small amount of uniETH, causing loss of funds.

    function _stake(uint256 stakeAmount) internal override returns (uint256) {
        if (stakeAmount == 0) return 0;

        IWETH9(Constants.WETH).withdraw(stakeAmount);
        uint256 _balance = UNIETH.balanceOf(address(this));
        BEDROCK_STAKING.mint{value: stakeAmount}({minToMint: 0, deadline: block.timestamp + 1});
        uint256 minted = UNIETH.balanceOf(address(this)) - _balance;
        if (minted == 0) revert InvariantViolation();

        return stakeAmount;
    }

Impact

Loss of funds, due to unfair mints and slippage losses.

Code Snippet

https://github.com/sherlock-audit/2024-05-napier-update/blob/c31af59c6399182fd04b40530d79d98632d2bfa7/napier-v1/src/adapters/BaseLSTAdapter.sol#L155

https://github.com/sherlock-audit/2024-05-napier-update/blob/c31af59c6399182fd04b40530d79d98632d2bfa7/napier-v1/src/adapters/bedrock/UniETHAdapter.sol#L78

https://github.com/sherlock-audit/2024-05-napier-update/blob/c31af59c6399182fd04b40530d79d98632d2bfa7/napier-v1/src/adapters/bedrock/UniETHAdapter.sol#L80

Tool used

Manual Review

Recommendation

[sherlock-admin2]

2 comment(s) were left on this issue during the judging contest.

z3s commented:

32

PNS commented:

slippage control is (will be) at the Tranche.issue level and not at the adapter level (following issue #84 in the previous contest)

[WangSecurity]

As a Sherlock judge we have limited resources to rejudge people their issue, these resources are allocated through the escalation mechanism. As your issue wasn't escalated I'm not able to rejudge it.

[WangSecurity]

These were duplicates of 88, that was escalated and was duplicated with another issue. Hence, all the duplicates of 88 were also duplicated accordingly.

[WangSecurity]

But both this and #32 weren't duplicated with 88 by the lead judge and wasn't escalated. This is why these weren't rejudged.