Luna Death Spiral Bugfix Proposal

The US dollar used to be backed by gold because gold is a resilient asset. Gold does not devaluate easily. Luna, on the other hand, became a weak asset because there is no limit for its dillution.

When a currency is backed by a weak asset, it has the systemic risk of being devalued along with its backing. This proposal aim at fixing this, by preventing the death spiral from ever happening again to Luna.

The death spiral is when the algorithm drives the price down without ever letting it go back up. In other words, it locks the price trajectory in a single direction. To fix this, we must ensure that the price is allowed to reverse its course. And there is a way to do this.

Luna’s death spiral taught us that when UST depegs by a substantial amount, Luna’s price falls much faster than the UST price because there aren’t enough buyers for the amount of Luna that needs to be minted in order to restore the UST peg. So, we must limit the minting of new Luna to prevent a price crash, but we must limit it in a way that still allows for UST to recover its peg.

The way to do this is by taking the speed of the price movement in consideration. To ensure that Luna is a strong asset, its price must not fall faster than the price of UST.

Let’s say that the price of UST is falling 10%, and the price of Luna is falling 5%. The amount of new Luna minted must not surpass the minimum amount that would make the fall of Luna’s price surpass the fall of UST price.

In this case, let’s say that enough Luna is minted to reduce the fall of UST to 7.5%, while increasing the fall of Luna to 7.5%. At this point, no new Luna should be minted.

Afterwards, if the price of UST keeps recovering while the price of Luna stays at the 7.5% loss, nothing else should be done until UST fully recovers its peg. Luna holders will have to wait until UST become overvalued (above $1) for Luna to be burned.

The core of the idea is that while the interaction between UST and Luna is a closed system, the interactions between UST & USD and Luna & USD are an open system that can’t be fully controlled by the algorithm. It’s inevitable that the US Dollar price of both UST and Luna can fall at the same time. So, what the algorithm can do is to direct the flow of USD between UST and Luna to make UST as stable as possible (which doesn’t mean 100% stable) while never unbalancing the value of Luna.

The more resilient Luna becomes, the better it can back UST. This proposal ensures that Luna will never be weaker than UST on the way down, while UST will always have a stronger price recovery.


Agree that minting has to be capped in some way. I’ve written a go-forward proposal for updating the Oracle to report a Terra Solvency Rating, if TSR is 100 then minting is allowed, when too many exit at once solvency is downgraded and minting $LUNA / $UST is blocked/limited: [Proposal] A Better Way Forward™ = TFL pays back $UST by burning excesses, NO FORK

1 Like

If people know a trillion is going to be minted tomorrow the price will crash today

do you really want it stable? back it with real gold, tomorrow morning get up early and mine it.

I believe Terra has very good technical tools already built, and I like the idea on this post.

Consider that perhaps implementing some type of “speed supervision” might require this being on the off-chain side of oracles, since as you mention, LUNA-UST is a closed system while it is in the blockchain, but not when markets are speculating or driving the price some other way outside of it.

In regards to “what to do” going forward, I think it makes sense to expect a plan on how to try to fix the issues that caused all this mess in the first place, as importantly as what to do right now in the current situation of course. What can be changed in the design to avoid these type of issues (or at least, try to minimize it as much as possible), considering something similar could happen again in the future?

Here are some ideas from my part (Disclaimer: I am by no means an expert on this or anything)

Having some kind of rate limiting over sudden fluctuations of collateral (in the protocol itself), for example there are already some measures:

  • When staking Luna there is an unbonding period. Why not also have this mechanism dependent on the amount of collateral when wanting to move in/out of the UST/LUNA liquidity, such that big movements have at least some resistance. Considering that it is difficult to have on-chain data analysis with enough performance, maybe some way of limiting the percentage of funds to move in general, based on block count or who knows (of course, I am not qualified to say whether this is a good solution or not).

  • Anchor APY (or anything that “promises” stability) to decrease based upon detection of these sudden movements (based on computations, so it acts quickly without human intervention). If there is an overwhealming amount of deposits (of course, how to determine this?) maybe there is the need for variable APY per wallet to apply - the bigger the deposited amount a wallet has, the lower the APY it receives. I understand a huge deposit could be split into many tiny ones to overcome this and make this less useful, but maybe there could be a cost for this in some sense, or a limiting in the rate of deposit admissions/block to these protocols to try to make it work to a certain extent).

  • Could “sharding” be a good thing to consider?. Of course, this would mean that there are in reality multiple similar runtime networks “isolated” from each other except for having bridges between them that have this “rate limiting” controls (perhaps you transfer from shard A to B, but need to wait some time (i.e. some number of blocks) before you can use them at the other side depending on the amount you wish to transfer AND the amount transferred per unit time based on shard TLV).

Incentives could exist for participants to keep the shards more evenly distributed. Again, these are just basic measures (and I can see ways around them already), but at least this gives some friction to when the network is intended to be abused.

In short, I believe any sort of mechanism that makes it increasingly harder for big movements of capital to occur very quickly (by design) could help bring more stability (at the cost of flexibility, yes, but perhaps these systems need to move a little bit more towards safety while they still grow, since market panic is a real thing as we’ve seen, so one thing that can help with it is to have mechanisms that try to mitigate this by design - and… they need to be clearly stated and talked about, such that expected market participant behaviors are at least documented in this situations.

Of course, having the system in isolation to understand “what value is really managing” probably is not possible without oracles or some sort of input from the outside world, thus, some of these parameters would require to be passed through governance, but the parameters themselves could have general risk thresholds that could tie with the voting quorum or something (to try to couple this responsibility with the difficulty of governance attacks).

Anyway, just some ideas that perhaps are being considered, but all in all, a response in this front would be something I would expect from the guardians of such a system.


Proposal to remove the mint function

their should be a fair exit mechanism in place, as a distributed solution to bank runs to prevent arbitrageurs from taking advantage of bank run:

I’d like to propose the following

We peg UST to 10c and once that peg is held we increase it 5 cents every 2 weeks.

We CAP the amount of LunaC that can be minted every day to 25% of the 7 day moving average binance/kucoin volume. This ensures that our minting sell pressure won’t cause an issue.

Everyday RANDOM Luna stakers are selected to perform ARB activities. This let’s ALL wallets participate.

Let’s go!!!


We would like you to join our discord to collaborate with like minded people to save USTC & LUNC

Your input would be appreciated.