Repeg Idea: Flexible Delegation to reduce USTC supply

Proposed by Tamashi ( @tamashi_papa )

Background of the LUNA Crash

LUNA lost most of its value in May of last year after growing rapidly due to its algorithm with stablecoin UST. This incident started when a large amount of UST was minted by the mint/burn swap that was used at the time, and the $1 peg came off.

A large amount of LUNA and UST was minted by the algorithm to re-peg the UST. UST had LUNA as a collateral.

The downside of this algorithm is that the more UST deviates from $1, the more mint it will need, and the more the LUNA price drops, the more mint it will need. The inexhaustible mints were a major factor in diluting the value of UST and LUNA, and the negative chain reaction of requiring more mints caused the crash.

This is the big crash of LUNA due to hyperinflation.

Value of UST and LUNA

Although there was a big crash due to hyperinflation, the structure of stable coins that doesn’t use legal currency as a collateral is epoch-making and will definitely be necessary in the future.

When UST exceeds $1, the mint/burn swap burns LUNA and the value of LUNA continues to rise significantly (before the crash) was also an epoch-making investment target.

This means that the higher the demand for UST, the higher the value of LUNA. In fact, the value of LUNA continued to rise. In other words, if you replace it with the present, it means that the greater the demand for USTC, the higher the value of LUNC.If USTC hyperinflation does not occur and demand continues to rise and UTSC can re-peg to $1, then anyone can imagine that the value of LUNC will rise significantly after that.

Negative chains and mint

“The lower the value, the more mint is required, and the more minted, the lower the value.” If there is no hyperinflation caused by this negative chain, mint is not scary. Rather, mint is essential to bring profits to investors.

It is not important to be mint zero. It is important that mint (hyperinflation) does not occur due to a negative chain.

conditions for suitable algorithms

・No hyperinflation
・No mint when the LUNC price decrease is large

If we can keep these two conditions, a proper mint is essential and not scary. Considering how much the value of LUNC will rise after the USTC peg returns, it is easy to imagine that not denying the “appropriate mint” would more benefit holders.

Therefore, I suggest a repeg proposal that does not require hyperinflation and token funding, and is shown below.

Overview of Flexible Delegation (FD)

In staking, You can get rewards with delegating LUNC to validators. In FD, we can get a reward by delegating to validators using an algorithm that swaps USTC to LUNC at the time of delegation. This proposal is an algorithm that can be realized by using mint/burn swap. Users who use FD will get a high benefit by using it at the same time as existing staking.

Advantages of FDs

User Benefits: This FD can be delegated or undelegated at any time. There is no locking when undelegating. Rewards can be received according to the amount delegation in the same way as staking. No need for token funding.
Chain Benefits: Increased on-chain volume. Demand for USTC increases. USTC supply will definitely decrease. There is no hyperinflation.

Disadvantages of FDs

“USTC opportunity loss” and “LUNC mints” may occur due to USTC/LUNC price fluctuations. However, all minted LUNC are sent to the Oracle (Stakking) Reward Pool.

Maximum number of LUNCs that can be delegated by FD

If staking is 100 LUNC, delegation by FD is also up to 100 LUNC equivalent.


By setting the total amount of staking as the upper limit of FD, it can be expected that the more the demand for FD increases, the more the staking rate rises as well.

FD operability

FD can be delegated with the same operation as staking LUNC.
The difference with staking is the cap on delegations and that USTC is required.

Required amount of USTC

If you want to delegate 100 LUNC on FD, you need USTC equivalent to 100 LUNC. FD does not require LUNC.

About delegation processing

Users delegate in the same way as staking, but minted dedicated tokens are delegated in the actual process.
The “flexible delegation” and “reduce USTC supply” algorithms are realized by using two dedicated tokens describes below.

FD dedicated token 1 (ncLUNC)
ncLUNC (non-circulating LUNC)

USTC is swapped to ncLUNC and then delegated. It has the same value as LUNC and is minted in a mint/burn swap with USTC. An FD-only token that never circulates.

FD dedicated token 2 (ncUSTC)
ncUSTC (non-circulating USTC)

An FD-only token that will be minted as a reference to reduce USTC supply. mint at the same time as delegation. It does not circulate and is not used for swapping. It functions as a ledger.

Specific usage examples of ncLUNC and ncUSTC are described later.
“ncLUNC and ncUSTC” Use these two to implement an algorithm that reduces the supply of USTC.

Once again, ncLUNC and ncUSTC are FD-only tokens that will be minted at the time of delegation, but neither will be circulated.

UI when delegating

Flow when ncLUNC is delegated

1 mint/burn swap of USTC(burn)→ncLUNC(mint)
2ncLUNC → validator (delegate)
Such processing is performed. This is illustrated graphically below.

・When a user consumes USTC and delegates to a validator

The flow is like this image. User consumes USTC to delegate ncLUNC. At this time, USTC is being burned, so you can see that the supply of USTC is temporarily decreasing.

・When the user undelegates

In this way, the USTC is returned to the user by performing the reverse procedure of delegation.

Swapped ncLUNC price

In 1, mint/burn swap from USTC to ncLUNC is performed. At this time, ncLUNC is always treated(wraped) as the same as LUNC Price(value).

If the price of LUNC is $0.00015, ncLUNC is also calculated as $0.00015.

USTC burns when delegating

Suppose you delegate 20000 ncLUNC when ncLUNC is $0.00015. $0.00015 × 20000 = $3

If the value of the ncLUNC to delegate is $3, you can delegate by spending $3 worth of USTC. When the USTC price is $0.03, $3 equivalent is “$3 / $0.03 = 100 USTC”.


100 USTC will be burned instantly and 20000 ncLUNC will be minted and delegated at the same time as delegation as shown in the above figure. The important thing here is that 100 USTC was burned.

Mechanism to continuously reduce USTC supply

Suppose the USTC price ($0.03 at the time of delegation) becomes $0.06 (doubled) after delegation.

Currently, users have delegated $3 worth of ncLUNC, and the USTC price is double the delegation to $0.06. If the user undelegates in this condition, 50 USTC will be returned as shown in the figure below.


It can be seen that the amount of USTC has decreased from 100 USTC to 50 USTC compared to before delegation. In FDs, value fluctuations depend on LUNC, so if the price of USTC rise while the price of LUNC stays the same, the supply of returned USTC will decrease.

If a user delegates $3 worth of ncLUNC, USTC remains at $0.03, and the price of LUNC halves to $0.000075, the amount of USTC will also decrease from 100 USTC to 50 USTC, as shown in the chart below.


At this time as well, USTC supply is lower than before the delegation.

This means that if USTC/LUNC rises before and after delegation, USTC supply will decrease.

Graph of when we delegate and after (when USTC/LUNC goes up and USTC supply goes down)

when delegate


when undelegate


Since USTC/LUNC increased before and after delegation, we can see that it decreased from 100 USTC to 50 USTC.

What to do when USTC/LUNC decreases and USTC supply


Compared before and after delegation, USTC supply decreases when USTC/LUNC rises. Then, when USTC/LUNC falls, USTC supply should increase as shown in the chart below.

when delegate


when undelegate


Looking at the image above, it increased from 100 USTC to 200 USTC before and after delegation. preventive measures Measures must be taken not to increase the supply of USTC.
This is where ncUSTC (non circulating USTC) comes into play.


ncUSTC is minted upon delegation.ncUSTC is minted by the same amount as USTC (if 100 USTC is burned, 100 ncUSTC is minted)
This ncUSTC becomes the maximum value of USTC mint at the time of undelegation.

ncUSTC when USTC/LUNC falls

If the value of the ncLUNC to undelegate is “greater than 100 USTC burned”


The mint amount of USTC at undelegation cannot exceed the amount of ncUSTC. If undelegation occurs that exceeds the USTC amount at delegation, mint the LUNC instead. This will be a measure to prevent an increase in USTC supply. In this case, 100USTC will be returned to the user and 10000LUNC will be sent to the Oracle Reward Pool.

If the value of the ncLUNC to be undelegated “doesn’t exceed the burned USTC”

In the above figure, the mint upper limit of USTC is 100 ncUSTC, but only 50 USTC was minted, so the state is “burn 50 ncUSTC” and “maintain the remaining ncUSTC”.

ncUSTC when USTC/LUNC rises

Since ncUSTC is minted at the time of delegation, I will explain the case when USTC/LUNC rises (USTC supply decreases).


(Left: 100% undelegated) (Right: 50% undelegated)

When USTC/LUNC rises, undelegating ncLUNC 100% burns ncUSTC 100%. Similarly, undelegating ncLUNC 50% burns ncUSTC 50%.

ncUSTC burn criteria and USTC/LUNC mint criteria
When USTC/LUNC rises: Burn ncUSTC by the percentage of ncLUNC that undelegates. Let this be “burn_type_A”.

When USTC/LUNC falls: Burn ncUSTC by the minted amount of USTC. Let this be “burn_type_B”.

Since it is difficult to let the blockchain itself determine the increase or decrease of USTC/LUNC, we will adopt a type that calculates typeA and typeB separately and burns more ncUSTC.

How to select ncUSTC burn amount by python code

Destination of minted LUNC

I think that many people worry about “I’m burning and reducing the supply of LUNC, but are you going to mint LUNC again?”
Send all minted LUNC to the Oracle (staking) reward pool to turn anxiety into positivity.

With this, it is possible to compensate for the currently worried Reward Pool and avoid the selling pressure of LUNC by mint at the same time.As explained below using the diagram, you can see that the Oracle Reward Pool will continue to be refilled after the USTC repeg.

Conditions for occurrence of LUNCmint(illustration)

The condition that LUNC is minted is only “when USTC/LUNC is lower than at the time of delegation”.The conditions for the USTC/LUNC to fall are “when the rate of decline in USTC is greater than the rate of decrease in LUNC” and “when the rate of increase in LUNC is greater than the rate of increase in USTC”.


LUNC is minted under these conditions.
In other words, after USTC re-pegs at $1, the price increase rate of LUNC will continue to increase relative to USTC, so the higher the LUNC price, the faster the Reward Pool will be replenished.

Maintain peg (if over $1)

Reactivate the “USTC mint → LUNC burn” algorithm that had realized the UST $1 peg before the LUNA crash in an irreversible (one direction only) manner. Even if USTC is temporarily depegged for some reason, “LUNC mint → USTC burn” is never performed. Mint/Burn swaps caused by user manipulation are also not reinstated.

Decrease USTC with FD and maintain $1 with “USTC mint → LUNC burn” algorithm when USTC exceeds $1 (LUNC burns)
It is such a simple structure.USTC will always continue to decrease until it reaches $1, and all minted LUNC will go to the Oracle Reward Pool. If the reward increases, the number of FD and staking users will increase and a positive chain will start.

How rewards are calculated

FD also receives rewards from Oracle Reward Pool like staking.
It consumes USTC, but only delegates ncLUNC (non-circulating LUNC), so it depends on how staking rewards are calculated.
For example, if you stake 20000 LUNC and delegate as FD an additional 20000 ncLUNC It’s a simple calculation, you’ll get a staking reward for 40000 LUNC (20000+20000).

Advantages of this algorithm

The algorithm can be repeged while receiving rewards and at the same time replenish the Oracle Reward Pool. Even if LUNC is minted, it will not lead to selling pressure and will

never become a death spiral because hyperinflation does not exist. It is a simple method that can be completed within the Terra Classic chain without the need for fundraising through token distribution.

Disadvantages of this algorithm

USTC opportunity loss may occur.

Note: I don’t have any development skills, so I need to ask the L1 task force or ask volunteer developers to write test code. Terra Station needs to be changed, so we need to ask TFL.Correction of reward payments from the Oracle Rewards Pool is required.


There was a mistake in the image used in the item “ncUSTC when USTC/LUNC falls”, so if you want to check the correct image, please check my twitter acount.


Awesome. I have always wanted the flexible saving! I hope this prop will pass.

1 Like

I am against this proposal, because coinage cannot return under any circumstances. however, I thank you for your dedication to put together this proposal.


Flexible delegation feature is a good idea help to maintain the peg, I think ,it can work collaboratively with another algorithm such as Divergence protocol and ziggy.


many theories but no one puts them into practice.

1 Like

Missing this part here:

Team to conceptualize it, test it, collaborate with all necessary parties?


I got in touch with #LuncBurnArmy, manager of the L1 Task Force, and he agreed to share this repeg ideas with the L1TF team.


The easiest way is to burn USTC instead of LUNC at the expense of all taxes. And of course, Oracle USTC we need burn also. We can use MMM with upper limit also.

Reminds me a bit of liquid staking tokens and a concept I ran by people several months ago called Dynamic Bonds.

The way I read this is closer to an amortized swap. So you’d put amortize 100 USTC worth of LUNC (~18.5k at time of writing) by swapping it over a given time period (say, 1 day+).

If this is what you are aiming for, I think it is a good idea and will make accounting easier. However, we have been trying to stay away from new abstractions of coins eg ncLUNC / ncUSTC, although I see that you are using it for demonstrative purposes.

In general, I would utilize a time-locked vault instead of new mint abstractions. I understand many Ethereum tokens, such as yvUSDC, are representations of vault tokens. Perhaps there is a way to mirror this on the Layer-1 of Terra Classic.

Here’s an example:

Lock 100 USTC for 3 months
Over 3 months, 100 USTC is swapped to the equivalent in LUNC
This process can also be reversed (as in lock LUNC, swap to USTC)
Create an ERC-4626 token on a mirror protocol on Ethereum representing this position
Destroy the token over time to the target token

The benefit of the above methodology is that users can opt-in to a cross-chain swap to any asset that isn’t LUNC or USTC while still participating in LUNC burn or USTC price appreciation (whether by contraction or value-add).

For example, the process can look like this:

Lock 100 USTC for 3 months on Terra Classic
Create a ERC-4626 token on Ethereum representing the value of 100 USTC at the time
Choose target asset (wBTC, WETH, wLUNA, wUST, USDC, USDT, etc) – this can be on any chain, but Ethereum has vault standard contracts
Over 3 months, that 100 USTC will be burn (amortized) to the market value (or OTC, if desired) of the target asset

Coinbase does this with USDC, which rotate 3-month US Treasury bonds every few days.

I understand I wrote “no new abstractions,” which is why you use existing coins on another network to facilitate this. Goerli Ethereum (GETH) is already set up for this kind of thing, seeing as the gas token has been monetized by Layer-0 and uses Proof-of-Authority, which is similar to how BSC and other Cosmos-based chains run, especially with EVM.

As far as “fluid staking” with LUNC goes, it would be wiser to simply integrate Alliance and/or Stride and allow cross-chain staking. Classic users can opt to use Eris ampLUNC for liquid staking.

Anybody who wants to hold USTC for higher prices can do so by holding spot. They will pay carrying costs in doing so.

In my experience, you need a third currency to realize a solution to the problems Terra Classic faces. If it’s just LUNC and USTC, you will be swapping it back and forth, extracting idle holders forever via carrying costs, until interest (oracle pool rewards) are gone. In this sense, I would not necessarily rotate supply units back into the Oracle or the Community pool. The Oracle will sustain the network as long as work is put in, and the Community pool will facilitate the work necessary to ensure that.

I wouldn’t think of the gap between USTC and $1.00 as “needing to mint.” That is a large reason why this problem exists in the first place. The chain’s “GDP” needs to increase. I have mentioned elsewhere that this is like asking the USA to start producing domestic instead of exporting goods and services internationally. USA’s inflation led to other IMF currencies losing value (EUR drop via Greece bailout, GBP drop post-Brexit) – JPY has been in a similar situation with continuous debt issuance, and so, RMB dominates the market.

On this note, it is better to think of Terra/Luna on Classic as developing accounting tools. Your concept serves as a way to introduce rotating bonds (a la USDC) into play which I think is an excellent idea. There might need to be some code implementations and trimming-down, but it can work. Nicely done.