SIMP-2: Advanced Liquidations queuing

One of our top priorities in the Mirror Steering Committee is to ensure that there is adequate and measurable liquidation depth, so that asset collateral ratios can be lowered without endangering the protocol.

To this end, we put together a proposed workflow. After capturing feedback from the community, we will establish technical specifications and announce a formal bounty.

We can effectively model after Kujira (and I’m hopeful that they will claim our development bounty so we can fully leverage their expertise), but there are some design decisions that will need to be made…


  • Loans are all denominated in UST
  • Collateral is in bETH and bLUNA

Kujira output:

  • Users deposit UST, specify discount %
  • When liquidation threshold is breached, UST repays loan and captures collateral at specified discount
  • Liquidation events waterfall through discount levels until all liquidations completed (or available UST is drained)


  • Loans are denominated in mASSETS (at oracle prices)
  • Collateral is in UST, mASSETS, aUST, LUNAx, etc.

Simple schema output:

  • Users deposit mAssets, specify discount %
  • When MCR is breached, mASSETS repay loan and capture collateral at specified discount
  • Liquidation events waterfall, etc.


  • shallow depth for each mASSET because liquidation fund spread across multiple mASSET types
  • users receive much broader range of collateral during liquidations; some mASSETS collateral may trade at liquidation/premium to market
  • mASSETS received in liquidations that remain are not removed by USER can in turn be used for liquidations of that mASSET type?

Complex schema output:

  • Users deposit aUST, specify discount %
  • When MCR is breached, aUST swapped for mASSET, mASSET repays loan and captures collateral at specified discount
  • captured collateral is swapped to aUST and stands ready for next liquidation event.


  • since collateral is swapped back to aUST, it can be used for the next liquidation, so pool needs enough depth for individual events but can be reused for separate events
  • when liquidation pool has insufficient depth at specified discount to fully liquidate a position, the position is ‘remedied’ by partial liquidation instead of full liquidation
  • partial remedy improves MCR of loan… it’s possible that continual reuse (looping) of lowest discount% pool means that deeper % pools are NEVER used
  • additional swap costs mean that for specified %, liquidator receives lower % than penalty paid by defaulting loan

Blended schema:

  • simple schema tiered with specified % levels like kujira, loans remedied with mASSET liquidation vaults until their liquidity is tapped out
  • complex schema backstops single schema vaults at 20% penalty
  • mASSETS received as collateral can be used for liquidations of that mASSET type
  • aUST received as collateral goes into backstop pool
  • UST or LUNAx received as collateral… available for unlock but not utilized in any way? or swapped for aUST and injected into backstop pool?


  • users willing to stake mASSETS get first shot at liquidations, as their liquidations are more cost efficient
  • unified aUST pool backstops mASSET liquidation pools, so enough depth is available to meet all liquidation events
  • aUST earned from simple schema liquidations is injected into aUST pool on behalf of user, deepening liquidity in the event of a liquidation cascade

Simplified version modeled after kujira has the lowest smart contract risk, but is unlikely to have enough depth to meet liquidation requirements in extreme events.

Blended schema results in the best overall user experience (allowing specified discount levels when mASSETS staked, but backstops with enough generic liquidity to protect Mirror and ensure that liquidation events are always sufficiently covered), but at the cost of additional complexity, swap costs, and smart contract risk.

In either schema, existing liquidation bots could update their parameters and front-run the liquidation pools; this decreases the performance of the liquidation pools- changing this would substantially increase the contract risks, but it means there is always unmeasurable ‘shadow’ liquidity, and dampened performance of liquidity pools may reduce their depth.

Using aUST as base asset for backstop pool helps ensure that adequate liquidity is available, since even a few liquidations improves the yield of aUST and makes the pool extremely attractive to single asset stakers. (anchor yields + mirror yields = OMG how can you not!!)

(Note that Kujira is releasing a v2 for their Anchor liquidation module soon that will be much closer to our needs, and our final workflow may be more iterative of their v2, but we did not want to table community discussion on this topic until after their release.)


Hi @josephsavage we’re Lighthouse Defi, another liquidator in the space, we’d be more than happy to help collaborate here. Any way to connect?

1 Like

Best option is to reach out on the Mirror Discord server.

1 Like

Hop on the Discord! We’ll be more than happy to have a chat.


I like this one. For sure don’t want to over complicate things, but seems like a good place to park aUST.

It says

Server is currently under lockdown. Verification is closed. Please try again later.

I can’t join the server