Summary

User might lose bdv on individual deposits when calling enrootDeposits

Vulnerability Details

The way enrootDeposit works is that if a user has a deposit in an unripe token and its bdv (Bean denominated value) has increased, the user can call the function and update the deposit to the current appropriate bdv

The problem is that this invariant is not enforced for individual deposits when using enrootDeposits. When using enrootDeposits it's only looked that the total new bdv is larger than the old total bdv.

Meaning that if a user has had to equal deposits at bdv $1.00 and $1.20, they've called the function enrootDeposits when the actual bdv is $1.15, the transaction would succeed, although the user has lost bdv on their 2nd deposit (and it would've been more profitable for them if they had simply enrooted the first deposit only).

Since bdv is dynamic (based on an oracle's value) and a user's transaction might be stuck for a long time (e.g. due to set low gas), user could accidentally execute the transaction in suboptimal conditions, resulting in a loss.

Impact

Loss of bdv(and therefore stalk (governance power) and roots too)

Tools Used

Recommendations

Check that the bdv of each individual deposit is less than the current bdv