Closed sherlock-admin2 closed 2 months ago
Escalate
I don't understand why my report was marked as a duplicate of https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/42
The report https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/42 only shows the discrepancy between the code and the comments, but my report shows an incorrect calculation if fee token (
output
) is one of thelpToken
, becausebalances()
function relies onbalanceOf()
. Look at the Impact section - I clearly explain why this will lead to a loss of funds, my report is not about "incorrect code comment".My report should be duplicate of https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/71: same root cause, same issue explanation, same impact, same recommendation.
The escalation could not be created because you are not exceeding the escalation threshold.
You can view the required number of additional valid issues/judging contest payouts in your Profile page, in the Sherlock webapp.
Escalate
Watson mentioned: Report should be a duplicate of #71.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
I don't understand why my report was marked as a duplicate of https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/42
The report https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/42 only shows the discrepancy between the code and the comments, but my report shows an incorrect calculation if fee token (output) is one of the lpToken, because balances() function relies on balanceOf().
Look at the Impact section - I clearly explain why this will lead to a loss of funds, my report is not about "incorrect code comment". The code comments in my report is ONLY to show that the incorrect calculation in the balances()
function is not a design choice, and nothing more.
My report should be duplicate of https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/71: same root cause, same issue explanation, same impact, same recommendation.
Also note, that https://github.com/sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging/issues/42 only identifies root cause:
- In addition to this, there is a submission D which identifies the core issue but does not clearly describe the impact or an attack path. Then D is considered low.
In contrast, I clearly demonstrated the impact and attack path.
I believe this is not a duplicate of 71 because the root causes are not the same. 71 is as a result of the fact that one of the LPtokens can be the output token causing broken accounting
As stated in the comments, fees is token0 : In this case function balances() will always return too big value of total0
Based on the comments, I assumed that output
might be the same as lptoken0
. Do you agree with this assumption?
Agree this is a duplicate of #71. While not really clear, watson gave a sufficient example of the fee being charged as token0. Since fee is charged in output token, this implicitly implies the fee being charged as token0 and hence the resulting issue.
However, whether or not the escalation is accepted depends on validity of #71, which will be separately considered. Per sherlock rules for escalation. Please avoid continuing discussions here and monitor discussions for #71 instead
- Escalation will not be accepted in case the reward distribution is not affected. Example: If an escalation says
This issue must be a duplicate of #23
and if the main issue 23 is already a low/invalid issue and is not escalated. Then that escalation would be rejected since it would not affect reward distribution.
Based on planned escalation resolution in issue #71, planning to accept escalation and make issue a duplicate of #71
Result: Medium Duplicate of #71
DenTonylifer
high
StrategyPassiveManagerVelodrome does not take into account unharvested fees
Summary
StrategyPassiveManagerVelodrome.sol
does not take into account unharvested fees, which will lead to inaccurate calculations and losing fees, as the functionbalances()
will return an incorrect value oftotal0
.Vulnerability Detail
Before every
deposit/withdraw
vault callsbeforeAction()
function. This is necessary for the calculation of amounts indeposit/withdraw
functions in vault to be accurate:The protocol expects this function to harvest a fees (for accounting purposes). But instead this function actually increases the amount of unharvested fees (because of calling
_claimEarnings()
):Next, the function
balances()
is called. It is expected to returnbalance of this contract + balance of positions - feesUnharvested
:But it does not take into account unharvested fees and only returns
balance of this contract + balance of positions
.Also note:
Impact
As stated in the comments,
fees
istoken0
:In this case function
balances()
will always return too big value oftotal0
. It will lead to incorrect calculation indeposit/withdraw
inBeefyVaultConcLiq.sol
. Alsopanic()
finction relies on the value of this function and will not revert even if amount oftoken0
in the strategy is less thatbal0
, so this check will not revert, causing to bypassing slippage check:Also note that
fees
is rewards from the gauge, not part of deposited funds, so they should not be withrawable. Here is attack scenario (some details omitted for simplicity):token0.balanceOf(address(this))
= 1050, where user's deposit = 1000, and unharvested fees = 50 tokensUser redeems 1000 shares and receives 1050 tokens: _amount0 = (_bal0 _shares) / _totalSupply = (1050 1000) / 1000 = 1050
Code Snippet
Link 1 Link 2
Tool used
Manual Review
Recommendation
Change the code as follows:
Duplicate of #71