# MagicLpAggregator doesn't consider the dcimal of MagicLP

MagicLpAggregator normalizes oracle and reserve decimals but not MagicLP totalSupply decimals, so LP price is wrong when base token decimals != 18.

- Payout: Contest reward
- Severity: medium
- Program: Abracadabra Money
- Credited: ether\_sky
- Disclosed: 2024-05-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-03-abracadabra-money-findings/issues/90
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-abracadabra-money%3AM-12
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:oracle-manipulation vuln:precision-loss

**Target:** MagicLpAggregator oracle (Solidity contract)
**Root cause:** latestAnswer() scales base/quote oracle answers and reserves to WAD but divides by pair.totalSupply() without scaling it, while MagicLP decimals equal the base token's decimals (not always 18).
**Steps:**
1. Deploy MagicLP with base token of 12 decimals and quote of 18 decimals.
2. Set base oracle decimals=8, quote oracle decimals=12, both price 4 USD.
3. Pool holds 5 base and 5 quote tokens; totalSupply = 5 * 10**12.
4. Call MagicLpAggregator.latestAnswer(): reserves and oracle answers are normalized to 18 decimals but totalSupply is not.
5. Observe returned price ~8,000,000 USD instead of correct 8 USD (off by 10**(18-baseDecimals)).
**How found:** Code reading: noticed MagicLP.decimals() returns base token decimals, then compared MagicLpAggregator's normalization of oracles and reserves against its unnormalized totalSupply division.
**Exploitation:** Not demonstrated; mispricing of MagicLP collateral in Cauldrons could allow over-borrowing if a non-18-decimal base token pool is used as collateral.
**Insight:** When an oracle normalizes reserves and prices to WAD, check every term in the final division—especially LP totalSupply, whose decimals mirror the base token, not a fixed 18.