Thank you, very helpful to locate the two relevant code scripts. Seems like the logic has not bene updated since October 2021 so that’s good. Some of the logic is clear but some is a bit tricky to check, and to trace how LiquidatedCollateral can end up > 50% of collateral.
But it would be easiest to discuss with the contributors and especially when they carried out unit testing for the code, the cases where liquidated collateral is excessively large.
the purpose of that paper is to properly attribute liquidation gains to pool bidders in a gas efficient manner; it is a clever way to solve a tricky problem, but i do not think it is in-scope for your core question.
Yes, totally correct, looking through the paper in a bit more detail.
Actually I found the query_liquidation_amount definition of code that directly addresses the issue:
(starting at line 34):
/// The amount of collateral to be liquidated depends on the status of the bid pools
/// for each collateral. To find out how much collateral should be liquidated
/// we find the intersaction between f(x) and g(x); where x = liquidated collateral,
/// f(x) determines liquidation amount at which the safe ratio is satisfied, and g(x) gives
/// the repay amount based on the collateral being liquidated, which takes into account the
/// available bids at different premium rates
and further down
/// The portion of collateral that liquidated from the available set is calculated
/// based on weight = min(collateral_value, available_bids) / max_ltv
I’ll review this code and see how far I get with the abstraction to arrive that the liquidated collateral is > 50% of total original collateral.
Apologies if you’ve dug deeper than this but I’d suggest joining the Kujira telegram and asking some of them how it works. They do most of the liquidations now. As other have said, it’s a bidding process which Kujira has kept typically <5% premiums (almost impossible to hit 10%+ now). I’d think they could detail how/if the contract let’s more than “enough” be liquidated.
Would love to have that discussion, on Twitter or in any other format that works. I also like the recommendation to reach out to Kujira folks about this, thanks @Generic@jc69
@paletas@jc69 Some folks looked at the transaction closer and speculate that the liquidation queue
“has miscalculated the amount of collateral it’s telling the custody contract to send for liquidation”. From looking at the code @paletas linked, the weight parameter that determine the liquidation amount is compounded in a loop, so somehow that loop ended up getting to 52% of the total collateral, but no clarity if it could theoretically go to 100% collateral liquidation.
A renewed discussion on Twitter got the the point I was missing: the liquidation aims to reduce not the LTV or usage % but the risk ratio, which is a slightly different calculation.
Credit to
@AgilePatryk for getting this all cleared up for myself and the community.
Quoting his tweet (see link below):
maxLTV for bLUNA is 80% - this is when risk ration happens.
currentLTV / maxLTV = risk ratio (RR). Liquidation at RR=100%.
Anchor liquidates you all the way to “safe RR” = 80%. Equivalent of LTV = 80% * 80% = 64%.
Account for the fees (average 4-5%): ~50% collateral is gone.
So two big conclusions: 1) with the increased bLUNA usage to 80% of collateral, the liquidation to 80% risk ratio basically will sell 50% of your collateral. 2) The liquidation algorithm works as it is supposed to, without any weird outliers or anomalies.
Bump for how effed predatory Anchor is though needs borrowers to function Having bLUNA allowed as is, is extra brutal. LUNA price f
goes down, bLUNA tanks, UST always valued as 1$ on chain while bLUNA collateral does not get that benefit = bLUNA riskiest asset on Anchor This is all before taking into account it’ll accept bids for way more than liquidations ltv, theoretically a “partial bid” can take all collateral depending on bidder buying parameters.
