Submitted by erebus, also found by windowhan001, oakcobalt, adeolu, and thank_you
Vanilla example of missing slippage protection.
As any AMM, Orca implements slippage protections by letting the caller specify the minimum amount of input and output tokens to be used in a given operation, so that if the transaction outputs a value less than the expected ones, it will revert preventing users from incurring in unacceptable losses.
In our situation, we are interested in the decreaseLiquidity handler:
decrease_liquidity, lines 18 and 19
The code snippet above calculates the delta variations of the two tokens amount in the given pool and reverts the whole transaction if the calculated amounts are less than the specified ones. However, if we go to:
liquidity_lockbox, function withdraw
We see that token_min_a and token_min_b are hard-coded to $0$, meaning that the liquidity decrease operation will accept ANY amount in exchange, even $0$, leading to a loss of funds as MEV exists in Solana too (see here). The mathematical reason is that:
$x >= 0, \forall x \in \[0, 2-1]$
So the errors:
Wont be triggered as:
Meaning there is no slippage protection at all if called with token_min_a = token_min_b = 0 (as its the case with liquidity_lockbock::withdraw).
Let users provide the minimum amount of tokens they are willing to use as function arguments and pass them straight to decreaseLiquidity like:
mariapiamo (Olas) confirmed, but disagreed with severity
LSDan (Judge) decreased severity to Medium
For this audit, 25 reports were submitted by wardens detailing low risk and non-critical issues. The report highlighted below by IllIllI received the top score from the judge.
The following wardens also submitted reports: 7ashraf, slvDev, 0xA5DF, lsaudit, cheatc0d3, EV_om, immeas, SpicyMeatball, hash, 0x11singh99, oakcobalt, erebus, imare, para8956, trachev, lil_eth, peanuts, 0xMilenov, Bauchibred, 0xTheC0der, Sathish9098, joaovwfreire, rvierdiiev, and Kaysoft.
Note: Ive removed the instances reported by the winning bot and 4naly3er.
