The volume will fluctuate and any projectons of the actual income from the tax will hardly ever be accurate - either over or under the target. So safe to say a higher % of cp funding is preferable. Excess can be burned off manually or kept as a reserve to fill months that are not ‘profitable’ lets call it.
This should be a subject for another proposal. If the L1 dev team cannot deliver Tax paramaters that are controlable through Terra Station voting, this change should not go forward.
In this case seek for another alternative to exempt Cex and Individual Burns by setting up secondary burn wallet as an example.
In this case we can still use the rewards.policy mechanisms as long as it will only apply to ONCHAIN transactions and nothing else.
Personally, I don’t care if it’s under the target, it only means we need to wait one more week/month(s) for the funds be available so whatever development starts.
What bother’s me is being over the target so we don’t waste money when we could put them to good use.
I start to like that idea as well. It will give us fine control of the speed by which we populate the community pool, up to its cap limit, out of the on-chain taxes as and when needed.
i.e assume we are on a slow period and we have an urgent development to go through but not the funds. So we only need to tune that (proposed but unneeded hard-coded) 50/50 into 10/90 so more (again ONLY from on-chain tax) funds go to the CP than BURN until we reach our target.
They are all relevant to this change so it can be done in the context of this proposal by exposing the AnteHandler CP allocation parameters to the treasury parameters API instead of being made fixed.
For example, consider the following:
Where, rate_min=rate_max=0.4 defines the split rate i.e 40/60 (CP/BURN)
and, cap amount=14000 defines the weekly cap in $ the distribution function needs to use
In total agreement. L1 developers must not be allowed to eat their cake and still have it. Hard-coding the percent split whether 50/50 ,90/10 , 80/20 etc…IS A NO. It should be done by parameter changes under community governance. We need a team that listens to us and represents us at the “devs/retailers/validator AMAs”
@godoal ideas on CAPPING the CP are great ideas. The L1 dev team/TGF should be able to figure out the weekly budget that should be able to fund L1 and L2 developments.
From our discussions would the following be reasonable assumptions?
If the tax revenue is less than the required funding amount then all revenue frorm tax should go to the CP.
If the tax revenue is greater than the funding amount, then the funding amount should be sent to the CP . Additionally, the difference between tax revenue and funding amount should then be split and 90% goes to Burn address and 10% goes to CP based on proposal #11111. The reason for the 10% to CP is for incidental costs. Hence, it is important for the split to be parameterized. For instance if projected weekly funding for development is reduced, then the community can decide what to do in terms of splitting the tax revenue by simple using parameter changes instead of asking for a program upgrade, which honestly I dont know what that will entail, but it seem that it would be more difficult or take more work to achieve.
So this parameter will constantly be interacted with based on your weekly funding. Something we want to avoid. You guys are something. Also remember the funding is not just for L1 devs, we have to look into external investments, L2 dev funding (community owned), marketing, adverts and all the likes I cannot list here. That 50/50 split must have a reason. Lets look at that first then we can decide. This narrative we all have that burning will save the chain without any utility yet is the biggest lie I have ever heard. We need utility to have ultimate burns no matter the burn amount. Worst, utility needs funding. All the adverts need funding. In general, we clearly see that funding is needed more than burning based on all the needs of the chain. We are still struggling on one leg, burning money will get us no where. Think clearly about it. We fund the CP so that we can actually get utility or we keep on burning most of our funds with the hope of waiting for almost 40 years to burn the LUNC supply. Take a pen for yourself and calculate the time it will take. But if we fund development on chain, attract more utility, more dapps with our cheap fees, get people to come more into LUNC. Imagine how much we can burn in a single day. Before we know it, 0.2 would be too much and we will have to even reduce it further. Just my opinion…NFA.
What I know is, 50/50 split wants to be changed to 90/10 based on 11111. Am not wrong on that. My opinion is to ask, why the 50/50 was suggested before moving on to 90/10 based on 11111 since it is already in effect and will not change until the community comes to an understanding. And on the issue of burning, I am explaining what I understand burning truly is and telling everyone who supports it to investigate. That is the translation of my reply. Ahhh yes, I have been following the thread even the second proposal that was brought up from this one.
Besides no one has talked about the burn narrative but they all think it.
You want to fund the CP yes, but is the partitioning correct??? The weekly budget allocations?? Will it not need constant change of the parameter weekly. This weeks budget is 20K for all L1 devs, so change parameter to 20K so that CP/Burn allocation can adjust. Am I also wrong in that understanding?
Is this not what is there: For instance if projected weekly funding for development is reduced, then the community can decide what to do in terms of splitting the tax revenue by simple using parameter changes
Are we not trying to stop with the change of parameter all the time???
I’m copying the response to the other amendment prop here. I think the 50/50 split is one of the major issues, and let me explain the “hard coded” reasoning.
The hard coded nature of the 50/50 split is purely technical. The way that cosmos chains are upgraded are through software governance proposals with upgrade handlers. The problem is that the chain never implemented upgrade handlers in the past, and so there is no mechanism to add parameters for governance control.
There are 2 solutions. One is to create a new genesis where we add the parameters, and the other is to figure out how to re-implement upgrade handlers, given the fact they do not exist. The new genesis (like going from columbus-5 to columbus-6) is not possible at the moment either. We knew this several months ago when we exported the state. Terra classic is the largest cosmos chain and thus overflows the compression mechanism built into cosmos-sdk. No other chain has grown this large, so no one has yet run into this problem, except for us. We are looking at ways to move to a streaming model in order to overcome this, but it will take time.
The other solution is to figure out how to implement upgrade handlers. This is our current approach, and as you can see in the L1 task force milestones, one of our first priorities. We are making progress on the upgrade handlers, but it seems it might require rebuilding the version history, i.e. building the module versions from the start of columbus-5, and implementing handlers for every upgrade since then, which means we need to go back to 2021 and map out every upgrade, and every block height that it happened.
Needless to say, once we get the upgrade handlers working, we can finally add a parameter to control the split in the burn tax.
So then back to the hard code. If the community decides that we need to change the seigniorage to resume binance burns, and the upgrade handlers still do not work at that time, we will need to hard code. If we can figure out the handlers, we can parameterize it. Given the discussion around this, I am very much praying we get the handlers working soon.
Mmm not quit, the distribution happens strictly as defined in the percentage split, but only the CP has a $ CAP limit.
Example:
Assume Sun 00:00 (18th) → Sat 23:59 (24th) the on-chain volume was 140B(ish) LUNC
Applying the current TAX of 0.2% yields 280M LUNC
Assume a hypothetical 40/60 (CP/BURN) split applied by the AnteHandler
Over that week:
BURN = 280M * 0.6 = 168M LUNC (Definitely going to the burn address)
CP is entitled to 280M*0.4 = 112M LUNC but whether all will make it into the CP depends on the $ spot price of LUNC on Sunday @00:00 @GhostyRex is right the CAP parameter will need to be queried throughout the week in order to check if (SPOT * CURRENT_TAX_VOLUME * 0.4) < CAP then
SEND_TO_CP
else
SEND_TO_BURN
endif
*** So if the total $ value of that 112M destined for the CP is valued under the weekly $ CAP by Saturday 23:59 it means our CP is on LUNC $ deficit for that week
Then in the above pseudo-code the CAP function will always push LUNC to the “else” statement (SEND_TO_BURN) until next Sunday 00:00, where the system resets and a new LUNC coin SPOT price is taken to be used for forward projection
Yes! It’s called conditional checking and it’s a de-facto process in every programming language.
Please see the details in reference to the weekly funding and how it’s derived, which we still haven’t reached a decision there:
While miners receive 80% of a block reward, 20% is given to the “Zcash development fund”: 8% to Zcash Open Major Grants, 7% to Electric Coin Co., and 5% to The Zcash Foundation.
80% should go to stakers (Oracle Pool) and 20% should go to developers.
But considering we need burns, the following ratio makes more sense:
50% for Burns
30% to Oracle Pool for staking
20% to Community Pool for devs
This, in my opinion, is a more fairer distribution model that aligns the larger community.
@ek826 wouldn’t it be more prudent not to rush this? It’s an important issue, and one that should be handled with care. The technical limitations underpinning the entire problem makes this look like a solid brick wall… bashing our heads into it to brute-force a solution is probably the last thing anyone needs.
I think you yourself mentioned this is a discussion that will probably last a couple of weeks at least… I’m still firmly of the belief that we ought to handle important decisions like these with the utmost care - this isn’t a simple param change that can be undone with a flick of a wrist. Perhaps this should be its own discussion on Agora - would you consider putting up a thread so the community can weigh in on the issue?
Regardless, thanks for all the hard work that you and the other L1 devs are doing.
Lol…I know what conditional statements are. My problem is, do we want constant parameter interaction?? Is this not something we ought to limit?? The reason why I hate too many proposals is because of the constant changes. I know things change but man, learn to live with the risk and adapt. Not changing all the time. See the mess we did with the tax and we are still trying to mess with it. So bad for me.
Sounds like we are at a technical d*4d end in terms of being able to expose a new API endpoint and those parameters required by AnteHandler in the context of this proposal.
What is your take @ek826 on the use of a weekly $ CAP of the LUNC flowing into the CP based on our projected development funding so we optimize our CP holding towards both DEV/BURN? That should make the 50/50 split point mute as the system will tend to normalize once the CAP is met…
(it’s the part here, please skip to the line in bold in it)
or this (Proposed Changes) section if it helps you save reading time:
If we are to use a 50/50 split it goes a long way in being able to control our finances (what goes into the CP) better and there is a way for doing so, so why not? We get the dev funding we need and make sure any overflow goes towards the BURN effort…also is compatible with the BURN effort should someone in the future choose to increase the tax rate (the CP will fill up faster up to its’ CAP and the rest goes for burning again)
@ek826 Thanks for the explanation. Binance I think suggested using a burn wallet address for their burn contribution. Based on the complexities involved with parameterization and @RabbiJebediah suggestion to avoid rushing to resolve it , would it make sense to provide a band aid fix by:
providing a “voluntary burn wallet address” for cex,etc?
Re-minting (although a taboo term in the LUnc community) the 0.2% ,based on proposal #111111?
I think fulfilling Binances request before March is a major priority. I would accept a 50/50 hard coded temporarily, as Ed has clearly committed in writing to changing this as soon as the solution is available.
Ending minting, the Binance whitelist and a temporary funding solution (50/50) until we get the parameterised solution for the burn tax split I am for this. We need to end minting asap.
In hindsight, more clear communication on this matter from the beginning would have been very helpful. I believe we should wait and see how January goes with progress towards a solution and take a decision. I do have confidence in Ed and the L1 team, especially after receiving the latest reassurance any hard code, if needed, will only be temporary. Thank you.
This will be a repeal of proposal #11111. Every time we mess with burning we have a price implosion.
With this hard-coding ;
What will happen to burning if Binance further reduce/stop burning?How long would it take to reverse this hard coding?
[
This is very important and in fact, both solutions will take time and there is no guarantee if the second option will work.
Does this mean there is a another way to resume binance burn without deprecating Seigniorage?
i.e. “the use of a voluntary burn address” . Please put this to rest that all though there will be re-rninting using this method that it is a zero effect on the number of coins that should be burn.
Can you explain explicitly to the community what this really mean?
Ed, we burned <1% all time. We need real utility. Funding or working with Faffy and Duncan projects, activated Market Market Module with upper limit for ustc burns.
It’s an important issue, and one that should be handled with care. The technical limitations underpinning the entire problem makes this look like a solid brick wall… bashing our heads into it to brute-force a solution is probably the last thing anyone needs.
