Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

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.

1 Like

The problem with decentralisation is that it only works to an extent. The LUNC community have been looking for a leader or leadership team continually since the crash, like a man looking for something to hold onto when floating in the sea. First it was Terra Rebels. The community was united behind the vote for staking, 1.2% tax and the proposal which signalled for exchanges to adopt the 1.2% off-chain, all unanimous votes. The hype and burns were there and the price reflected this with a 600% move. The community naturally looked to the people with the greatest expertise when making decisions, that is developers. They became the de-facto leaders. However, just because someone can code does not make them a good leader or that their vision for LUNC is correct. They are technical professionals, not necessarily quality leaders.

For example, from long ago Ed always spoke that he didn’t believe in the 1.2% tax, same with Zaradar and others. It was given 3 weeks before Ed wrote the Medium article supporting the change to 0.2%. He also supported and was instrumental in the minting of LUNC. Both of these were extremely poor decisions. Only now when Binance threatens to pull all burn support is it revealed that we could have had code to never allow minting in the first place.

Developers are concerned about getting paid and continuing to get paid. A worker is worthy of their wages. But the developers should serve the community, not the community serving them. They should be advocating for the will of the community, not theirs. Hence their proposals will always put the greatest chance of getting paid. The 50/50 proposed here is really wrong, but whether what we say will have any influence on it remains to be seen. Developers are the de-facto leaders of this chain, that is obvious. Just remember they have often made poor strategic and governance decisions in the past, and do need to be held to account.

6 Likes

The conflict if I may add is that cz believes in burning and based on your article if @ek826 did not believe in the 1.2% burning, he shouldn’t be advising @ClassyCrypto on his1.2% proposal,unless his views have changed.

You are 100% correct. I asked that question a long time ago and was informed that it could not be done any other way based on how the coding was written. But now it seems that it’s a no brainer.

We need a team to represent us retailers. Decentralization is not working for us.

4 Likes

@ek826 and the L1 Joint Task Force Team authors. Please take time to browse through the ammendment proposal which I feel is necessary to implement to your proposal.

I tried to address the issues with your prop that were simply to painful to read - like centralising the control over the Burn Paramater and Political-like narrative around the Burn/Pool split.

Everyone in the LUNC Community has expectations of the L1 devs to fix the issues we have at their core and in my opinion (and many in the community) this cannot be went ahead with as is.

4 Likes

It is hard for people to wrap their heads around the fact that the chain is owned by the community and we are all responsible for all decisions around it. That also means we need to be actively engaged with what is going on.

As you said, it feels like people want to offload that responsibility to another TFL and DK and retain the right to point their finger at them when something goes wrong…it’s easier after all to blame others for mistakes than oneself.

2 Likes

So what is the amount of $ do you (ALL) think we should collect in our wallet (Community Pool) via on-chain tax for development purposes?
NOTE: The money in the community pool is not automatically distributed to the developers, whoever needs dev funding will still need to raise a proposal and we’ll have to vote on whether we release the funds to them or not

Cost Profile 1

Based on the proposal cost breakdown here and here (two major dev projects running in parallel).
The cumulative cost comes down to:
$141.75k + $125k = $266.75k over a period of 3 months,
or $266.75k / 3 = $89k per month
There are 4.34524 weeks in a month, hence that last value gives us the weekly cost for such a development schedule described above: $89k / 4.34525 = $20k per week

Question 1: Do you think $89k per month is too much?

Cost Profile 2

We start small so we are lean in terms of our community pool management.
For example, we make sure we can support at least L1 development cost and we add a bit of overhead, like a quarter of the L1 dev cost, which will build up over time (1 year) to allow us to support funding of another large development project. Using the L1 development cost values again here we get:
$141.75k + $141.75k/4 = $177.1875k over a period of 3 months,
or $177.1875k / 3 = $59k per month
or 59k / 4.34525 = $14k per week (there are 4.34524 weeks in a month)

Question 2: Do you think $59k per month is too much?

Why set a limit?

So as we don’t populate our community pool with stagnant coins which could otherwise contribute to the BURN effort. We collect and keep what we need to help develop the chain and burn the overflow and that is over and above our usual burn contributions as outlined on the technical design diagram (Proposed Changes) below:

P.S: I have rounded up/down here and there to get easy-to-read numbers

1 Like

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.

1 Like

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

1 Like

@Mpowski

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?

  1. If the tax revenue is less than the required funding amount then all revenue frorm tax should go to the CP.

  2. 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.

2 Likes

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.

Agreed. Leave it as is for now… at least until a more opportune time comes.

Shalom! :pray:

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.

7 Likes

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:

You need to follow the threads to fully understand what we are talking about. You are veering of an a tangent

No one here has said that.

That’s what we said.

Not more than 20% for development. This is in line with other blockchains.

Here’s an excerpt from the Zcash wiki:

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? :man_shrugging: 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. :+1:

Shalom! :pray:

1 Like

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)

2 Likes