Amendment to the "Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy" Proposal

[Bilbo]

This is an alternative to the signalling proposal “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” by Edward Kim and the “Joint L1 Task Force” found here: Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

Motivation for this amendment proposal:

• Proposal 11168 “Joint L1 Task Force” which seeks community spend of 908,000,000 LUNC is set to pass.
• Proposal 11168 appoints a group of developers committed to working on chain upgrades.
• Since LUNC Community is providing the funds, it gives the LUNC Stakers direct control over what the “Joint L1 Task Force” works on.
• Part of the “Joint L1 Task Force” is a provision to hard code a major change to the Burn Tax by sending 50% of the Burn Tax to the Community Pool.
• Due to the changes being hard coded and not exposed as a parameter, the above change could not be reversed or controlled by a governance vote.
• Any future changes to the Burn Tax would require a text proposal passed (minimum 1 week) plus a separate chain upgrade that every validator would have to update to (unknown timeframe weeks/months/???). This is an inefficient architectural decision in many ways.
• The above changes would also require developers cooperation and in an instance of lack of it, would not be enforceable and could create a severe centralisation risk for the community as developers could rent seek or raise prices for future Burn Taxes changes to levels that would extract significant value from the community pool by holding future changes to the Burn Tax hostage.

Conclusion: If passed as presented, the “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” proposal would have various negative effects:

• There would be no community control over the Burn Tax via the governance module.
• Any future changes to the Burn Tax would require Developer work that is paid out from an already strained community pool.
• On top of cost to the community, there would also be a time cost to making changes to the Burn Tax in the form of coordinating updates with all of the validators in the chain instead of changing a simple parameter via the governance module.
• This would put a timeframe for such changes and cost of it in control of the developers, control which could be adversarily used to extract value from the community.
• Information of timing of the Burn Tax changes would also be put in hands of the developers which could lead to market manipulation.
• The hard coded changes to the Burn Tax done by “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” would lower the burn from 0.2% to 0.1%, diminishing the impact of the burn even further.

Concerns:

• An element of politics inherently exists in the “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” proposal despite the claim that the team is focused on delivering L1 work requested by the Community. These politics should not be present in the proposal.
• Further decreasing the Burn rate is not in line with what the majority of the community wants, and risks our progress with the burn.
• Having the Burn Tax parameters be hard coded instead of exposed as parameters that can be changed via the governance module creates unnecessary architectural and maintenance complexity that isn’t needed, as well as community risk via centralization that could be used to exploit the community.

Proposed changes.

This amendment is focused to fix the highlighted issues with these goals in mind:

• Establish full community control over the Community Pool / Burn split through governance - completely removing the centralization risk to the community.
• Remove any and all political aspects out of the proposal (such as the current ongoing argument about the Community Pool / Burn split).

Proposed best solution and framework. These solutions are organized by preferred, best outcome for the community at the top. In case any single method is deemed impossible to implement by the community, the next best alternative is listed below it. And so on.

A. These changes address the goal of Full Community Control over the Burn AnteHandler parameters via the governance module.

1. Make the Burn AnteHandler parameters directly controllable via governance the same way other parameter changes already work.

Comments:

• This is a preferred method that prevents the re-mint process and keeps control over the taxation parameters in the hands of the community.

2. Abandon any changes to the Burn AnteHandler and achieve a tax-exempt status for Cex and Private Entity burns by setting up a second Burn Wallet.

Comments:

• This solution was proposed by Binance and is the second best solution. In this solution:
• The community still retains control over Taxation parameters.
• Funds burned by Binance and other Entities are not affected by the re-minting process. It ceases to be an issue.
• Seignorage (re-mint) only applies to the on-chain tax. With the most of the funds burned off-chain it will no longer be a major issue.

3. Abandon any changes to the Burn AnteHandler and come up with alternative solution to the Off-Chain Burns problem.

Comments:

• This solution is the same as above but with an alternative to setting up secondary Burn wallets. A possible solution was mentioned by Edward Kim so we’re leaving it here as a place holder that we can iterate on through further discussion as a community.

4. Abandon any changes to the Burn AnteHandler.

Comments:

• If no solution can be found to exempt Private burns from the re-mint process while keeping the Burn / Community Pool parameters in direct community control through governance parameter change proposals, do not make any changes to the Burn AnteHandler and leave it as is until a better solution is discovered.

B. These changes address the “Political” issues that currently exist with the “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” proposal.

1. Make the Burn AnteHandler a parameter directly controllable by governance without an initial value.

Comments:

• The mission of the “Joint L1 Task Force” is to provide solutions without political bias and let the Community decide on the solutions used. It is preferred to expose parameters for the Burn AnteHandler that can be changed via the governance module and let the LUNC Community come up with proposals as to what those parameters should be. Once this is voted on by the community, then the changes can go live without requiring any coordination from validators to upgrade their validator nodes.

2. Make the Burn AnteHandler a parameter directly controllable by governance and set a value that we currently have approved by governance vote: The 10% Community Pool Share.

Comments:

• The only community controlled parameter related to the community pool funding is the Rewards.Policy parameter. This was recently voted by proposal 11111 to be set at 10%. If any, this percentage should be chosen as a starting point. If the community wishes to change it, they shall do so through a separate governance vote.

3. Abandon any changes to the Burn AnteHandler.

Comments:

• Same as in previous analysis, this is the final preferred option which avoids alienating parts of the community and mitigates the risk of the creation of a “Joint L1 Task Force” becoming a political issue and dividing the community further.

Summary.

The process of funding the Community Pool that we have at the moment is not ideal and there is plenty of room for improvement.

The questions we need to ask ourselves though is:

• Is the proposal that the “Joint L1 Task Force” has put forth what the chain most needs right now?
• Is it an improvement for the community to lose control over a crucial function for the chain and to open itself up to more risk of exploitation from developers who seek to extract value from the community pool?
• Is it an improvement to increase the time and cost of any future changes we would like to make by requiring validators to upgrade their nodes every single time we want to make a change to the Burn Tax / Community Pool split, when the functionality so clearly should be exposed as parameters the governance module can change?
• Is it an improvement to add a risk of changes not being implemented at all, if the developer team refuses to do them or the community can’t afford to pay for the work to be done?

We applaud and support the spirit of nominating a “Joint L1 Task Force” who will work on chain upgrades on behalf of the LUNC Community. However it does not bode well for this concept if from the very beginning the team which is supposed to deliver perfect solutions for the chain and get to the core of the problems (and is paid handsomely by the LUNC community to do so), is offering flawed solutions which create more problems then they solve.

To be frank, it is alarming that in the very first proposal the “Joint L1 Task Force” has given the community, they recommend hard coding of values that should be exposed as parameters as a solution when the community is poised to pay significant prices for their work. We are paying for senior developers, and we expect senior developer level work.

Hard coding of parameters and taking shortcuts because it’s “easier” or “there’s less complexity” is not how the “Joint L1 Task Force” should function, and we certainly shouldn’t be paying the prices we are as a community for work that’s going to be cutting corners as the “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” proposal currently intends, especially when those cutting of corners are at the community’s expense in terms of cost, needless complexity, validator upgrade risk (and therefore risk to the chain), and a loss of the community’s decentralized control over the chain. The risk is far too high for very little gain for the community.

If you agree that we should build the “Joint L1 Task Force” with the aim of delivering perfect solutions without any political / tribal biases then please support this proposal.

How will this proposal be voted on?

1. We would prefer if the “Joint L1 Task Force” members took this common sense feedback onboard and amended their proposal of their own volition. We would also prefer they delay the vote on this particular issue until a solution is found, as that would show good faith towards the community on their part.
2. However, if the proposal of the Burn AnteHandler is voted on as they wrote it without these changes we’ve recommended here being put in place; then the alternatives outlined in this proposal needs to be voted on as well. As we mentioned before the LUNC Community has allocated 908,000,000 LUNC to this project which makes LUNC holders the project owners and directors. It is the community who instructs the “Joint L1 Task Force” Team how to proceed and what to work on since they are seeking community funds.
3. It is clear that the current approach the “Joint L1 Task Force” needs to undergo further iteration due to the issues we’ve outlined above, and we sincerely hope to see the “Joint L1 Task Force” work collaboratively with the community on their proposal to come to a solution that provides value to the community instead of trying to push their proposal as it currently exists through to a vote.

Signed by: Bilbo Baggins, Powvski, Solid Snake, Orka.

We would like to give a special Thanks to Solid Snake and Orka from Terra Allies for helping us on this proposal.

[JESUSisLORD]

Excellent proposal. At the very minimum the 50/50 hard code must be able to be changed. It is worth the extra work. It is absolutely inappropriate to pitch that proposal with a hard coded 50/50 and the suggestion any vote to change it should receive a NO WITH VETO, as stated in the proposal by Ed.

The community should have the say and the community is paying for the coding work. I support a 90/10 for the on-chain tax, but if they want to proceed with 50/50, at least allow it to be changed by parameter proposal. Great post and thank you. We need more community advocates as the developer’s have the power here.

[Mpowski]

I would ideally want the L1 Team and @ek826 to remove any suggestions of what the split should be and deliver a base on which the community can decide on it later. Just give us the mechanism to work with and let the community do the rest. L1 Coders should work for all of the community and have no biases. Suggesting a 50/50 split (or any other) tied up to the rest of the L1 work is like throwing more wood into the fire. This is exactly what we must learn to avoid.

[Tonu_Magi]

This prop is as long and politically motivated as Eds prop. Only difference is the one on top of the soap box.

Antehandler upgrade is removing the quick-fix of remint. The split of 50/50 or whatever it will end up to be, will be automated.
Seigniorage goes away.
Tax % will be governable.
Burnt coins will be exempt without the need of whitelisting (and giving unfair advantages to CEX-es, political much) a wallet and without the need for multiple “burn” wallets.

Issue is: Hardcoded split and what % is the split to be. Divided community with wildly differing knowledge gaps.
Sidenote:
Burning via tax is a gimmick as it currently stands with low volume. Increasing gas fees would make more sense than messing with the tax, but oh well.

Your own proposal is politically motivated as it cites 11.111 as the latest prop that passed.
Ignoring #5234 and 10983 that were also in this saga.

11,111 was mainly driven by fear of what Binance does and given the marketing via Influencers. 10983 was motivated due to lack of funds.
5234 was Akujiros fantasy about more volume.
Community is political. So are you and this prop.

[Mpowski]

The split of 50/50 they are offering ar the moment is fixed. Everyone has an opinion of what it should be thats why i think its best to take this out of the prop, build a mechanism that the community can control and let them figure out what the % should be separately.

The split will ot be automated. It will require chain upgrades to be ammended. This means coding. Coding means work. Works needs paid. On top of that there is time required for these changes to be made. This has nothing to do with being automated.

Seignorage is gone sure, but at what cost? New mechanism is outside of direct community control.

Tax will be governable? Not quite. Only the total amount of tax would be governable. How much of that goes to burn and cp effectively will not.

Creating a wallet that any private party wants to use to burn their coins seems a much simpler solution and does not affect governace in a negative way. It’s coding a new mechanism that requires more effort.

On your suggestion of increasing gas fees - Id need to see it to judge. Sounds good as a concept. No one seems to be working on it and its not part of the proposal im refrring to. If someone is working on it then it should be put up as an alternative or addition to the changes L1 team is to make. Otherwise there is nothing to talk about at this point.

Thats a good breakdown of props history, and I can nothing but agree with their characteristics. The one in force is still 11111 though - 10% cp fund, so i dont see why they wpuld increase the cp fund to 50% which was repealed earlier. Well, you could say we went back to Akujiros prop 5234 which is also correct. If thats what you mean this can be edited in for the sake of clarity. Stil IMO there should be no initial set of values in a prop by L1 devs. Just deliver the framework and let the stakers decide on the values later. If the values cant be controlled by governance directly - abandon this solution.

[GhostyRex]

Cut pay work out. We already have a team of L1 devs that are to be paid a salary. Isn’t that what the L1 joint task force proposal is for. So we don’t need to pay anyone to update any code. They are already there so this narrative of paying devs to do the work is not straight. They are now under a salary mechanism. Your proposal even says it above. We have paid you so the community should decide, isn’t that what is said in your proposal. My problem is, rather than the community deciding, they should ask, why the 50/50 split. Maybe there is a good explanation. If there isn’t, then we work from there and come up with a good split as you are saying but first, it is good to know why 50/50 split suggestion in the first place.

[ek826]

Thanks for taking the time to voice your concerns. Your passion on this matter, and actions to address them are commendable. Let me preface this by saying the 50/50 split was something that seemed to be a compromise that kept in the spirit of the previous passed proposals… I believe I can say this as I consulted them all during this process.

That being said, I am 100% for a parameterized split governance mechanism.

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.

[JESUSisLORD]

Thank you Ed for your detailed response. I am glad to hear you are for a parameterised split governance mechanism, and that you have been working on solutions for this.

If I understand correctly if you can get the solution to make the on-chain split parameterised and implemented before the march Binance burn, we can proceed with that option. If you can’t get the parameterised split by then we need to go with the hard code until later, when the fix will come.

I support this and thank you for considering our views. That way the community can vote and decide on what ratio they prefer, which can be adjustable if the tax rate changes. Thank you Ed.

[dfunk]

@ek826

Needless to say, once we get the upgrade handlers working, we can finally add a parameter to control the split in the burn tax.

Instead of a 2-way split between burns and community pool, can we do a 3-way split instead between burns, community pool & oracle pool?

The Oracle Pool funds are slowly depleting and this will be needed to align interest from stakers.

[JESUSisLORD]

That is a good idea. Staking is one of the primary draws for LUNC and we should have a good way of topping it up.

[JungleBoy]

Thanks Ed. My only suggestion at the moment, aside from all the technical recommendations that keep flying around, is this. If you can maintain a clear conscience as your responsibility in this Blockchain Rises, that will be the most important part in my opinion.

Not saying you don’t already realize this on some level, but as influence and fame or riches increase, so also does compromise. I hope for you all the best in this mind battle!

…and on that note, also a reminder to everyone that reads this…Including myself!

[NN78]

@ek826

we need

What about Terrarebels 2022 roadmap? TR said you and Zaradar wrote this.

[Dannavan_Morrison]

@ek826

That being said, I am 100% for a parameterized split governance mechanism.

Very powerful statement!

Binance statement:

“To create a new burn wallet that Binance can send the LUNC spot and margin trading fees to that does not allow re-minting of the burn amount.” This has nothing to do with on chain 0.2%

This burn wallet could also be used for the other voluntary contributors.

The parameterized on chain solution that we presently employ will then effectively not re-mint new coins . It’s just taking back what should be sent to CP in the first place. Is this correct. If so why do need to do any hard-coding ? Is there something else that i am missing?

[RabbiJebediah]

The devil is always in the details…

@Bilbo

Any future changes to the Burn Tax would require a text proposal passed (minimum 1 week) plus a separate chain upgrade that every validator would have to update to (unknown timeframe weeks/months/???).

This right here is reason enough to stop and seriously rethink even attempting to hardcode the change. Having to negotiate with validators in case we want to reverse/change these hardcoded parameters is something that should give us pause. Even if all the validators agreed to play this game it’s still grossly inefficient and a massive waste of time.

@Bilbo

The above changes would also require developers cooperation and in an instance of lack of it, would not be enforceable and could create a severe centralisation risk for the community as developers could rent seek or raise prices for future Burn Taxes changes to levels that would extract significant value from the community pool by holding future changes to the Burn Tax hostage.

Another nail in the coffin of any pro-hardcode argument(s).

@Bilbo

Having the Burn Tax parameters be hard coded instead of exposed as parameters that can be changed via the governance module creates unnecessary architectural and maintenance complexity that isn’t needed, as well as community risk via centralization that could be used to exploit the community.

Well put, this is the gist of it.

@Bilbo

If no solution can be found to exempt Private burns from the re-mint process while keeping the Burn / Community Pool parameters in direct community control through governance parameter change proposals, do not make any changes to the Burn AnteHandler and leave it as is until a better solution is discovered.

This is probably preferable to rushing a hardcoded solution.

@Bilbo

Is it an improvement for the community to lose control over a crucial function for the chain and to open itself up to more risk of exploitation from developers who seek to extract value from the community pool?

No, most definitely not. Any loss of control the community suffers can have a lasting negative impact in the future. If anything, we should be looking for solutions that will further protect and strengthen the community’s ability to exert their decentralized will through governance… taking even a fraction of that control away is a direct violation of our “people’s coin” ethos, no matter how well-intentioned.

@Bilbo

Is it an improvement to add a risk of changes not being implemented at all, if the developer team refuses to do them or the community can’t afford to pay for the work to be done?

Another great point, and another “definitely not” answer to a rhetorical question that does a great job of illustrating the problem we’re facing. We have to keep in mind there’s a non-zero chance the community pool runs out of funds (or developers refuse to accept X money for Y work), which would leave us up shit creek without a paddle in case we must make changes to these variable settings.

@Bilbo

Hard coding of parameters and taking shortcuts because it’s “easier” or “there’s less complexity” is not how the “Joint L1 Task Force” should function, and we certainly shouldn’t be paying the prices we are as a community for work that’s going to be cutting corners as the “Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy” proposal currently intends, especially when those cutting of corners are at the community’s expense in terms of cost, needless complexity, validator upgrade risk (and therefore risk to the chain), and a loss of the community’s decentralized control over the chain.

You know, I was on the fence about this issue for a while (I understand Ed’s point of view and how much effort/time this change may take to parametrize), but after reading the above paragraph I can’t in good conscience accept a hardcoded solution to this problem. It simply carries too much risk and rests on that assumption that the general LUNC ecosystem will see smooth sailing in the future… and if life taught me anything, it’s that things rarely go as planned or the way we expect them to. Failing to plan is planning to fail, as they say.

@Bilbo

We would also prefer they delay the vote on this particular issue until a solution is found, as that would show good faith towards the community on their part.

Well put. I don’t think anyone would disagree with the above - it’s common sense at this point.

Shalom!

[rahul_kumar]

@ek826 3 way split is more suitable. Please have look into this

[Mpowski]

I just recieved an update that the parameters controlling the Community Pool / Burn split would be controllable by governance! Thats great news and many thanks to the L1 Task Force for this change and their work.

Some questions remain though:

Recently a proposal was passed to increase the gas fees by x5 in order to fund the community pool by an equivalent of the 0.1% of each transaction by @dfunk.

So as it stands at the moment we are funding the community pool via gas AND will be funding it via 50% of the burn tax also. This funds the CP by Double the amount originally requested by the L1 Task Force(if the calculations are correct). This comes at a cost of sacrificing 50% of the BURN TAX - yet again. So patern of smfunneling money to CP at the expense of Burning down the suplly remains.

This is an obvious issue and, if no changes are made to the antehandler proposal, myself and co-signers of this ammendment will counter-propose to preserve the BURN Tax as originally intended and fund the CP through gas fees exclusively.