Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

Governance & Proposals
111

Awesome!!! That was very helpful, and hopefully correct LMAO I greatly appreciate it and believe that this is a really good idea. Looking forward to it’s implementation!

Cheers!

112

Because of the proposl you proposed, this uproar is happening and everyone is suffering, but you are so calm?

2 Likes
113

@ek826 hasn’t commented on the suggested technical item yet; he has too many comments to read through… :wink:

1 Like
114

Are you sure about this? TR has access to the offical multi-sig wallet?

115

I thought I was the only stupid one saying this, here and on twitter. I dont want pills to be pushed down my throat. Some people are like, since it’s @ek826 and @Zaradar then everything is good. NO! Question and comment on everything you want explanation on. @ek826 recommends you do so. We have to be very careful when we vote “YES” on any proposal.

4 Likes
116
  1. Let’s reintroduce the LUNC 1.2 burn tax and apply it to the chain.
  2. Let’s limit the LUNC supply and no longer print LUNC.
  3. Let’s transfer the proceeds from the LUNC 1.2 burn tax (90% LUNC burn) (10%) to the community pool

4.binance will accept these offers.

@ek826 @Asobs @ClassyCrypto @Alessandro_Nardaggio @David_Goebelt @LunaticstokenValidat @HappyCattyCrypto1 @HappyCattyCrypto @lunc_nymph

2 Likes
117

It appears to be their donation wallet, funny enough that is not the address they post on their public sites but searching over google the address comes up on various TR notifications.

1 Like
118

No, it is quite different. Proposal is hard code 50% tax send to cp, while i suggest to keep the rewardpolicy parameter.

I would whether just created a separated burn wallet for 0% reminting. It is lallow cz burn 100% tax.

I don’t mind remint at the end of epoch, it is literally same as same the fund during taxing.

My concern is hardcode 50%

119

It should not. Tax rate parameter can be changed 0.2%/0.6%/1.2% etc. What will not change and can only be changed with a program upgrade is the split of the amount passed by parameter tax change . It will always be 50% CP, 50% burn.

3 Likes
120

Hello to the Luna Classic community, I would also like to thank Mr. Edward Kim for his efforts. I am a LONC loser. Everything I had in my life has been destroyed. Now I am living with two children. The economic situation is really painful. I am desperately asking everyone to help in their capacity. If necessary, I will provide documents to prove that I am really a loser.

terra1htrgm44k6f3shyd34pwty7zjldrtsf7wjtsyqz

121

We approved a 1.2 tax to reduce the LUNC supply and it ended at 0.2, and a percentage was diverted for the community pool… a total failure, Now we are committed to raising the tax on burning again, we approved 11111 and we once again propose the reduction of the money that goes to be burned.
There are some who do not understand that the first problem we have is that there is LUNC to give and take. supply must be reduced. That is not incompatible with filling the community pool. That there is not a first and a second, that you can do both things at the same time. That one thing does not take away from the other, that they can be implemented in such a way that one thing does not exclude the other. That the money from burning is not diverted to the pool (perhaps 10, if necessary) that there are many good ideas to fill the pool without subtracting money from burning and without making great sacrifices, but that everyone must put their share and contribute some of the profits.
Everything is a whole. If we reduce the necessary supply, the price of LUNC and the value of the pool will rise, and developments and developers will be able to pay. And on the other hand, if we are able to fill the pool and progress is made in large developments, the price of LUNC and confidence will rise.
I repeat again we stick to knowing which comes first, the chicken or the egg and I think that both options should not be ruled out… burn and develop by filling the pool. Keep burning and look for formulas to fill the pool.

4 Likes
122

I c, similar outcome different approach.




My worry also is (and from what I gather @RabbiJebediah and @Dannavan_Morrison too) the unrestricted (fixed) collection of that 50% going to the CP from the on-chain tax proceeds.

Since we have a ballpark of how much we want for dev purposes why not cap it to the amount we want to be collected in there and aid the BURN with the overflow…feels like win, win!

My dream is that of “BURN EVENTS” organized twice a year and lasting a few days (or a week), where we increase the tax rate for that period into something ridiculous (say 50%). Would be a shame to lose half of those proceeds to the CP :slight_smile:



Even that 10% can fill the CP with more coins than those needed to fund development, I would suggest even in this case putting a CAP. So one way (50/50) or another (90/10) what will end up in the CP is the same and the overflow gets burned.



Had to ask, Trust but verify :wink:

1 Like
127

I think this is great, this is the right way for lunc blokchain, i support it.

129

Hi @ek826 ,

Three questions and a comment.

I do think it is good to separate out the seigniorage mechanism (while retaining it for further use as may be needed - rather than fully depreciating it), from the burn tax (whose purpose is for supply reduction through a type of collective buy back and burn through transactions).

Questions:

  • Do you intend this mechanism to fully replace seigniorage, or to be a complement to it?
  • Although I can take a guess what would happen, I would like to ask, what happens if this is implemented, and the Treasury’s RewardPolicy parameters min and max are set to something other than 1.0?
    • Comment: While I would advocate that the RewardPolicy be kept (not necessarily deprecated for later removal), I do think it would be good that it be coded so the new code does not cause unintended consequences if both the new code, and RewardPolicy min and max, are active at the same time.
  • Lastly, why is this not being parameterized (below outlines how this can be accomplished for v0.44)(is there an edge case, or technicality, that I am missing that prevents this)?

Thank you.

I hope you have a great day today :slight_smile:

130

sending tokens to the burning wallet should have no TAX

131

Great idea! However the community voted for an emphasis on burn with the passing of proposal #11111. It would need another governance proposal to repeal #11111. Hence the split should not be hard-coded, rather it should be set algorithmically based on

  1. price of coin
  2. volume
    3 . Dev cost

Then the calculation may be done on a weakly basis.(epoch, whatever)

ex. may have some type but here go

dev_cost_per_week = S12,000
price_value=Current(price)
volume_value=changeinvolume(volume)
split_amount=price_value*volume_value
(
if split_amount>=dev_cost_week
(
cp_extra=split_amount - dev_cost_per_week. // extra value for 90/10 split
cp_value=dev_cost_per_week+10%*cp_extra. //sent to cp pool
burn_tax_amount=90%*cp_extra //sent to burnt wallet
}
.cp_value=split_amount //full amount sent to CP … split_amount is less than dev cost for the week
)
…

Another wonderful idea, but we would have to get the support of investors and cexs. As you pointed out the 50/50 will to a certain extent defeat the purpose, since a program update will be required to change the split.

1 Like
132

Don’t forget cosmoscapybara who proposed proposal 10983

1 Like
133

Hi @ek826 can you consider 50/50 ratio with Oracle pool also. I mean to say that
50% to burn and 25 to cp, 25 to oracle pool. Please give your view on this

134

Lunc is in a huge crisis because of only one person
Someone please shut up the cosmoscapybara

1 Like
135

Actually people and validators who voted yes are to blame.

2 Likes