You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 24, 2023. It is now read-only.
Limit orders are delayed by a block due to oracle block number restrictions, in combination with requiring ascending/descending prices. Limit orders have special logic to ensure that they're only triggered when the price approaches the trigger price. To ensure the two prices (the primary price and secondary price) used for determining the price direction are not prices from before the order is placed, the oracle code requires that oracle price block numbers all come after the block where the order was placed.
Vulnerability Detail
Rather than requiring that only the secondary (later endpoint) price comes after the block in which the order was placed, both the secondary and the primary price are required to come after the order block.
Impact
Consider the case where a user wants to set a stoploss at a price of 100, and they submit an order at the indicated block/price:
An order submitted at the indicated block would be unable to be filled using the prices at block range [2,3], and instead would be forced to use [4,5] block range. This on its own is not an issue, but if the order is combined with a swap whose price impact penalty in [2,3] is very small, but is very large in [4,5], the user will be understandably unhappy about the order execution.
Code Snippet
All oracle prices are required to come after the order timestamp, including both the position and the swap prices:
Allow a price that is separate from the primary and secondary prices, to come before the order block, and allow the primary/secondary prices to equal the order block
The text was updated successfully, but these errors were encountered:
IllIllI
medium
Limit orders are unnecessarily delayed by a block
Summary
Limit orders are delayed by a block due to oracle block number restrictions, in combination with requiring ascending/descending prices. Limit orders have special logic to ensure that they're only triggered when the price approaches the trigger price. To ensure the two prices (the primary price and secondary price) used for determining the price direction are not prices from before the order is placed, the oracle code requires that oracle price block numbers all come after the block where the order was placed.
Vulnerability Detail
Rather than requiring that only the secondary (later endpoint) price comes after the block in which the order was placed, both the secondary and the primary price are required to come after the order block.
Impact
Consider the case where a user wants to set a stoploss at a price of 100, and they submit an order at the indicated block/price:
An order submitted at the indicated block would be unable to be filled using the prices at block range
[2,3]
, and instead would be forced to use[4,5]
block range. This on its own is not an issue, but if the order is combined with a swap whose price impact penalty in[2,3]
is very small, but is very large in[4,5]
, the user will be understandably unhappy about the order execution.Code Snippet
All oracle prices are required to come after the order timestamp, including both the position and the swap prices:
https://github.com/sherlock-audit/2023-02-gmx/blob/main/gmx-synthetics/contracts/order/DecreaseOrderUtils.sol#L134-L156
https://github.com/sherlock-audit/2023-02-gmx/blob/main/gmx-synthetics/contracts/order/IncreaseOrderUtils.sol#L98-L117
The same is true for liquidations and swaps.
Tool used
Manual Review
Recommendation
Allow a price that is separate from the primary and secondary prices, to come before the order block, and allow the primary/secondary prices to equal the order block
The text was updated successfully, but these errors were encountered: