Liquidity Management

Summary

The protocol cannot support having two handlers of the same type at the same time, which prevents the GmxProxy::afterOrderExecution function from executing, leading to a severe disruption of the protocol's functionality.

Vulnerability Details

According to the integration notes of the README of GMX contracts:

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

The protocol's code supports only one instance each of orderHandler, liquidationHandler, and adlHandler. However, if there are two handlers of the same type, one of them cannot be registered to support the callbacks. As a result, with two orderHandlers, the GmxProxy.sol::afterOrderExecution and PerpetualVault.sol::afterOrderExecution functions cannot be executed sometimes, which disrupts the core contract functionality.

Impact

• Breaks at some level the functionality of the contract

Root Cause

• Not supporting two handler instances of the same type at the same time(e.g. OrderHandler(1), OrderHandler(2)).

Tools Used

Manual Review

Recommendations

Add a second instance of each type of handlers.