Liquidity Management

Details

In the afterOrderCancellation function within the PerpetualVault contract, when a MarketSwap order is cancelled, the contract automatically resets the next action to SWAP_ACTION by executing:

This operation is performed without any validation of the current state or the swap parameters. In particular, the contract does not verify whether the swapProgressData.remaining value is still valid or if the conditions for executing a swap are still met. The absence of such checks can cause the protocol to reattempt a swap even under unfavorable or outdated conditions.

Root Cause

• Lack of State Validation: The function does not verify whether the swap conditions (e.g., valid remaining amount, sufficient token balance, or current market conditions) still hold after an order cancellation.

• Blind Reassignment: The contract blindly resets the next action to SWAP_ACTION based solely on potentially stale swapProgressData, without distinguishing between transient errors and persistent issues.

• Potential Staleness of Data: The reused swapProgressData might no longer reflect current market or contract state, leading to repeated and potentially harmful swap attempts.

Impact

• Repeated Swap Attempts: An attacker or adverse market condition might force repeated cancellations, which in turn cause the contract to continually reattempt swaps.

• Financial Loss: Repeated swap attempts under invalid or unfavorable conditions can lead to significant slippage, executing swaps at poor rates and resulting in a loss of user funds.

• Denial-of-Service (DoS): Excessive and repeated swap retries could consume high amounts of gas, potentially blocking further legitimate operations and stalling the protocol.

• Protocol Stalling: The protocol might become stuck in a loop of swap retries, requiring manual intervention to reset or recover the system.

Recommendation

1. State Validation Before Retry:

   • Introduce checks in afterOrderCancellation to ensure that swapProgressData.remaining is greater than zero and that the current token balances and market conditions are favorable for a swap before resetting the next action.

2. Implement Retry Limits:

   • Add a retry counter to limit the number of swap attempts. If the swap has been retried more than a defined threshold, halt further retries and revert to a safe fallback state.

3. Graceful Fallback Mechanisms:

   • Consider alternative actions when swap conditions are not met, such as reverting to a stable state (e.g., settling the position) or alerting the system administrator.

4. Enhanced Logging:

   • Emit detailed events capturing the state of relevant variables (e.g., swapProgressData.remaining, token balances) during cancellations. This will help in monitoring and diagnosing swap failures.

Proof of Concept

1. Scenario Setup:

   • An attacker (or a faulty external condition) forces the cancellation of a MarketSwap order repeatedly.

2. Triggering the Vulnerability:

   • Each cancellation invokes the afterOrderCancellation function, which unconditionally resets nextAction to SWAP_ACTION using stale swapProgressData.

3. Exploitation Loop:

   • The attacker triggers successive cancellations, forcing the protocol to reattempt the swap under potentially deteriorated market conditions.

   • Due to the lack of validation, the swap is continually retried despite having an invalid or insufficient remaining amount to swap.

4. Resulting Damage:

   • Financial Loss: The repeated swaps execute under poor market conditions, incurring significant slippage and resulting in financial losses for users.

   • Gas Exhaustion/DoS: The repeated retries consume large amounts of gas, potentially preventing legitimate transactions from being processed.

   • Protocol Stalling: The system becomes locked in an endless loop of swap attempts, requiring manual intervention to restore normal operation.

Conclusion

The failure to validate the swap conditions in afterOrderCancellation creates an exploitable scenario where repeated and unchecked swap retries can occur. This poses significant risks in terms of financial loss, gas consumption, and protocol stalling. Implementing the recommended validations, retry limits, and fallback mechanisms will mitigate these risks and enhance the protocol's overall robustness.