Open hats-bug-reporter[bot] opened 7 months ago
Thank you for the submission.
A conclusion that for Velodorme is also relevant in our case I would also point out that duplicate #45 is more informative in this regard
In my opinion, this presentation is on the verge of medium/high (The conclusion may be revised)
We have a case that shows the loss of funds by certain users if the added initial liquidity is too small, that will make it possible to withdraw this liqudiity through manipulation. Of course, these funds will be small, but it will also not be just dust
The code refers to the part that is OOS, but due to certain criticality(high) and actions with other people's funds
Github username: -- Twitter username: -- Submission hash (on-chain): 0xc75fc74f410b735b4d7fb2f57342daccc15167ac95e6084e242afa093947d666 Severity: high
Description: Context: Pair.sol#511, Pair.sol#364
Description\ The invariant k of a stable pool is calculated as follows
Attack Scenario
The value of _a = (x y ) / 1e18 = 0 due to rounding error when xy < 1e18. The rounding error can lead to the invariant k of stable pools equals zero, and the trader can steal whatever is left in the pool. The first liquidity provider can DOS the pair by: 1.mint a small amount of liquidity to the pool, 2. Steal whatever is left in the pool, 3. Repeat step 1, and step 2 until the overflow of the total supply. To prevent the issue of rounding error, the reserve of a pool should never go too small. The mint function which was borrowed from uniswapV2 has a minimum liquidity check of sqrt(a * b) > MINIMUM_LIQUIDITY; This, however, isn't safe enough to protect the invariant formula of stable pools
Recommendation: Recommend to add two restrictions on the first lp of stable pools: