improving liquidation (2 suggestions)

[0xbigz]

Liquidations on Drift involve assuming control of asset/liability pairs based on premium/discount compared to the oracle, without consideration for market price. Despite attempts to stagger liquidations across a brief interval per account, the process operates on a first-come, first-served basis.

Two potential enhancements are identified:

1. Refining liquidator_fee

A fixed liquidator_fee proves inadequate in scenarios of supply/demand mismatch:

• If set too low, insufficient incentive for liquidation may disrupt insurance.
• If set too high, excessive Miner Extractable Value (MEV) or spam could result, potentially overcharging users or the protocol.

Proposing a dynamic fee based on the following factors:

• Market/oracle standard deviation
• Distance from zero-price (bankruptcy threshold)
• Time since the first liquidation attempt/margin shortage

The parameter for liquidation fee could specify a clamp (minimum and maximum) for this dynamic fee.

2. Implementing an Open Liquidation Order System

Opening liquidation orders on user accounts and relying on a competitive fill system:

• Liquidation orders triggered by a keeper for a minimal viable fee (akin to trigger orders).
• Market competition to fulfill (with the vAMM also potentially acting as a counter-party).

Both options aim to protect protocol users from excessive fees and enhance the security of Drift.

Open call for additional factors to consider.

[ricardojmendez]

Hey @0xbigz,

This part isn't entirely clear:

Liquidation orders triggered by a keeper for a minimal viable fee (akin to trigger orders).

Market competition to fulfill (with the vAMM also potentially acting as a counter-party).

What's meant to happen in that case?

Does the keeper merely trigger placing the orders to sell the collateral and de-risk the perp on the respective order books, at a discount (likely crossing over price)?

[0xbigz]

For suggestion 2, was thinking keeper just triggers placing mildly aggressive crossing orders. fee would likely be higher than trigger order even its relatively importance but since theres no inventory/risk could be lower than base liq fee

[ricardojmendez]

Wouldn't a keeper bot placing perp orders that way mostly act as a feeder into the VAMM?

I'm also having a hard time modeling how well suggestion 2 would work for spot collateral, though. From personal (but admittedly purely anecdotal) experience, it's usually easier to liquidate collateral via swapping on Jupiter than through Drift spot trades. If it relies on Drift limit trades, it seems that you might potentially need to incentivize more than one order-placing keeper, since a spot sell order may not be taken up while collateral value decays (or maybe you let a second one try again after the order expires). That would still put the protocol at risk of bad debt.

Another option would be letting said keeper execute a Jupiter trade right away, with contract implementing the swap sending the funds back to the liquidated account to cover their debt. I'm not entirely sure how that would work with the internal margin controls, though, since it effectively means collateral for an already overstretched account is temporarily leaving Drift.

[ricardojmendez]

Regarding the "potentially decaying collateral" issue with suggestion 2: would it be possible to implement a variant that, instead of just triggering, actually does an atomic "trigger place and take"?

That would solve both issues:

• The position is transferred to someone else the moment it's triggered;
• People writing liquidator bots are still incentivized to come up with a creative logic that lets them get at liquidations quickly (or just throw hardware at the problem), given that finding potentially liquidateable users is a comparatively heavy process.

@0xbigz

[ricardojmendez]

Having through about this some more, I'm inclined to prefer option 1 - this might be habit and familiarity, but I think an approach where an individual takes over the debt right away is preferable overall, as it can lead to a variety of approaches and risk management strategies.

Beside oracle/market standard deviation, I'd also consider some EMA of the oracle's update rate. Some markets have much flakier oracles, and the fact someone may be unable to place a derisk order because of an Invalid Oracle price error should be factored in - otherwise those markets are less likely to attract liquidators.

Given this fee will be dynamic, it would be ideal canBeLiquidated returned not true/false, but 0 if not liquidateable, and a percentage if it can - that way liquidators can configure a minimum fee threshold of their own to do business in a market.

[0xbigz]

Quick update here, a hybrid of both suggestions above has been written / in the works:

completed:

1. ability to derisk a liquidatee versus another open order user or the market's AMM, w/o speedbump has been completed here: program: add liquidation via fill #1106. viewable in changelog as well

in progress:
2. dynamic fee (essentially a slow auction) on liquidator fee is in progress here: #1185

any example client using these are in progress for release

@ricardojmendez would appreciate your feedback