Line of code

https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/df2dd129a878d16d4adc75049179ac0029d9a96b/protocol/contracts/beanstalk/silo/PipelineConvertFacet.sol#L49

https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/df2dd129a878d16d4adc75049179ac0029d9a96b/protocol/contracts/libraries/Convert/LibConvert.sol#L262

Summary

pipelineConvert missing slippage control because of how the penalty is applied

Vulnerability Details

In the pipelineConvertFacet we can observe the following comments.

as the comment suggests, A stalk penalty may be applied if the convert crosses deltaB.

However, while user does a pipeline convert, because there is no slippage control, the user can suffer heavily and unexpected loss from the penalty that he did not account for when submitting his transaction.

as we can see, the penalty depends on the capacity and peg information and the up to 100% of the penalty can be applied.

consider the case when user A submits a pipelineConvert transaction, but then other user submits the transaction that fills in the convert cap and change delta B first before User A,

user A's transaction can suffer high stalk penalty, which is not what user A expected.

Impact

user may receive less tokens than he anticipated because of lack of slippage control

Tools Used

manual review

Recommendations

add a slippage control to check the min token minted amount and let user input the max penalty tolerance.