Rounding errors can lead to DoS of the removal of liquidity
When someone wants to remove liquidity, the protocol accounts a certain amount of fees to the quant admin. These fees are accounted by adding liquidity using the percentage of fee in each token and expecting the same percentage of minimum BPT out:
When it adds this liquidity it passes as maxAmountsIn
the accruedQuantAMMFees
array that are the amounts of each token that represented the fee. Also this addition expects a minBptAmountOut
of the percentage of fee extracted from the total BPT. This can be really problematic because rounding errors in token amount computations can yield to not meet the minBptAmountOut
. So if this happens, the user will be unable to remove any of his liquidity.
For example, if the pool require that to receive 1 BPT it needs 10e18 tokenA and 20e18 tokenB, if the computations of the fee tokens yield to provide 10e18 and 19.999999999999999999 of tokenB due to rounding error, the return would be something like 0.999999999999999999 BPT. This would not meet the 1 BPT and the addition of liquidity would revert.
Since this addition of liquidity is done in between a transaction, the minBptAmountOut
could be set to 0 and it would have no risk of being sandwitched. This would prevent the addition of liquidity from reverting because of the minBptAmountOut
not met.
Medium, the removal of liquidity would revert
Manual review
Setting the minBptAmountOut
would be the best solution to this:
Likelihood: High, multiple rounding down and little value can trigger the bug Impact: High, DoS the removal.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.