If a user become liquidatable, his order will not be filled by the keeper, even though he created the market order when its account was healthy, and the liquidatable stated is the result of a oracle price update that occured in between its order and the keeper transaction.
Liquidation keeper will only be able to act at best during for block N+1
, as they will be aware of the liquidatable state of the account at block N
, risking to put the protocol and the user in a worse state.
To reduce or close a position, users must submit a market order in the opposite direction of the actual position size.
Doing so will reduce their exposure to the asset, and seize them any negative PnL that are due to the protocol.
Zaros has made the decision to prevent liquidatable user from creating market orders if, at the time of the order creation, and before simulating the trade, they are liquidatable.
This decision choice can be discussed, but as far as user are aware of this condition, this is acceptable.
Then, after this, the new simulated position is checked against the margin requirement, which make sense as the first check ensure user wasn't in a unhealthy position, and the second check ensure the position do not become unhealthy after the trade execution.
The issue is that, at the time of creation, the order might pass these conditions.
But once the order is created, it must be executed by market order keepers, which will call SettlementBranch::fillMarketOrder->_fillOrder
, which uses the most recent price
Finally, the account margin will be compared to the maintenance margin, and will revert if it does not validate the requirement.
In case of high volatility scenario or flash crash, the priority should be to cut the loss as soon as possible.
But as the order will not be filled during block N
, liquidation keeper will be able to act at best during for block N+1
, as they will be aware of the liquidatable state of the account at block N
.
If the price of the asset decrease further:
the user will incur higher losses
there is a risk the losses exceed the user margin balance, causing a net loss for the protocol.
In case of high volatility scenarion, the protocol take the risk that position get worser until it is liquidated by keepers, while it could have cut the losses sooner.
The user will also see its losses increase.
Manual review
Allow keeper to execute a trade if it does not make the user's position worser.
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.