# Incorrect UPPER_118BITS_MASK mask in OraclePackLibrary causes unexpected clearing of EMAs and lockMode in OraclePack

Incorrect UPPER_118BITS_MASK in OraclePackLibrary.rebaseOraclePack clears EMAs and lockMode bits, corrupting OraclePack state during rebase.

- Payout: Contest reward
- Severity: medium
- Program: Panoptic
- Credited: joicygiore
- Disclosed: 2026-03-09
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-12-panoptic-next-core#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2025-12-panoptic-next-core%3AM-04
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** OraclePackLibrary.rebaseOraclePack bitmask in OraclePack.sol
**Root cause:** UPPER_118BITS_MASK is 130 bits instead of 138, so the AND in rebaseOraclePack clears the lower bits of EMAs and lockMode along with referenceTick/residuals.
**Steps:**
1. Read OraclePack layout: epoch(24)|orderMap(24)|EMAs(88)|lockMode(2) = 138 bits.
2. Note UPPER_118BITS_MASK = 0xFFFF...C000...0 spans 130 bits, not 118.
3. Call rebaseOraclePack(oraclePack) with nonzero EMAs/lockMode.
4. Observe `(OraclePack.unwrap(oraclePack) & UPPER_118BITS_MASK)` zeroes EMAs and lockMode bits.
5. Run provided Foundry PoC test_poc_rebaseOraclePack to confirm corruption.
**How found:** Code review of the mask constant against the documented OraclePack bit layout; noticed mask length mismatch (130 vs 138 bits) causing unintended clearing.
**Insight:** When auditing bitmask constants, recompute the exact bit width from the struct layout and verify the mask's hex length matches; off-by-N mask widths silently corrupt adjacent packed fields.