“The on-chain transaction is taxed at a rate of 0.2% of the total amount. Instead of sending it all to the burn wallet, the tax is immediately split 50/50 and half is sent to the burn wallet, and half is sent immediately to the community pool.”
This is a direct quote from the proposal. It is clearly 50/50 for on-chain burns. This is too much. It’s also irreversible. 90/10 is much better with another proposal to increase on-chain tax to 1.2%. It would bring plenty of funds for the community pool. The push to constantly sabotage the burn movement has almost caused us to be dropped by Binance, has resulted in negative price movement, loss of focus on reducing the total supply, division and disregarding the voice of the community.
S[quote=“ek826, post:1, topic:49249, full:true”] Summary
Every epoch (approximately 7 days), the treasury module records the total supply of LUNC and subtracts that from the previous supply of LUNC 7 days ago. This is the number of LUNC burned within that week. This module was originally purposed around the market swaps (burning LUNC < > minting USTC, and minting LUNC < > burning USTC), and a portion of the burned LUNC is re-minted at the end of the epoch as seigniorage which is sent to the community pool. Community pool funds must be voted on by governance for distribution. The seigniorage is currently set to 10%.
There are many factors that affect the total supply of tokens in the system. There is the on-chain tax (0.2%), there are token inflation parameters (currently 0%), seigniorage (10%), market swaps (disabled for LUNC/USTC, enabled for USTC/Other stables 0.35% tobin tax), pre-determined vesting schedules, and there are voluntary burns, like the one Binance and other members/validators have been generously contributing.
Efforts by the community utilize the RewardPolicy parameter change in order to capitalize the chain and fund the community pool. In consultation with members of the community and Binance, it is clear that the co-mingling of voluntary burns with the seigniorage remint policy is confusing at best, and undesirable for others.
This is a signaling proposal that seeks to deprecate the use of RewardPolicy for the purposes of funding the community pool. It is proposed that core code changes are implemented to the burn antehandler to achieve the same effect as seigniorage RewardPolicy, but would directly be coded in the on-chain burn tax.
For example, in the current implementation, an on-chain transaction is taxed at a rate of 0.2% of the total amount. This tax is immediately sent to the burn wallet. At the end of the epoch (7 days), the amount re-minted (which includes the on-chain tax, voluntary burns, etc.) is calculated by the reward policy, and that percent is sent to the community pool.
In the new proposed model, the RewardPolicy should be set to 0.0 (no seigniorage remint). The on-chain transaction is taxed at a rate of 0.2% of the total amount. Instead of sending it all to the burn wallet, the tax is immediately split 50/50 and half is sent to the burn wallet, and half is sent immediately to the community pool. Thus, the only amount contributed to the community pool is via the on-chain tax and there is no minting happening at the end of the epoch. The 50/50 split is currently proposed (as I believe it is consistent in spirit to #5234, #10983, and #11111 see below), and would be hard coded into the burn antehandler. It could not be changed by parameterization (the overall tax rate of 0.2% is still a parameter change). The manual/voluntary burns remain “untouched”.
Note about passed proposal #5234
This was the governance proposal that first introduced the RewardPolicy upgrade to 10%. As shown in the first figure, this proposal reminted approximately 190M in a week, given the inclusion of the Binance burn. Without the Binance burn, this would have been reduced to 65M in a week.
Note about passed proposal #10983
Given the passing of this proposal, the RewardPolicy was adjusted to 50%, and this is where it currently is now. As shown above, the 50% split re-minted approximately 200M in a week, without Binance burns. Whether or not this was intentional by the proposer, this amount is approximately equal to the 10% RewardPolicy with Binance burns.
Note about passed proposal #11111
A new proposal repeals 10983, and brings back the RewardPolicy to 10%. The amount of weekly community pool contributions would be back to the same amount only if Binance continues to burn.
Parameter justification in this proposal
This proposal 50/50 split maintains the same level of contribution to the community pool as (5234, 11111 (if calculated using Binance burn contributions)), and (10983, calculated without Binance burn contributions) while keeping manual/voluntary burns out of the equation - in the range of 200M to 300M depending on volume. In essence, we believe this governance proposal maintains the spirit of all three passed proposals.
By voting YES, you agree that the burn mechanism should be refactored in this way. There will be at least 2 more governance proposals that follow, one to set the RewardPolicy to 0.0, and another to review the code, and accept the implementation on the blockchain. Subsequent parameter proposals that attempt to adjust the RewardPolicy greater than 0 should be voted No with Veto without proper justification.
By voting NO, you are indicating that the current mechanisms of the burn antehandler and seigniorage RewardPolicy are acceptable as currently implemented.
For this Agora post, we would appreciate any comments or suggestions. If you could please justify suggested changes with data/models, that would be particularly impactful. Please note that this code adjustment would be scheduled in the next release, and thus will not likely go to vote for at least another several weeks. Special thanks for the discussion with LuncLive.org.
[/quote]
No edit allowed…
Stealers everywhere
Simple1, dont burn go mint pool all for tax save stakers
Simple2, only burn all tax for save lunc and ustc tax to ustc
simple3, tr, or nev teams works only donate? Decentealize system
“The on-chain transaction is taxed at a rate of 0.2% of the total amount. Instead of sending it all to the burn wallet, the tax is immediately split 50/50 and half is sent to the burn wallet, and half is sent immediately to the community pool.”
Directly from proposal. I’ve read the proposal hoirs ago so I don’t know what was written meantime
@ek826 will the on-chain tax parameter be set as part of this proposal or the plan is to be transparent to whichever value is/was set by the system at the time?
In details:
There is a proposal under discussion here to raise the on-chain tax to 1.2%. Will the AnteHandler work overwrite the outcome of this proposal and reset the tax rate should it were to pass first?
Hey guys. Thank you Ed for the proposal. I will support it. 50/50 rule is getting an amazing amount of air time in this thread. Personally I am not sure so I won’t offer any view on it. I did want to point out the extraordinary number of people who have signed up to agora hours ago to now comment on the 50/50 tax split in this thread. I count at least 7 so far.
Totally true with your statement that Binance was supposed to be contacted and before any implementation of 10983 we were supposed to have binance feedback which never happened. This was a big gap in trust
[quote=“ek826”]
This module was originally purposed around the market swaps (burning LUNC < > minting USTC, and minting LUNC < > burning USTC), and a portion of the burned LUNC is re-minted at the end of the epoch as seigniorage which is sent to the community pool. Community pool funds must be voted on by governance for distribution. The seigniorage is currently set to 10%.
There are many factors that affect the total supply of tokens in the system. There is the on-chain tax (0.2%), there are token inflation parameters (currently 0%), seigniorage (10%), market swaps (disabled for LUNC/USTC, enabled for USTC/Other stables 0.35% tobin tax), pre-determined vesting schedules, and there are voluntary burns, like the one Binance and other members/validators have been generously contributing.
By voting YES, you agree that the burn mechanism should be refactored in this way. There will be at least 2 more governance proposals that follow, one to set the RewardPolicy to 0.0, and another to review the code, and accept the implementation on the blockchain. Subsequent parameter proposals that attempt to adjust the RewardPolicy greater than 0 should be voted No with Veto without proper justification.
By voting NO, you are indicating that the current mechanisms of the burn antehandler and seigniorage RewardPolicy are acceptable as currently implemented.[/quote]
explains everything. A different method is applied for reprinting. reprint if a new offer comes in = lunc(0.2/50%)=0.1+ustc(0.35/50%)=0.17.5 tax fee
Tax 0.1+0.17,5 go pool
Tax 0.1+0.17,5 burn wallet
%50 - %50 no with weto
Go all burn or all pool really scams
NO NO NO NO.
We need immediately stop any REMINT, burn tax is burn tax, we need find fund for developer in another way, aks “DEVELOPER” to make a DAPP like any other business man investing time and or money by making it and than take the reward from it. We community do not need any seigniorage reward policy.
I just want know one things.
Who ask anyone, to make something for free ?
And who ask them, after you did it for free, you will be paid 10 time more.
I’d like to be part of this circle, can I ?
I will make a proposal on agora in the next 10 minute stay tuned.
I agree with this proposal. Best compromise.
Maybe we could think about a yearly burn on community pool to prevent it to overflow and keep it balanced?
This way if community pool is used properly, and a lot of development is done, the leftover lunc is small in community pool. Causing a small burn.
If little development is done, and leftover lunc is a lot in community pool, a big burn takes place.
My idea is to take the same percentage of what the leftover is of the total community pool, and burn that percentage of the leftover.
For instance:
1b lunc goes in community pool in 2023, 900m goes into development and 100m is leftover at the end of 2023. This is 10% of total of 2023. So 10% of 100m = 10m will be burned.
Or
1b lunc goes in community pool in 2023, 100m goes into development and 900m is leftover at the end of 2023. This is 90% of total of 2023. So 90% of 900m = 810m will be burned.
This part is a bit worrying. Is there some specific (programming) reason to make this hardcoded? As you point out, if this goes through it won’t be changeable through future parameter proposals. Regardless of the potential need for such a change, anything that removes the community’s ability to directly influence the chain through governance is a step in the wrong direction IMHO.
@ek826
Reading through the proposal (and some insightful comments made by various community members) I understand we are trying to address two major challenges:
We need to stop using third-party burn initiatives for CP funding purposes (that also includes the re-mint function)
We need to find a stable funding source for our CP in order to continue supporting all our important L1/L2 etc. development initiatives
The first one is satisfied by the piece of work outlined in this proposal where we deprecate the Seigniorage Reward Policy and refactor the AnteHandler to make sure ONLY (a portion of the) on-chain taxes contribute to the CP funding effort. Also, reading through the comments sounds like the majority of members are on board with this action.
The second point appears to present the main point of friction which mainly stems from two equally important actions that need to be balanced to make the best use of our chain and ensure our future success. Those are:
Ensure that we have the available funds in the CP for (at least) two major threads of development to take place every quarter in parallel
The CP funding is not such that becomes detrimental to our over-supply reduction effort (always talking in the context of the on-chain tax burn portion)
Therefore my take on all previous community member comments is NOT that we shouldn’t do the 50/50 split out of the on-chain tax proposed where half is sent to burn while the remaining is to the CP (without re-mint); but HOW do we balance the two so we get the best result for both.
To that end, I suggest the following approach/solution/changes:
(I am not sure how difficult it is to implement, so please let me know should you think this is technically unfeasible)
Requirement (open to adjustment if needed to):
We need at least the equivalent of $300K in local tokens in our CP every quarter (3 Months) in order to be able to support two major development projects every quarter (be that L1 or a new CEX for those of you following Agora closely)
We need the funding towards the CP stop once a certain weekly target is met and the remaining proceeds are directed to the BURN address instead
Specification:
There are 4.34524 weeks in a month, so if we need to fund (as per requirement) the CP with $300K per quarter that translates to $100K per month, and that in turn translates to $100K/4.34524 = $23014 per week (rounded up).
Now consider the following distribution function -
Every Sunday 00:00 the function calculates the number of LUNC it needs to collect in the coming week for CP funding purposes (a.k.a to reach $23.014K) using the LUNC spot price (for this example let’s assume that’s $0.00015). Based on the values so far that is 23014/0.00015 = 153426666 LUNC (rounder up).
The (max target) LUNC value calculated above is fed into the AnteHandler tax split function and becomes the weekly collection ceiling. That means, the AnteHandler will continue splitting the allocated on-chain tax 50/50 until the ceiling is met, from there on all tax proceeds that were meant for the CP are redirected to the burn address instead. If the ceiling is not met then the 50/50 split carries on. Next week the cycle starts again with a new max-target/ceiling calculation in place.
To accustom to fluctuations in the local coin price over a week we can set the weekly collection target (in $) as the (calculated value)+10%(of calculated value) i.e. 23014+0.1*23014=$25315.4
Finally, the advantage of the above method allows us to maintain sufficient funding for the chain development and make sure we redirect all surplus into the BURN effort from the on-chain proceeds. Additionally allows us to tweak them indirectly using only the core tax rate value.
We now also have a request from Binance to create a second Burn wallet for their funds? Why cant this be used for Burns of other parties? This is a solution they requested so why not just extend this to others?
Why the need to centralise the Burn and Community Pool parameter and make it unchangeable by governance?
If we are sending 907 million LUNC to your project then why not spend a bit more and make these parameters 100% controllable by the community? This is a proper way to fix it.
Prof EdK208 has gone to substantial lengths in consolidating the spirit of props #5234#10983 and #11111 without compromising on future support through Binance voluntary . The refactoring of current burn antehandler so as to deprecate seigniorage RewardPolicy is a welcomed upgrade with a YES vote from me…
As a community, we do not accept this offer. If this offer passes, I will cancel my lunc investment. Binance and the community want a burn. You want to fill your own pocket. We’ve been taking 3 steps forward and 2 steps back for months. We cannot progress. In fact, we are always in the same place. Binance supports the community. Support the community with your offers, not yourself. Lunch is close. You reduced the Lunc burn by 0.2 and you mentioned that the volume will increase. You said that if the Lunc burn is 0.2, other exchanges will support us. What happened? They didn’t support it. Other exchanges will not support us unless Lunc gains trust.
Answers
Stop pressing Lunc supply. Limit the supply. No more supplying. We are in this state because of the supply
Bring back the 1.2 burn tax and apply it on the chain. Binance will support us. Binance wants it. Now understand.
Let the 2 tax (90%) burn (10%) be given to the community.
Do not make unnecessary demands from the community.
Do not upvote the community with these offers. Just close and build. After the accident, the investor suffered a lot and still continues to suffer. We started to gain trust with the burns. Don’t lose this trust
. The refactoring of current burn antehandler so as to deprecate seigniorage RewardPolicy is a welcomed upgrade with a YES vote from me…