After a liquidation event, the protocol’s afterLiquidationExecution() function sets depositPaused = true and does not automatically reset it. Although the owner can later unpause deposits via setDepositPaused(), this creates a temporary DoS condition for deposits during market extremes. Such conditions are precisely when new deposits could help capture market opportunities, leaving users reliant on owner intervention to resume deposits.
After gmx makes a liquidation then protocol’s afterLiquidationExecution() function sets depositPaused = true but never sets it to false(not in any next actions too).
In extreme market conditions, liquidations may be frequent. While pausing deposits might be a safety mechanism, it inadvertently creates a state where, after liquidation, new deposits are blocked until the owner intervenes manually. This not only delays the ability to capitalize on market recoveries but also increases centralization risk, as it forces users to depend on the owner’s availability.
Temporary DOS of deposits.
Centralization: Users lose autonomy as deposit resumption relies solely on the owner's action.
Opportunity Loss: In volatile market conditions, delays in unpausing deposits could result in significant profit opportunities being missed.
Manual Review
Add depositPaused to false in next actions.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.