Liquidity Management

The GmxProxy contract incorrectly tracks only a single active order using the queue struct, which contains requestKey (identifying the order) and isSettle (indicating settlement status). When multiple orders are created in quick succession, each new order overwrites the previous queue.requestKey, leading to incorrect execution tracking. Specifically, if a vault submits an order via createOrder() and then submits a settle() order before the first order executes, the first order's key is lost because queue.requestKey = requestKey; is overwritten in both functions. Later, when afterOrderExecution() is triggered by GMX for the first order, the contract references the *wrong order key, potentially misallocating funds or failing to execute settlements correctly. The bug stems from using a single-slot storage variable instead of handling multiple simultaneous orders, as seen in this flawed implementation:

When GMX calls afterOrderExecution(), the contract processes the wrong requestKey, leading to incorrect fund transfers or failed liquidation tracking.

impact:

Loss of funds or incorrect execution tracking due to overwritten order keys, leading to misallocated settlement funds and potential vault liquidation failures.

Mitigation:

Use a mapping (mapping(bytes32 => OrderQueue)) to track multiple active orders instead of a single struct, ensuring each order is handled individually and safely deleted upon execution.