The afterOrderFrozen callback function in GmxProxy contract is completely empty despite being a critical part of the order lifecycle. When orders become frozen on GMX protocol, the system fails to handle these cases, leading to stuck orders and system lockup.
The afterOrderFrozen function is empty with no implementation and no handling of state changes on the queue.
When an order becomes a frozen state the order in the queue remains active without any update to the requestKey and no cleanup to the queue.
The validCallback modifier only validates the caller and account but does not validate the order status in the queue and does not check whether the order has been previously frozen.
This can cause frozen orders to still appear active and DOS the system when the order is frozen on the GMX protocol.
Frozen orders will still appear active
DOS
Manual review
Clear queue if order is current order.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.