Liquidity Management

Summary

Whilst the Perpetual Vault Protocol incorporates several mechanisms to address market volatility and potential failures, but significant gaps remain.

Vulnerability Details

1. Off-Chain Leverage Monitoring (Partial Mitigation)

• Mechanism: An off-chain script monitors leverage ratios and triggers adjustments to avoid liquidation.

• Limitation:

  • Relies on external systems; failure or delay in the script could lead to unchecked leverage.

  • No on-chain enforcement, creating a single point of failure.

2. Liquidation Handling (Partial Mitigation)

• Mechanism:

  • afterLiquidationExecution pauses deposits (depositPaused = true) and initiates recovery flows.

  • Liquidated funds are automatically reclaimed and swapped back to collateral.

• Limitation:

  • Only pauses new deposits, not withdrawals or existing positions.

  • No automatic deleveraging during rapid price crashes (e.g., -30% in one block).

3. Collateral Sufficiency Checks (Weak Mitigation)

• Mechanism:

  • willPositionCollateralBeInsufficient (in VaultReader) checks if collateral remains sufficient post-adjustment.

  • _createDecreasePosition enforces collateral safety during position reductions.

• Limitation:

  • Reactive, not preventive. Fails to address cascading liquidations during volatility.

4. Withdrawal Lock Time (Minor Mitigation)

• Mechanism:

  • lockTime (default 1 week) prevents immediate withdrawals after deposits.

• Limitation:

  • Does not protect against protocol insolvency during extreme market moves.

5. Missing Critical Protections

• No Circuit Breaker:

  • Lacks a global pause to halt all operations (trades, withdrawals) during black swan events. GMX might completely fail then where does the customers stand when wanting to withdraw funds? Although rare these type events do happen and mitigations should be in place to avoid this type of collapse and ensure users are protected.

• No Dynamic Fees:

  • Fixed governanceFee cannot be adjusted to discourage risky behaviour during volatility.

• No Automatic Deleveraging:

  • Positions remain exposed until keepers manually intervene, risking undercollateralisation.

Impact

Locked Withdrawals in GMX Failure – If GMX stops updating prices, withdrawals become permanently blocked.

Tools Used

Manual review and checking with OpenAI/DeepSeek re my hunch.

Recommendations

1. Implement On-Chain Circuit Breaker:

   • Add emergency shutdown triggered by oracle price deviations or TVL drops.

2. Dynamic Fee Adjustment:

   • Increase fees during high volatility to deter risky positions.

3. Auto-Liquidation Bot:

   • On-chain bot to force-close positions nearing liquidation thresholds.

4. Real-Time Collateralisation Checks:

   • Reject leveraged trades if global collateralisation falls below a threshold.

5. Emergency Withdraw Mechanism for GMX Failures

   • Implement a failsafe withdrawal function allowing users to exit if GMX stops updating prices:

   function emergencyWithdraw(uint256 depositId) external {

   require(block.timestamp - lastGMXUpdateTime > 6 hours, "GMX still updating");

   MarketPrices memory prices = lastStoredPrices;

   _withdraw(depositId, hex'', prices);

   }

   • Allows users to withdraw at the last known price if GMX is down for an extended period. OR add a back-up price oracle that is used in circumstances like this and to check for/verify any price fluctuations.

The protocol has basic safeguards (price validation, liquidation handling) but lacks robust on-chain mechanisms to handle extreme volatility. A compromised keeper or delayed off-chain monitoring could lead to protocol insolvency. Upgrading to include automated risk mitigation is critical.