if (param.sellSlippage > bank.config().maxSlippageOfClose())
revert Errors.RATIO_TOO_HIGH(param.sellSlippage);
to check the slippage for Uniswap.
A Curve pool is considered imbalanced when there is an imbalance between the assets within it. For instance, the Curve stETH/ETH pool is considered imbalanced if it has the following reserves:
ETH: 340,472.34 (31.70%)
stETH: 733,655.65 (68.30%)
Vulnerability Detail
If a Curve Pool is imbalanced, attempting to perform a proportional join will not give an optimal return (e.g. result in fewer Pool LP tokens received).
In Curve Pool, there are penalties/bonuses when depositing to a pool. The pools are always trying to balance themselves. If a deposit helps the pool to reach that desired balance, a deposit bonus will be given (receive extra tokens). On the other hand, if a deposit deviates from the pool from the desired balance, a deposit penalty will be applied (receive fewer tokens).
The source code of add_liquidity(). The function attempts to calculate the difference between the ideal_balance and new_balances, and uses the difference as a factor of the fee computation, which is tied to the bonus and penalty.
(by xiaoming90)
But in Convex and Curve SPELL this line repeat several times
The minLPMint has no check for it
This could lead to:
Impact
1- users could be exposed to a front-run attack
2- users could be exposed to big penalties from the Curve Pool in case it becomes imbalanced ( there are multiple instances where the largest Curve pool (stETH/ETH) becomes imbalanced (Reference 01 and 02 )
So there is no guarantee that a Curve Pool will always be balanced
Ch_301
high
users could be exposed to big penalties from the Curve Pool
Summary
On Ichi SPELL the protocol use this
to check the slippage for Uniswap.
A Curve pool is considered imbalanced when there is an imbalance between the assets within it. For instance, the Curve stETH/ETH pool is considered imbalanced if it has the following reserves:
Vulnerability Detail
If a Curve Pool is imbalanced, attempting to perform a proportional join will not give an optimal return (e.g. result in fewer Pool LP tokens received).
In Curve Pool, there are penalties/bonuses when depositing to a pool. The pools are always trying to balance themselves. If a deposit helps the pool to reach that desired balance, a deposit bonus will be given (receive extra tokens). On the other hand, if a deposit deviates from the pool from the desired balance, a deposit penalty will be applied (receive fewer tokens).
The source code of add_liquidity(). The function attempts to calculate the
differencebetween theideal_balanceandnew_balances, and uses thedifferenceas a factor of the fee computation, which is tied to the bonus and penalty. (by xiaoming90)But in Convex and Curve SPELL this line repeat several times
The minLPMint has no check for it This could lead to:
Impact
1- users could be exposed to a front-run attack 2- users could be exposed to big penalties from the Curve Pool in case it becomes imbalanced ( there are multiple instances where the largest Curve pool (stETH/ETH) becomes imbalanced (Reference 01 and 02 ) So there is no guarantee that a Curve Pool will always be balanced
Code Snippet
Tool used
Manual Review
Recommendation
check the received LP token's value
Duplicate of #126