Liquidity Management

Brief

The PerpetualVault protocol’s token approval mechanism with the GMXProxy contract unintentionally leaves behind non-zero allowances after failed or canceled swaps. Because SafeERC20 prevents changing a non-zero allowance to another non-zero value, a leftover allowance blocks all new approval attempts for the same token-spender pair, leading to a permanent DoS for future swap operations.

Details

The core issue comes from how the protocol handles token approvals on retries when a swap fails or is canceled. Specifically, the GmxProxy contract calls safeApprove without resetting any previously granted allowance. Below is a simplified code excerpt from GmxProxy.createOrder illustrating this:

When a MarketSwap order is canceled, no mechanism exists to revert this non-zero approval back to zero. The SafeERC20 library enforces a rule disallowing safeApprove(...) from a non-zero to another non-zero amount, so these lingering approvals block future attempts to re-approve the same token. The afterOrderCancellation path in GmxProxy and PerpetualVault likewise never resets the leftover allowance:

Because the protocol always calls safeApprove(...) again on every retry, the remaining non-zero allowance triggers SafeERC20’s revert condition, causing further swaps for that token pair to fail irreversibly unless manual intervention zeroes out the approval.

Specific Impact

This flaw introduces a permanent DoS on swap operations for any token pair that experiences a failed or canceled swap with a leftover non-zero allowance, preventing all subsequent trading for affected tokens and requiring manual fixes to restore normal functionality.