Liquidity Management

Summary

Based on the documentation of GMX:

"When creating a callback contract, the callback contract may need to whitelist the DepositHandler, OrderHandler, or WithdrawalHandler. It should be noted that new versions of these handlers may be deployed as new code is added to the handlers. It is also possible for two handlers to temporarily exist at the same time, e.g., OrderHandler(1), OrderHandler(2). Due to this, the callback contract should be able to whitelist and simultaneously accept callbacks from multiple DepositHandlers, OrderHandlers, and WithdrawalHandlers."

However, in the current implementation of GMXProxy, only a single OrderHandler is whitelisted, as seen in the validCallback modifier:

This restricts the callback contract to accepting calls from only one OrderHandler at a time, which contradicts the GMX documentation and introduces a potential failure scenario when multiple handlers are deployed concurrently.

Vulnerability Details

Issue

The current implementation of validCallback enforces a strict equality check against a single orderHandler instance. This leads to a scenario where, if a new OrderHandler is deployed while the old one is still in use, callbacks from the new handler will not be accepted until an explicit update occurs. This misalignment can cause system failures or interruptions in order processing.

Root Cause

• The contract assumes only one OrderHandler will be active at any given time.

• GMX documentation explicitly states that multiple handlers might exist simultaneously.

• The implementation does not account for dynamically updating and managing multiple handlers.

Impact

The protocol will not function correctly when multiple OrderHandlers exist because only one handler is whitelisted at a time. Any callback from a non-whitelisted OrderHandler will fail, potentially disrupting user orders and leading to operational issues.

Tools Used

Manual review

Recommendations

Modify validCallback to Support Multiple Handlers.