Liquidity Management

GmxProxy.sol

Observation:
Within createOrder, the contract calls:

to approve the collateral token for transfer to the GMX router. Some ERC20 tokens require that an existing allowance be zeroed out before a new nonzero allowance is set. Furthermore, the approval is followed immediately by a token transfer via gExchangeRouter.sendTokens.

Validated Issue:
If the token in question follows the “approve–reset–approve” pattern, the above safeApprove call might fail or be susceptible to race conditions (i.e. if an allowance is nonzero, some tokens might be reapproved or even exploited by an attacker if they control the token’s approval flow). In addition, the order creation and subsequent state changes (including the queue assignment) depend on exact amounts. Rounding or approval issues could cause the router to receive an incorrect amount, resulting in an order that does not match the vault’s intended position sizing.

Recommendation:
Before approving, the contract should either (a) ensure that the current allowance is zero or (b) use a safe approval pattern that first resets allowance to zero (if needed). This would align with best practices and reduce the risk of allowance-related errors during order creation.