thank you for the break down this is correct.
@Asobs yes, my mistake, rewardpolicy 1.0
@Ramrodthe1st yes, hard coded just means that it would have to be changed by text prop, and then changed in the code via the next upgrade.
@arunadaybasu yea, i think there is just a lot of confusion here.
@Dannavan_Morrison 1. yes, 2. yes, 3. yes, we can and i’m hoping that this prop simplifies all the moving parts. As for the oracle pool loan… maybe? It opens up another can of worms
@godoal the tax rate is an independent parameter change and could be set. the change of the split would have to be a text prop to be implemented in the next code release.
@Alessandro_Nardaggio there would be no re-mint in this proposal. but yes, if the consensus is not to utilize the burn tax for funding the community pool, we can explore other ways. one other way people have be talking about is block rewards via the gas fees.
@RabbiJebediah good question. There is a tricky thing here with the current upgrade handlers that we cannot introduce new parameters until we figure that out. If we can figure that out quickly, we can add this as gov parameter. This is one of the first things tasked to the L1 team – figure out upgrade handlers.
@Mpowski this request for the second burn wallet was my first brainstorm to binance about how to exclude their burn from the remint. Ultimately, this required the upgrade handlers as mentioned above to Rabbi, so we cannot do it in this way yet. I shared this new idea with binance, and they are good with this, but didn’t update their announcement to reflect the new plan. 50/50 split is not set, i assume this discussion will go on for weeks.
As for the gas fees, we would have to make a hard coded split there to a dev wallet or fund. If that is the preferred method, that can be explored too.
8 Likes