# Gas spikes after outages may prevent order execution

GMX order execution fee can't be topped up without resetting the order timestamp, so gas spikes after outages leave orders unexecutable and positions liquidatable.

- 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/173
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-9
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** GMX Synthetics OrderHandler order execution/keeper fee logic
**Root cause:** Updating executionFee calls order.touch(), resetting the order's update timestamp which gates oracle price validity; users cannot raise the fee to survive post-outage gas spikes without invalidating their price window.
**Steps:**
1. Create an order with a generous executionFee and a valid oracle price window.
2. Keeper/oracle network outage delays execution past the oracle price validity window.
3. Gas prices spike on recovery due to queued orders/liquidations.
4. Attempt to top up executionFee via OrderHandler update path: `order.setExecutionFee(order.executionFee() + receivedWnt)` then `order.touch()` resets timestamp.
5. Order's oracle price window is now invalidated; order cannot execute at intended price.
**How found:** Code reading of OrderHandler update path noticing order.touch() is always called when topping up executionFee, and reasoning about outage/gas-spike scenarios where the fee becomes insufficient.
**Escalation:** Delayed execution during gas spike can turn a profitable position into a loss or liquidation.
**Insight:** When a fee/timestamp field is coupled to price-validity logic, check whether any legitimate user action (fee top-up, partial fill) silently resets the validity window and locks the user out during congestion.