[Proposal] Deprecate Seigniorage Reward Policy and Increase Gas Fees by 5x

Why are you still here?

Can we please leave all the political spin-offs out of it…

1 Like

When it will rise to 3-4x again we will see how easy will be
or you put in a auto- multiplier and demultiplier, or it will be a full mess.

Another problem is: Funding devs means funding L1 team, nothing else. That’s not good. Luna Community funds also other projects. Lunc community seem to going approve ONLY L1 team.
Lunc community use 80% CEXs not DEXs. And do not give a shit about DeFi.

Either you change your approach - just L1 Team is good, everything else is nothing - or new projects (except for a few scam attempts, or hit-and-runs) will not even think of entering Terra Classic.

Those left behind, because the new holders barely know how to use a wallet. The dexes have never even used them and probably have no intention of using them either. Unfortunately.

For the rest, we have already seen what happened with the tax burn. Increasing it decreases the already poor volumes in DeFi.

At least then we can remove the tax burn, and make 1/3 validator, 1/3 CP, 1/3 burn. But adding a 5x on gas fees on top plus having the tax burn is shooting ourselves in the foot.

We have to understand one of the few reason to choose Lunc instead Luna is cheaper costs. if we go and narrow these differences, we discourage its use too.

My 2 cents.

1 Like

I think its a good idea if all devs are ok and all side effects calculated to not hurt the network it can be very good.

1 Like
1 Like

I am afraid you are a bit late to this discussion. This proposal is a continuation of what started with @ek826 proposal here Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy - Governance & Proposals - Terra Research Forum and has now been put to vote.

Please read through the discussion on @ek826 proposal first and follow through to this one here, to get the ins and out of how we got here. There are also some projected cost profiles there which fed into the values you see here.

Yeap, the chain will start to provide funding for its maintenance/support the way any other blockchain does.

Zaradar is still talking about a code-based solution according to the initial proposal @ek826 raised here. Based on that, half the income from on-chain burns would be hardcoded to fund the community pool for dev purposes.
This proposal is a continuation of that one and takes a slightly different path, which ensures dev funding and at the same time respects the BURN effort making sure anyone (CEXs, Individuals, on-chain tax) sending money to the burn address will BURN in its entirety.

6 Likes

Would using the mechanism from this proposal mean leaving the antehandler and hardcoded 50% cp split alone?

Dont feel intimadated by others, Vegas. For some is nice u still be around!!!

2 Likes
- repeg steps

	- 1 - mint a coin called BUST with same capabilities as USTC and LUNC

	- 2 - create a pool of USTC and BUST

	- 3 - change arbitrage code to use BUST instead of LUNC the mint and burn amount of 

		USTC / BUST are the originals when USTC was peg

	- 4 - set a tax of 0.2 % in arbitrage code for every arbitrage transaction

	- 4.1 - arbitrage tax can be paid in LUNC USTC and BUST

	- 4.2 - 100 % of arbitrage tax is burn 

	- 4.3 - 50 % of last arbitrage tax is mint into pool of USTC and BUST

	- 4.4 - 50 % of last arbitrage tax distribution, if in the pool the distribution is 50 / 50 %

		of USTC / BUST then 50 / 50 % of last arbitrage tax distribution is mint

		as 50 / 50 % USTC / BUST into the pool.  Else if in the pool distribution is 51 / 49 % of

		USTC / BUST then 49 / 51 % of last arbitrage tax distribution is mint as 49 / 51 % 

		USTC / BUST into the pool. Else if in the pool distribution is 49 / 51 % of USTC / BUST 

		then 51 / 49 % of last arbitrage tax distribution is mint as 51 / 49 % USTC / BUST into 

		the pool. Else always mint the oposite distribution % of the asset distribution % in the pool, 

		to try to keep a balance

	- 5 - change arbitrage code to attempt repeg to values of 0.01, 0.02, 0.03, 0.04, 0.05, 0.10, 

		0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.45, 0.55, 0.60, 0.65, 0.70, 0.75, 0.80, 0.85, 

		0.90, 0.95, 1.00, 1.00, 1.00, 1.00, 1.00

	- 6 - change arbitrage code to attempt repeg only if USTC / BUST pool have a value % of the

		USTC + BUST market cap of 0.1 %, 0.2 %, 0.3 %, 0.4 %, 0.5 %, 1 %, 1.5 %, 2.0 %, 2.5 %, 

		3.0 %, 3.5 %, 4.0 %, 4.5 %, 5.5 %, 6.0 %, 6.5 %, 7.0 %, 7.5 %, 8.0 %, 8.5 %, 9.0 %, 9.5 %, 

		10.0 %, 10.5 %, 11.0 %, 11.5 %, 12.0 %

	- 7 - change arbitrage code to use 1 of 2 times USTC / BUST pool instead of mint USTC / BUST 

		whenever the USTC / BUST pool is up the USTC + BUST market cap % require and also +/- 0.005 

		close to reach the repeg value.  For example when repeg to 0.05 will riquire a pool of more than

		0.5 % of the USTC + BUST market cap value and will use the pool assets when USTC value 

		is between 0.045 and 0.055, 1 of 2 times, one use the pool and the other use the original arbitrage

		protocol.

	- 8 - arbitrage code will move to next repeg value whenever USTC / BUST pool size requirement is met

		In the case when the USTC / BUST pool size goes lower the current stage repeg requiriment, the protocol

		wont return to repeg using last stage value until USTC / BUST pool size gets below last repeg value 

		requiriment.  For example if repeg to value of 1 with pool size of 10.5 % USTC + BUST market cap, 

		will attempt to repeg to 0.95 value only if pool size of drops below 10.0 % of USTC + BUST market cap 

		and not if goes below the 10.5 % of current repeg value requiriment.

	- 9 - arbitrage code will use the USTC / BUST in specials cases

 	- 9.1 - arbitrage code will use the USTC / BUST special case pool when size of 10.5 % and value of 1 +/- 0.006

		This means when repeg to 1 will riquire a pool of more than 10.5 % of the USTC + BUST market cap 

		value and will use the pool assets when USTC value is between 1.006 and 0.994, 1 of 2 times, 

		one use the pool and the other use the original arbitrage protocol.

	- 9.2 - arbitrage code will use the USTC / BUST special case pool when size of 11.0 % and value of 1 +/- 0.007

		This means when repeg to 1 will riquire a pool of more than 11.0 % of the USTC + BUST market cap 

		value and will use the pool assets when USTC value is between 1.007 and 0.993, 1 of 2 times, 

		one use the pool and the other use the original arbitrage protocol.

	- 9.3 - arbitrage code will use the USTC / BUST special case pool when size of 11.5 % and value of 1 +/- 0.008

		This means when repeg to 1 will riquire a pool of more than 11.5 % of the USTC + BUST market cap 

		value and will use the pool assets when USTC value is between 1.008 and 0.992, 1 of 2 times, 

		one use the pool and the other use the original arbitrage protocol.

	- 9.4 - arbitrage code will use the USTC / BUST special case pool when size of 12.0 % and value of 1 +/- 0.009

		This means when repeg to 1 will riquire a pool of more than 12.0 % of the USTC + BUST market cap 

		value and will use the pool assets when USTC value is between 1.009 and 0.991, 1 of 2 times, 

		one use the pool and the other use the original arbitrage protocol.

	- 10.0 - arbitrage code will remain the same for other cases

why we are just staying arround one proposal,
increase tax, decrease tax
is that all what we can propose??
i dont agree with that proposal, and the comparison with luna2 is too far incorrect, since most if the volume come from cex

If this passes, i would think it means we do not touch the burn tax (there would be no need to if seigniorage is 0).

4 Likes

@ek826 Hi Ed now we have this new proposal up for voting (mint to 0, 5x gas fees), this satisfies part of Binance’s request to stop minting. The other part of Binance’s request is their wallets whitelisted. Could we get this done asap to complete Binance’s request or what would be the eta on that? Thank you very much for your hard work for LUNC.

Very nice idea, i was for a x2 x3 but comparing us to others blockchain x5 isnt even an overkill. Would it be possible to make a cap on the CP at like 5 billion and once that theeshold hit, it direct the overflow to the burn wallet so once the 5 billion hit, it focus toward an extra push for burning ?

Also increasing to x 5 actualy make it so the 0.2% tax itself will burn much more ?

Thx

I agree with the cap on the community pool as has been proposed earlier by valuable contributors. If we go over the cap direct it to the burn wallet. This should be a governance parameterised proposal which the cap amount can be changed in the future without difficulty to account for LUNC price rising. A cap of 5 billion LUNC is currently worth $793,500 USD (at LUNC $0.0001587) which is a reasonable cap, especially as price increases. A 10 billion LUNC cap would be $1.587M at current LUNC price. This would be a great proposal which deals with excess funding by redirecting to burns.

Hi,ED.you already had a TGF as a substance to interact with that funding plan.Why we still want devs be fund by ourselves?why not leading a big campaign including these small devs group’s projects and ask a big budget from binance revival plan at one time?
And Binance already give us a direction,TGF lead these projects development.

Nice one. Only thought is how can we make such changes automatic :cat:

I’ve tried asking Binance for funding 3x in written form through formal applications, and informally more than 5 times in voice/video/chat… I will continue to ask until they get tired of saying no and stop talking to me.

17 Likes

@ek826 Excellent work Ed your efforts are greatly appreciated! Keep it up! Remember Binance only agreed to do the burns due to pressure and continual asking. I think this is a relevant passage, Luke 18:1-5 NKJV (you can google it).

1 Like

I think on the L1 side, its important that we menage to fund ourself our dev, this will show a healthy side recovery. Binance can and will likely help to fund protocol/apps, we will see how they help out on that side later on. As the lunc price will increase, the 5 billion fund will be worth much more. We have to beliave in our evolution overtime and recovery. As for the gaz fee, if you got a way to make it so it can be easily changed as overtime a X5 will hurt as the price increase and we could even start with a x 10 with this low lunc price. Pershap Ed you can find a kind of chart where the blockchain fee increase or reduce from x10-x1.5 as the lunc price raise or fall. The sweet spot versus lunc price point.If thats possible to even be automated.

@ek826 has just mentioned that it is possible to parameterize the burn split on the burn tax and also provide a “new burn wallet”. Imo, this effectively cuts out minting.

Qus.

  1. Will the increase gas fee be able to fund the dev teams? If yes, will the burn tax be split according to proposal 11111?
  2. Please explain how @ek826 new statements would relate to the seignorage proposal?

@ek826 mentioned a “new burn wallet”. Hence there would be