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.