MultiLiquidate transaction.

[AgentSmithMatrix]

It is possible, depending on how the multi liquidation transaction is defined that it can become more profitable to run it on every block with all the positions (paying the fees) and eventually some liquidations will happen than to have an ultra optimized algorithm.

I open this in order to discuss the fairness of this approach and posible problems.

[matthiasmatt]

We talked a couple month ago about limiting liquidation to the protocol only. The reasoning was to give more source of funds to the EF, and also prevents the behaviors from solana happening on our chain:

Solana: ...liquidators and borrowers raced to send their transactions through as SOL crashed.

[testinginprod]

I am against whitelisted liquidators for two reasons:

• philosophical: are we decentralized?
• what is the criteria for a liquidator to be included?
• what happens if whitelisted liquidators are targeted and they go down? who provides the redundancy? The platform can go into bad-debt quite quickly.

Solana: ...liquidators and borrowers raced to send their transactions through as SOL crashed.

This does not justify limiting what actions can be performed on the chain, the chain must not have downtimes no matter the operation being performed on it.

[matthiasmatt]

• philosophical: are we decentralized?
  If the funds goes to the perp EF we are still decentralized. This money goes to the funding rate payments and bad debt clearing.

• what is the criteria for a liquidator to be included?
  Only the protocol would be allowed to liquidate

• what happens if whitelisted liquidators are targeted and they go down? who provides the redundancy? The platform can go into bad-debt quite quickly.
  We can have redunduncy built in our own service for that.

[matthiasmatt]

in particular, if you burn extra nibi from the perp EF you can actually benefit all nibi holders

[testinginprod]

It is possible, depending on how the multi liquidation transaction is defined that it can become more profitable to run it on every block with all the positions (paying the fees) and eventually some liquidations will happen than to have an ultra optimized algorithm.

I think the ante handler which consumes gas based on TX size makes this unprofitable long term.

I run a test scenario, sending 1_000 liqs in a single tx, produced a tx with size: 59319bytes.

Counting auth's default params.TxSizeCostPerByte is 10:
Then the gas consumed (only for the TX size) is 593_190.

I think attempting to always liquidate every position, every block, will become unprofitable quite fast (depending on our tx fees).

If we deem this to still be a problem I would not add a penalty fee for failing liquidations as liquidations are a race by default and I would not want to be punished because someone's liquidation got included before mine when I am behaving fairly.

We could instead introduce a parameter (or keep it as a constant) which limits the amount of liquidations that can be done in a single TX [it needs to be done at TX level and not Msg level as I could send multiple msg multi liq txs, possibly solvable through an ante handler].

[matthiasmatt]

I think looking at liquidating all positions on every block is a bit much. You can just liquidate all positions below 10% margin ratio, or 8%, or 7.5% etc.

The reward for liquidating big positions is very high compared to the cost of the transaction. If there's a position with a notional of 50k usd about to be liquidated, i'm willing to pay 20k usd in fees if i have 50% change of liquidating it.