# Oracle staleness parameter tampering

Risk parameters like staleAfter, price bounds, or oracle versions set without caps, letting stale prices or overflow block settlement

_Area: DeFi oracles, liquidations and flash loans. Seen in 2 disclosed reports; latest 2024-08-17. Updated 2026-10-24._

## How it works
A price or risk parameter that should be tightly bounded is instead trusted as-is. The code assumes whoever sets it (admin, coordinator, or position owner) will pick a sane value, so it never enforces a cap. When the value is extreme, downstream math either uses a very old price as if current, or overflows, or skips limit checks. The broken assumption is "the parameter is bounded"; nothing in code makes it so.

## Where it shows up
- Staleness windows (`staleAfter`, oracle timeout) written with no min/max check [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-6.md)
- User- or owner-settable prices feeding multiplication in liquidation/challenge paths [E2](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-05.md)
- Oracle version invalidation that adjusts positions without re-running limit checks [E3](https://bugbountylibrary.com/r/sherlock%3A2023-10-perennial%3AM-3.md)
- Settlement logic that accepts a committed price without comparing age to a bounded window [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-6.md)
- Asymmetric guards: one direction checked (`closable`), the mirror (`openable`) not [E3](https://bugbountylibrary.com/r/sherlock%3A2023-10-perennial%3AM-3.md)

## How to review
For every parameter that influences pricing or settlement, find its setter and confirm an enforced bound exists in code, not just in docs or deployment practice. The invariant: any staleness window, price, or version must be clamped to a range where settlement math stays correct and limits still hold. Trace each parameter into the multiplication/comparison it feeds and check the extreme values (max uint, zero, huge window) cannot bypass a limit or overflow. For oracle invalidation, confirm position limits are re-checked after adjustment in both directions.

## Variants seen
- Coordinator sets `staleAfter` to uint24.max, settling against a very old price and creating bad debt [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-6.md)
- Owner sets price to uint256.max, overflowing challenge math so liquidation reverts and challenger funds are trapped [E2](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-05.md)
- Invalid oracle version invalidates pending positions past `makerLimit`, bricking updates [E3](https://bugbountylibrary.com/r/sherlock%3A2023-10-perennial%3AM-3.md)

## Why fixes fail
E3 shows a partial guard: underflow was protected via `closable` but the symmetric increase case had no `openable` check, so the fix covered one direction only.

## Impact and severity
High: full collateral drain [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-6.md), blocked liquidation with trapped capital [E2](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-05.md), and a bricked market [E3](https://bugbountylibrary.com/r/sherlock%3A2023-10-perennial%3AM-3.md). Severity rises when a privileged role or any user can set the value and when the extreme value is reachable in normal operation.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-6.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-05.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2023-10-perennial%3AM-3.md