Liquidity Management

Summary

The cancelOrder function in PerpetualVault.sol allows the designated keeper to cancel pending GMX orders. While the function itself is not directly front-runnable by external users, the centralized keeper role introduces a trust assumption. If the keeper acts maliciously or negligently (e.g., canceling orders after unfavorable price movements), users may suffer losses.

Vulnerability Details

1. Keeper-Centric Control:

   • Only the keeper address (set by the owner) can call cancelOrder.

   • The function checks _gmxLock, which is true only during active GMX operations (e.g., when an order is pending execution).

2. Risk Scenario:

   • Suppose the keeper submits an order to open/close a position at a favorable price. If the market moves unfavorably before the order executes, the keeper can front-run their own transaction (as the sole authorized entity) to cancel the order.

   • Users expecting the order to execute at the original price may face losses if the order is canceled and re-submitted at a worse price.

3. Example:

   • A user expects a long position to open at 1000pertoken.

   • The keeper submits the order but the price drops to 950. The keeper cancels the order and re-submits it at $950, causing the user to enter the position at a worse price.

Impact

Users may incur losses if orders are canceled and re-submitted at unfavorable prices due to market movements.

Tools Used

manual code review

Recommendations

• Add a delay between cancellation requests and execution, allowing users to react.

• Enforce maximum slippage tolerances for users during order submission, making cancellations less impactful.