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.
- 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.
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.
- Make the Burn AnteHandler parameters directly controllable via governance the same way other parameter changes already work.
- This is a preferred method that prevents the re-mint process and keeps control over the taxation parameters in the hands of the community.
- 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.
- 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.
- Abandon any changes to the Burn AnteHandler and come up with alternative solution to the Off-Chain Burns problem.
- 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.
- Abandon any changes to the Burn AnteHandler.
- 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.
- Make the Burn AnteHandler a parameter directly controllable by governance without an initial value.
- 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.
- 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.
- 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.
- Abandon any changes to the Burn AnteHandler.
- 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.
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?
- 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.
- 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.
- 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.