# Missing checks for whether Arbitrum Sequencer is active

GMX Synthetics oracle reads Chainlink price feeds without checking Arbitrum sequencer uptime, so stale prices during sequencer downtime could let keepers execute orders at nonexistent prices.

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

**Target:** Solidity oracle contract (Oracle._setPricesFromPriceFeeds) on Arbitrum
**Root cause:** Oracle._setPricesFromPriceFeeds calls priceFeed.latestRoundData() without verifying the Chainlink L2 sequencer uptime feed, so prices can be stale while the sequencer is offline.
**Steps:**
1. Observe Oracle.sol `_setPricesFromPriceFeeds()` reads `priceFeed.latestRoundData()` and casts `_price` to uint256
2. Note no sequencer uptime feed is consulted anywhere in the price path
3. Assume sequencer goes down; L2 oracle aggregation transactions stop being processed
4. Prices remain stale (e.g. USDC de-peg not reflected)
5. Submit orders (as user and keeper) that execute against the stale price
**How found:** Code review of the oracle price path against Chainlink's documented L2 sequencer-uptime recommendation; noticed latestRoundData is used with no sequencer health check.
**Exploitation:** If the sequencer is offline and a real price moves (e.g. USDC de-peg), a user who is also a keeper can submit orders that get filled at stale, nonexistent prices, extracting value from the protocol.
**Insight:** On L2 deployments, audit every Chainlink latestRoundData consumer for a paired sequencer uptime feed check; the price feed alone cannot signal downtime because aggregation txs are L2-submitted.