This is an interesting proposal and I’ll share my thoughts. My concerns are during a big drama event like a major crypto crash, 10% loss to immediately undelegate is not significant enough to stop mass undelegations. If the market is dropping 50% what’s 10% cost to exit? With mass undelegations we will get good burns from the exit event, but mass unstaking. As long as validators are still running the chain should still be stable.
On the other hand during stable market conditions 10% is reasonable for a fee, so the feature will be used to bring burns, otherwise what’s the point of a feature that is not used. 5% is too low, 20% is too much. 10 or 15% is suitable for this purpose. It’s too complicated to have different fees at different times for market conditions, so a flat 10 or 15% would be best.
For the proceeds 100% burn is okay but a 90% burn 10% CP would be good too. Undelegating instantly is like an exploit of the normal chain rules so having part go to fund chain development would be okay also. The % proceeds could also be set based on the current value of the tax AnteHandler (currently 90/10%).
Having only 21 days or 30 days option if you don’t want to lose LUNC, and then a 10% tax on undelegation is a financial penalty to those who want additional flexibility with their LUNC stake. For that reason I prefer a flat 14 day undelegation period. A flat 14 day undelegation period with a 10-15% instant undelegation could be good. It gives people more flexibility without financial cost but is still 2 weeks wait, and gives those who want instant access a way to have it, while contributing to the chain by burn/funding CP.
If your proposal goes to vote I’m not sure what I’ll vote, but I’ll consider it further.
[@LUNCPREDATOR]
Am on the same train of thought as @JESUSisLORD; completely eliminating some form of market shock absorption from the system is not wise.
I would suggest we change the cool-off period to 7 days for a (10-15)% “fast undelegation” privilege charge. That’s a third of the typical undelegation cooling-off period which makes it lucrative enough to use and at the same time provides some basic market shock absorption capabilities.
Should we want to allow an immediate undelegation option I would use the equally penalizing 50% tax bracket; Whatever the market conditions, would make you think twice about pulling this trigger. At the same time would make it a win-win case as far as the chain total supply is concerned should someone choose to do so
Hello everyone and thanks for your opinions. Here again, I am answering all of your questions and concerns en masse:
I reiterate that this risk exists. But let’s ask ourselves the question, how to make this wonderful and necessary function so that it is safe?
Let’s imagine the worst possible scenario, which, however, will not happen 100%. In a single quick moment, all currently staked coins (1 trillion LUNC) will be immediately pulled. At the same time, a 10% tax would ensure that 100 billion LUNCs would disappear from the total supply forever. Furthermore, if LUNCs were to be dramatically withdrawn from delegation, then the people left with coins in delegation would benefit from a massive increase in rewards, as the rewards would be redistributed to fewer people.
I propose to increase our protection as follows:
The tax for immediate cancellation of delegation must be as high as possible (minimum 10%, optimal 20%)
We can extend the standard waiting period from 21 days to 30 days
My latest math is going towards a 20% tax. (10% burn, 5% community pool, 5% oracle pool).
Sorry, I’m not a fan of shortening that waiting period. On the contrary, I would welcome its extension or locking for a precisely determined time without any possibility of withdrawal before the end of the maturity period.
I believe we can agree that this tax must be as HIGH as possible. Opinions that it should be 1-3% are absolutely misguided and dangerous for the blockchain. Currently, my mathematical calculations lead to the conclusion that a 20% tax would be much better and safer than 10%.
And at the same time, we would gain space to obtain funds for development:
20% tax for immediate cancellation of delegation:
a) 10% to the burning wallet
b) 5% to the community pool
c) 5% to the oracle pool
I wonder how you keep clinging to this locked trillion. In the event of mass sales and panic, neither 10% nor 20% will save the situation. Much more interesting is where the rest of the money is. About a trillion is traded on the CEX per day. But this is per day, and at a time 200 billion. Where are the other 5 trillion?
Good idea. I would add one thing - to make sure that chain remains secure if there is massive undelegation at once, and total delegated amount of LUNC decreases to less than 10%, than faster undelegation by paying 10% tax is disabled, if total delegated amount again reaches more than 10%, it is possible again instantly undelegate by paying 10%.
So this change would have a cost associated, it needs to be implemented. Do you know the scope of change required and an estimate to develop this?
You mention lots in the community want this, I mean that makes sense, who wouldn’t want to be able to exit their staked position as quickly as possible. So beyond that what outcome/benefit, for the protocol, do you expect this change to deliver?
Can this outcome/benefit be quantified/estimated?
This change would introduce some level of risk to the protocol.
If you weigh up the value of the change vs the cost and risk… Would it make good business sense to proceed?
You are very right. One of the most important questions is how to protect the chain in the event of a massive “bank run” - mass withdrawal of delegated funds. This is still up for debate. We see the solution in the optimal ratio between:
The amount of LUNC that can be immediately released from delegation to the circulating supply (based on this proposal, we expect 90% of the withdrawn amount)
The amount of LUNC that we will throw away during this event (burn wallet, oracle pool, community pool) (based on this proposal it would be 10% burn)
Bonus: Additional security mechanisms that can limit such activity.
We can use none, all, or only some of them:
determining the maximum amount of delegated coins in percentages that we can instantly withdraw using the “Fast undelegate” function
daily / weekly / monthly limit
algorithmic linking of the amount of this tax to the volumes of withdrawals for the last period
other
Implementing this change would require modification on several layers. Additional discussion with developers is required. This discussion is scheduled for the second update of this proposal.
Yes, I have already done these calculations. See my previous comments.
I listen carefully to all requests from the community. I announce that I agree with the requirements for funding the Oracle pool and the Community pool in order to maintain the development and prosperity of the Terra Classic chain.
**As I have already announced several times, I insist that the burning must not be lower than 10%.
Therefore, I propose to increase this tax from 10% to 20% and to distribute these funds as follows:
The community pool funding is already handled by the Tx fees increase and the Ante Handler parameter recently put in place. The latter also will make sure a portion of the burned percentage makes it into the CP anyway!
Maybe:
15% Burn Wallet (reduction of total supply)
5% Oracle Pool
Also, the “Bank Run” protection harnesses (algorithmic or mechanical) need to be made known and reviewed before the proposal makes it into the voting stage. It’s a too critical component of the proposal to be left out of this discussion…
One concern that was voiced was - “We have to consider the worst possible scenario.”:
I have already commented and expressed the worst possible scenario in my calculations in previous comments.
The worst case scenario (and an unrealistic one) is that a mass undelegation of ALL coins happens. This currently amounts to 1 trillion LUNC (1,000,000,000,000 LUNC).
If 1 trillion LUNC were undelegated using the “Fast undelegate” function, this would happen:
Calculation in case of 10% tax:
increase in circulating supply by 900,000,000,000 LUNC (temporary increase in circulating supply by 16.044%)
immediate reduction of total supply by 100,000,000,000 LUNC (permanent reduction of total supply by 1.458%)
Calculation in the case of the new 20% tax:
temporary increase of circulating supply by 800,000,000,000 LUNC
immediate and permanent reduction of total supply by 100,000,000,000 LUNC
profit for Oracle pool 50,000,000,000 LUNC
profit for the Community pool 50,000,000,000 LUNC
However, I remind you that the eventual cancellation of delegation causes an extreme increase in the volume of on-chain transactions, which would also be further burned thanks to the 0.2% tax on on-chain transactions.
I think 20% it won’t get used enough to be effective and is too big a jump from 10%. For me 15% seems the limit of what is reasonable and is probably ideal. You could have 10% burn 2.5% CP 2.5% Oracle Pool. I like the 50/50 split between CP and OP as that mirrors the gas fee setup. I think it would get used a lot and contribute well to burns and funding. Would you use it at 20%? I would think about using it at 15% in certain circumstances.
I disagree with @godoal and think CP should definitely be included. If we get excess CP from other means we can cap it and flow it to the OP anyway.
Yeap I get that and your calcs in the post are spot on and do make sense.
The million-dollar question is how do we create a framework that incentivizes regular traders to use the (10-15)% option while disincentivizing a move toward the worst-case scenario which, should certain individuals choose to pursue, would provide the max benefits to the chains’ total supply.
For example, a mechanical solution to that would be something like this:
Personally, I don’t mind if it’s mechanical or algorithmic as long as it has a stick and carrot in it and balances the risk/reward scales
This proposal has a lot of potential so worth finding the optimal solution for our chain.
Sorry to be blunt but this feels like a vanity metric, not an outcome that delivers any meaningful value.
What problem is the 21 day lock up period actually causing? If we were to fix that what would it mean for the protocol e.g. “we would get a sudden influx of new delegators? If we were to get a sudden influx of delegators, why would that be a good thing for the protocol?”
The biggest risk to lunc is complete failure, Why would we use the limited development resource to work on this over creating other meaningful product changes, that allow us to win in the market we play in? Again, sorry to be blunt; who cares how long your assets are staked for, if they are worthless.
Is this akin to fixing the central locking on a car, whose engine is about to fail?
So yeah, the value assumptions of the proposal just don’t make sense to me.
Hi everyone.
I believe we should consider together the following two potential changes:
bringing undelegation fees up to 20% (15% to burn wallet and 5% to the Oracle Pool) ;
increasing unstaking period up to 30 days.
The reason for this second change is that we actually want people to pay the 20% fees if the price dramatically increases. We all know that at some point stakers will need to give up on some of the bags they hold, otherwise the total supply will always stay, at least, above 1T.
I understand that 20% is a very high fee, but 30 days (or even more) are quite a lot too, so people, under certain conditions, might choose to instant undelegate and pay the fee.
I saw Garuda nodes mention this on Twitter but if there’s an instant undelegation period then if someone’s wallet is hacked or compromised, they cannot use the stake recovery service available from Allnodes for example as the hacker would simply instantly undelegate and take the coins.
If the undelegation was fast instead of instant, at maybe 24-48 hours it could still work. I don’t know how much time a service like that needs to recover a stake. Something to consider as I do like the fact hacked accounts who stake can be recovered by currently available services.
You have to protect the users from their own brains. If holders panic sell at -10% loss at the same time, the chain will be not safe.
I repropose my ideas here:
48h security lock
let’s add a 48hr staking freeze time protection. If you stake lunc, you cannot unstake for 48hrs. this is an extra security measure. If a man wants to secure 100% of his wallet, he needs simply to stake 1 more lunc/day.
Unstaking penalty
The thing we can do is introduce the possibility of an earlier unstaking with penalty.
21 days unstake > 0% penalty ( regular unstake, 100% of tokens are returned )
14 days unstake > 1% penalty ( so 1% of tokens are not returned but burned )
7 days unstake > 2% penalty ( so 2% of tokens are not returned but burned )
