Closed sherlock-admin3 closed 4 months ago
This works as intended, get tokens required is making sure we allocate appropriate shares. It does not care whether or not we are in range.
Escalate
I believe this is still a valid issue. while _getTokensRequired goal might be to allocate appropriate shares, is also determines how much of each token is taken from the depositor. In the case described, the function chooses to utilize the wrong token (causing a net loss for depositors). This is a side effect of the price being out of range which is why the function should be aware of this situation and handle it (as described in Recommendations).
Escalate
I believe this is still a valid issue. while _getTokensRequired goal might be to allocate appropriate shares, is also determines how much of each token is taken from the depositor. In the case described, the function chooses to utilize the wrong token (causing a net loss for depositors). This is a side effect of the price being out of range which is why the function should be aware of this situation and handle it (as described in Recommendations).
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.
Escalate I believe this is still a valid issue. while _getTokensRequired goal might be to allocate appropriate shares, is also determines how much of each token is taken from the depositor. In the case described, the function chooses to utilize the wrong token (causing a net loss for depositors). This is a side effect of the price being out of range which is why the function should be aware of this situation and handle it (as described in Recommendations).
Escalate I believe this is still a valid issue. while _getTokensRequired goal might be to allocate appropriate shares, is also determines how much of each token is taken from the depositor. In the case described, the function chooses to utilize the wrong token (causing a net loss for depositors). This is a side effect of the price being out of range which is why the function should be aware of this situation and handle it (as described in Recommendations).
Still not valid. There is no issue here and it works as it should. The main goal is to create a 50/50 balance with getTokensRequired() and this accomplishes that. The strategy position has no impact on this. The shares are calculated while there is no active position as the funds are removed, shares are calculated and issued and then the strategy is put back to work.
Agree with sponsor comments, planning to reject escalation and leave issue as it is.
Result: Invalid Unique
nirohgo
medium
_getTokensRequired calculation is wrong when the current price tick is out of the current position range, causing loss of potential earnings
Summary
The calculation in _getTokensRequired (which calculates how much to take of the depositor's amount0 and amount1 for optimized utility) produces an incorrect result in the case that the price is out of the main position range and rebalance hasn't been called yet, causing inefficient utilization of liquidity.
Vulnerability Detail
background information
When a user deposits to the ConcLiq vault, the order of operations is:
First, uniswap fees are claimed and all liquidity is removed from the Uniswap pool:
Then _getTokensRequired is called to find out the ideal amount to take from the depositor's offered amount0 and amount1. This calculation considers the current balances in the strategy (after they've been removed from the pool) and the current price, and tries to utilize the user's amount0 and amount1 to the maximum, while getting the balances ratio to be as close to the current price ratio (so that when liquidity is added back to the main position, a maximum portion of the balances is utilized).
After the calculated amount0 and amount1 have been transfered from the depositor to the StrategyPassiveManagerUniswap, the StrategyPassiveManagerUniswap deposit function is called. This function calls setTicks (which updates the position ticks) only if the ticks were never initialized before, and then calls _addLiquidity.
The _addLiquidity function first tries to add as much of the balances to the current main position range and the rest to the alt postion, but if the current price is out of the main position range (checked by _checkAmounts) the main position is skipped and all liquidity is added only to the alt position
// Flip minting to true and call the pool to mint the liquidity. if (liquidity > 0 && amountsOk) { minting = true; IUniswapV3Pool(pool).mint(address(this), positionMain.tickLower, positionMain.tickUpper, liquidity, "Beefy Main"); }