Liquidity Management

GmxProxy.sol

Observation:
GmxProxy uses a single global variable, queue (of type OrderQueue), to store the request key and settlement flag for the active order. In both the createOrder and settle functions the new order’s request key is written into queue.requestKey, and later the callbacks (in afterOrderExecution and afterOrderCancellation) simply “delete queue” to clear it.

Issue Path:
This design assumes that only one order will be active at any given time. If the associated PerpetualVault (or an attacker who can manipulate vault calls) triggers multiple orders concurrently or before the previous order’s callback completes, the global queue can be overwritten. This leads to mismatches in callbacks—meaning the vault might process the wrong order’s results, misallocate funding fee claims, or even lose track of pending orders. Such behavior directly violates the protocol’s assumption of sequential, isolated order processing and can disrupt accurate share and fee accounting.

Recommendation:
Either redesign the proxy so that it supports multiple outstanding orders (for example, by using a mapping or an array keyed by requestKey) or ensure that the vault strictly enforces sequential order submissions so that a new order cannot be initiated until the previous one’s callback has been fully processed.