Liquidity Management

Summary

During the afterOrderExecution function, if the executed order is not a MarketSwap, the logic attempts to claim funding fees. However, if this call reverts (e.g., due to feature disabling or other reasons), the protocol will be unable to claim these fees. This could result in fees being permanently stuck. To mitigate this, consider adding a separate function that can be invoked at any time to claim funding fees.

Vulnerability Details

The afterOrderExecution function attempts to claim funding fees for non-swap orders. However, the call to claimFundingFees is wrapped in a try-catch block, which means that if the call fails, the function will emit an error event but will not retry or provide an alternative mechanism to claim the fees. This can lead to the following scenario:

1. The last order for a position is executed, but the claimFundingFees call fails due to a temporary issue (e.g., feature disabling or other external factors).

2. As a result, the funding fees associated with the position remain unclaimed and are effectively stuck in the protocol.

Impact

• Loss of Funds: Funding fees that cannot be claimed due to a failed call will remain unclaimed, leading to a loss of revenue for the protocol or its users.

• Lack of Recovery Mechanism: There is no way to retry claiming the fees after the initial failure, making the funds permanently inaccessible.

Tools Used

Manual code review.

Recommendations

Introduce a new function that allows owner to claim funding fees for a specific market or position. This function should be callable independently of the afterOrderExecution logic.