Liquidity Management

PerpetualVault.sol

Issue:
The contract uses a global flow variable (with the helper modifier _noneFlow) to gate user actions while a deposit, withdrawal, or signal change “flow” is in progress. If for some reason a flow is not completed (for example, if an external call to the keeper or GMX fails and the keeper does not call a recovery function), then no new deposits or withdrawals can be initiated.

Details:

• The modifier _noneFlow reverts if flow != FLOW.NONE.

• Many key functions (deposit, withdraw, run) call _noneFlow at the start.

• There are functions like cancelFlow that allow the keeper to cancel a flow. However, if the keeper fails to act (or if an unexpected error occurs that prevents the keeper from calling the appropriate recovery function), the vault may remain in a locked state indefinitely.

Impact:
This creates a potential DoS scenario. A stuck flow—whether due to an off-chain keeper misbehavior or an unforeseen error in the GMX callback—could lock out users from depositing or withdrawing funds until an administrative intervention occurs.

Recommendation:
Consider implementing additional timeout logic or administrative “emergency reset” functions (with appropriate safeguards) that allow the protocol to clear a stuck flow. Such mechanisms can reduce the risk of long-term service disruption without opening the door to unauthorized fund access.