# Oracle look-ahead via resettable execution gates

User-resettable timestamps or request IDs that let orders or draws peek at future oracle output

_Area: DeFi oracles, liquidations and flash loans. Seen in 3 disclosed reports; latest 2023-04-20. Updated 2026-10-24._

## How it works
Execution is gated on a value the user can move. A limit order only runs once the oracle's block range is strictly past `orderUpdatedAtBlock`, and `updateOrder()` resets that field for free. A raffle's `fulfillRandomWords` only accepts the stored `requestId`, and `redraw()` rotates it. In both cases the user can keep the pending action alive while the oracle's answer becomes visible, then commit or discard based on what they saw. The broken assumption: that the gate timestamp or request ID is fixed once the action is submitted.

## Where it shows up
- Validation comparing oracle block numbers against a mutable `orderUpdatedAtBlock` or similar last-touched field.
- Any user-callable update path that rewrites that field with no delay, fee, or cooldown.
- Strict `>` versus `>=` checks that push execution at least one extra block range out.
- Async callbacks (VRF, price feed) guarded by a stored request ID that another function can overwrite.
- Cooldowns shorter than the oracle's worst-case response window (e.g. 1h redraw vs 24h underfunded VRF).
- Sibling order types with different validation logic for the same check.

## How to review
Identify every value that gates execution, then ask who can change it and how cheaply. The invariant: once an action is submitted, no user-triggerable call may extend its validity window or replace its pending oracle request before the oracle responds. Check that the gate is monotonic and not user-writable, or that updates carry a cost or delay exceeding the oracle's response window. Compare all order types and all callback consumers for the same check.

## Variants seen
- Free look-ahead by repeatedly nudging `orderUpdatedAtBlock` by ±1 wei to delay execution while watching signed prices [E3](https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-15.md).
- Stricter block check on LimitSwap than MarketSwap, leaving a two-block-range gap after a partial fix [E1](https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AH-4.md).
- Request-ID rotation via `redraw()` to discard unfavorable VRF randomness [E2](https://bugbountylibrary.com/r/c4%3A2022-12-forgeries%3AH-02.md).

## Why fixes fail
E1 shows a fix applied to LimitDecrease/StopLossDecrease that did not cover LimitSwap; the same validation gap survived in a sibling order type [E1](https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AH-4.md).

## Impact and severity
Risk-free look-ahead lets traders cherry-pick favorable fills and abandon unfavorable ones, and lets a draw host rig raffle winners [E1](https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AH-4.md)[E2](https://bugbountylibrary.com/r/c4%3A2022-12-forgeries%3AH-02.md)[E3](https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-15.md). Severity is high where value settles on the peeked price or randomness. Worse when the reset is free and repeatable, and when the oracle window is long relative to any cooldown.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AH-4.md
- E2: https://bugbountylibrary.com/r/c4%3A2022-12-forgeries%3AH-02.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-15.md