Coupling Lunc minting to burn rate

Summary
Re-enable minting Lunc/USTC, but the number of newly minted Lunc should be dependent on the amount of Lunc tokens that have been burned in the last 24h. If the number of existing Lunc tokens is under a predefined threshold, there is no limit of minting new tokens, until the threshold is reached again.

Motivation
The value of UST was that users were always able to convert 1 UST to $1 worth of Luna. Since the price of Luna has dropped immensly, when converting 1 UST to Luna, a huge amount of new Luna tokens has to be minted, which consequently has resulted in the amount of available Luna tokens having exploded. When one of the numerous proposals of introducing a burn rate passes, the amount of available Lunc tokens will slowly decrease. My suggestions is to then enable converting USTC to Lunc under the constraint, that not more Lunc tokens can be minted than have been burned in the last 24h. That way, arbitrage trading of USTC is possible again which will lead to a price increase. When the price has been pegged again, trust will be regained and Lunc can burn faster.
Also, there can be a factor that determines how many Lunc tokens must have been burned before a new one can be minted. For example, when that factor is 2, 2 Lunc tokens have to be burned before 1 new one can be minted. Additionally, when the number of Lunc tokens falls under a threshold, for example 10b, no limit of Lunc token minting will be applied. That means, if there are 5b Lunc tokens in existence and the price of USTC is falling below $1, USTC can be burned quickly. If the number of tokens passes 10b, USTC can still be burned, but slower than Lunc is burned.
The distance between the number of Lunc tokens available and the threshold when minting Lunc tokens will be slowed can be seen as the currency reserve: The lower amount of available Lunc tokens, the less likely a de-pegging is since USTC can be burned without problems.

2 Likes

Indeed! It is necessary to quickly print another 100 trillion tokens! How could we not think of this before?! And then print 100 quadrillions of tokens! Urgent!

1 Like

The idea is to limit the amount of tokens being minted to not be bigger than the burn rate, ie the amount of Lunc tokens will decrease.

1 Like

Coding a blockchain to set max Mint rate based on the current burn rate sounds very difficult (if not impossible to do) in my opinion.

What happens when the threshold is reached? When does it restart? How will it even know the number of tokens being burned at any given moment.

I understand what you’re trying to do, in theory it’s not a bad idea. It’s an overly complex way to handle what could be a much simpler solution.

Would it not be easier to set daily limits, or transaction size limits (adjustable if needed)? Also set up a system to monitor short term limits to prevent an attack. This idea is already in a plan that is up for vote.

Either way before you can even turn this system back on, we need to fix the system first. To do any of this we need a dev team.

https://twitter.com/john_is_whale/status/1534315862215344128?s=21&t=3KYL3JS5h4YxtO_AswAAcg do just like the Orion money validator, I asked your community if you want them to vote yes on proposal 3568 to burn luna. What do you have to lose, you already have luna v2 let us try to save luna v1 everything we ask for. Terra Station

What happens when the threshold is reached?

When the number of Lunc tokens is above the threshold, the minting is limited. When it is below the threshold, it is unlimited.

How will it even know the number of tokens being burned at any given moment.

Given that only one address is used for burning, it is possible to check how many coins have been burned between two points in time. After that it’s simple math: minted_coins = num_of_coins_t1 - num_of_coins_t0 + burned_coins_in_same_timeframe. Ie, if there are 1000 tokens at t0 and 900 at t1 and we know 200 have been burned, then we know 100 must have been minted.

Would it not be easier to set daily limits, or transaction size limits (adjustable if needed)?

Technically of course, but it is less flexible.