Lines of code

Vulnerability details

C4 Issue

https://github.com/code-423n4/2024-01-salty-findings/issues/221

Comments

In this issue, the author describes an attack scenario where the crux of the vulnerability lies in the liquidity amount calculation method used by salty's AMM, which is not path-independent. Unlike Uniswap v2, which calculates initial liquidity shares as the geometric mean of the token amounts deposited—ensuring that the value of liquidity pool shares is essentially independent of the deposit ratio, salty's AMM calculates liquidity shares in a way that is influenced by the sequence of actions leading up to the deposit. This lack of path independence means that the number of shares minted for a given deposit can vary significantly based on prior manipulations of the pool's reserves. The attacker exploits this by front-running with an imbalanced deposit to inflate the liquidity shares they receive, and then performing actions that alter the pool's reserves before Alice's deposit. The end result is an artificial inflation or deflation of the value represented by the liquidity shares depending on the manipulated path taken, allowing the attacker to profit from rebalancing the pool at Alice's expense.

Mitigation

https://github.com/othernet-global/salty-io/commit/0bb763cc67e6a30a97d8b157f7e5954692b3dd68

The mitigation for this issue revolved around allowing the user to specify the minimum amounts they want to add for each token, via minAddedAmountA and minAddedAmountB. If an attacker tries to manipulate the pool's prices before Alice's transaction, the specified minAmount0 and minAmount1 ensure her transaction will fail rather than executing at a disadvantageous rate.

Conclusion

LGTM

code-423n4 / 2024-03-saltyio-mitigation-findings