Liquidity Management

Summary

The Perpetual Vault Protocol is designed around a single Keeper responsible for executing all trade actions, managing leveraged positions, and handling liquidations. Unlike traditional multi-Keeper systems, this approach centralises execution authority but relies on trust and transparency rather than decentralised validation.

This presents specific risks related to execution fairness and MEV exploitation, particularly in the following functions:

• GmxProxy.sol::createOrder(): Orders are created without front-running protection, making them susceptible to MEV.

• PerpetualVault.sol::afterOrderExecution(): Orders are executed without on-chain price validation or slippage protection, exposing users to unfair execution.

• GmxProxy.sol::executeLiquidation(): Liquidations do not enforce time delays, allowing the Keeper to selectively execute liquidations for profit.

While the system is designed with a single Keeper, it still requires execution fairness mechanisms to prevent price manipulation, trade reordering, and unfair liquidation execution.

Vulnerability Details

Threat Modelling & Risk Breakdown:

Orders Are Executed Without Price Validation

• Function: PerpetualVault.sol::afterOrderExecution()

• Issue: The function does not validate on-chain prices before executing an order. This means users could get worse execution prices than expected, and Keepers could manipulate pricing.

No Slippage Protection in Order Execution

• Function: PerpetualVault.sol::afterOrderExecution()

• Issue: Since there are no slippage checks, an order can be executed far above or below the expected price with no restrictions.

Liquidations Can Be Selectively Executed for Profit

• Function: GmxProxy.sol::executeLiquidation()

• Issue: The Keeper can intentionally delay or prioritise liquidations to take advantage of market movements, leading to unfair liquidation timing.

Orders Are Created Without Front-Running Protection

• Function: GmxProxy.sol::createOrder()

• Issue: Orders are submitted publicly, making them visible to MEV bots and the Keeper, who could reorder transactions for profit.

Impact

1. Users Can Be Front-Run by Keepers or MEV Bots

   • If an order is detected in the mempool, an attacker can insert their own transaction first, taking advantage of price movements before executing the user’s trade.

2. Unfair Liquidation Risk

   • A Keeper can intentionally delay liquidations to ensure that they are executed at the most profitable moment for them, rather than when it is fair for the user.

3. Orders Can Be Executed at Unfavourable Prices

   • Without on-chain price validation, the Keeper could execute trades at highly unfavourable prices, causing unexpected losses for users.

Tools Used

I might not be using this section wrong (my first competition), but as time is of the essence and since I'm almost at the end of my employed busy season work, I've used OpenAI for the exploration of the above issue to ensure these vulnerabilities are judged/discussed (at least for the potential highs and mediums I've come across).

Recommendations

1. Enforce On-Chain Price Validation Before Execution

• Ensure that orders execute within an acceptable price range before finalising trades:

  function validateExecutionPrice(uint256 marketPrice, uint256 acceptablePrice) internal view {

  require(marketPrice <= acceptablePrice, "Execution price too high");

  }

  • Prevents unfair execution at extreme prices. Although, who sets the acceptable price range, what is an acceptable price range and how should it be determining it? If there are extreme price volatility and the user is in the money, who are to say that they can't execute the trade to profit from it? This comes down to what the protocol market themselves as and users seeking extreme returns should probably go elsewhere and the protocol should inform the users of an acceptable price range.

2. Implement Execution Delays to Prevent MEV Exploits

• Introduce a time-lock mechanism to prevent Keepers from selectively executing trades:

  mapping(bytes32 => uint256) public orderExecutionTime;

  ​

  function scheduleExecution(bytes32 orderId) external onlyKeeper {

  orderExecutionTime[orderId] = block.timestamp + 30 seconds;

  }

  ​

  function executeOrder(bytes32 orderId) external onlyKeeper {

  require(block.timestamp >= orderExecutionTime[orderId], "Execution too soon");

  _processOrder(orderId);

  }

  • Ensures Keepers cannot immediately front-run or delay orders.

3. Introduce a Commit-Reveal Mechanism to Prevent Order Manipulation

• Require Keepers to pre-commit their orders before revealing details:

  mapping(bytes32 => bytes32) public orderCommitments;

  ​

  function commitOrder(bytes32 orderId, bytes32 commitmentHash) external onlyKeeper {

  orderCommitments[orderId] = commitmentHash;

  }

  ​

  function executeOrder(bytes32 orderId, Order memory order) external onlyKeeper {

  require(keccak256(abi.encode(order)) == orderCommitments[orderId], "Order mismatch");

  _processOrder(order);

  }

  • Prevents Keepers from modifying or selectively executing orders.

Mitigation should focus on price validation, execution delays, and commit-reveal order protection.