# Delayed orders won't use correct prices

GMX delayed orders priced via Chainlink latestRoundData use current price instead of submission-time price, mispricing fills during depegs.

- Payout: Contest reward
- Severity: medium
- Program: Gmx
- Credited: IllIllI
- Disclosed: 2022-09-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/176
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-6
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:oracle-manipulation

**Target:** GMX Synthetics Oracle price feed integration
**Root cause:** Oracle._setPricesFromPriceFeeds reads priceFeed.latestRoundData() at execution time rather than the order submission timestamp, so delayed orders fill at current (post-depeg) prices.
**Steps:**
1. Submit order at time T for a market using both archive and Chainlink price feeds
2. Keeper delays execution to T+N
3. At execution, Oracle._setPricesFromPriceFeeds calls `priceFeed.latestRoundData()` returning current price
4. Order fills at T+N price instead of T price, altering PnL/liquidation outcome
**How found:** Code reading of Oracle._setPricesFromPriceFeeds noting latestRoundData() is read at execution rather than order time, combined with reasoning that archive oracles are omitted for feed-backed tokens, so no historical price is available.
**Exploitation:** Not weaponized; requires a depeg event (e.g. USDC/UST) so delayed orders settle at materially different prices, shifting PnL between traders and the liquidity pool.
**Insight:** When a protocol mixes push-oracle (Chainlink latestRoundData) and pull/archive oracles, check whether deferred execution paths re-read the push oracle at fill time; depeg events turn that into a mispricing vector.