# Anyone making use of the MagicLP's TWAP to determine token prices will be exploitable.

MagicLP updates its TWAP cumulative after reserve changes, letting an attacker frontrun a price query to set the entire elapsed-window TWAP to an inflated value.

- Payout: Contest reward
- Severity: high
- Program: Abracadabra Money
- Credited: Trust
- Disclosed: 2024-05-03
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-03-abracadabra-money-findings/issues/227
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-abracadabra-money%3AH-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:chained technique:source-review vuln:oracle-manipulation

**Target:** MagicLP AMM TWAP oracle (_BASE_PRICE_CUMULATIVE_LAST_)
**Root cause:** _twapUpdate() is called after reserves are modified, so the new (attacker-influenced) mid-price is multiplied by the full time elapsed since the last update, retroactively setting the cumulative for the whole window.
**Steps:**
1. At T0 cumulative = X, integrator records (T0, X).
2. T seconds pass with no swaps; price stays X.
3. Victim contract queries _BASE_PRICE_CUMULATIVE_LAST_ to price a large swap.
4. Attacker frontruns with a large swap inflating base reserves; new mid-price Y >> X.
5. _twapUpdate runs after reserve change: cumulative becomes X + Y*T.
6. Integrator computes TWAP = (X+Y*T - X)/T = Y, the manipulated price.
7. Victim trades at bad price; attacker swaps back, netting profit minus fees.
**How found:** Code reading of _twapUpdate ordering versus reserve mutation, compared against UniswapV2 and Beanstalk which update cumulative before reserves; recognized the retroactive multiplication of new price by elapsed time.
**Exploitation:** Attacker observes a pending TWAP-consuming swap, frontruns with a large swap to inflate reserves so the post-update cumulative reflects the inflated price across the whole elapsed window, victim executes at manipulated price, attacker reverses swap to profit.
**Insight:** When auditing TWAP oracles, check the ordering of cumulative-price update relative to reserve mutation: if the cumulative is written after reserves change, the new spot price is applied retroactively to the entire elapsed interval, making the oracle fully manipulable by a single frontrun.