I have a different view on the @ArrakisFinance attack, analyzed by @exvulsec... (xitter.cf/exvulsec/status/209152…) The root cause has nothing to do with spot oracle price manipulation! (While it is true that the protocol uses the spot oracle price.) Instead, the attacker stole the unclaimed LP fees with a "sandwich" attack. Here is why: The mint and redeem functions both require the input and output to be proportional to the `deposited LP + unclaimed fees + idle balance` in the two tokens. That means, if the pool holds x:y of token A:token B (in the LP position, plus fees and idle balance), your input/output will also be proportional to x:y. Thus, you cannot manipulate the price to fool the vault, because no matter how the tokens are priced, your minted vault shares are simply proportional to your deposit relative to the actual amounts of the two tokens. However, when burn() is called, the fees are collected. These fees are then compounded into the pool. This creates the vulnerability. The attacker then performs: swap1 → mint → swap2 → burn → swap3. After swap1, and later when burn() is called, the collected fees add more liquidity back to the LP, so when swapping back in swap3, the attacker can end up with more tokens. To sum up, the root cause is an "atomic sandwich attack" on the idle balance plus unclaimed swap fees, not "oracle manipulation". This also explains why the hacker left a significant amount lot of LP in the vault untouched. Fun fact: I reviewed their code back when Gamma (another Uniswap V3 liquidity manager) was exploited in 2024. Arrakis's vault requires proportional input/output, so it is not vulnerable to the same issue (while Gamma allows you to input tokens in any proportion and reads the spot oracle price).