Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

Instead of doing a 50-50 split between burn and CP, can’t we do a 80-20 split between oracle pool and CP, and keep the burns untouched?

The negative effects of this can easily be combated by raising gas fees as per your article: No Money, Mo’ Problems?. Introduction | by Edward Kim | Dec, 2022 | Medium

1 Like

We are currently allocating half of the delegator rewards to the community pool through the distribution parameters but that currently yields only circa 180M coins per month (last time I checked) which are not sufficient for a single round of development at the moment.
For example to fund the L1 proposal that was raised recently we would need a bit less than Cost Profile 2 (see below for details and references). That is $47.25k per month which translates to 47250/0.00014=337.5M LUNC with the current rounded spot price.

But you are right we need to reach a point where we don’t need to use tax to supplement our development cost and purely rely on block rewards via the built-in distribution module.



Not really! If you think about it the context that 11111 was raised was to reduce the re-mint in the TOTAL burn contributions made by the on-chain tax rate AND third-party contributions (CEX/Individuals) which last is the largest portion by far. So it was unfair to those third parties and the BURN effort.
As a matter of fact, using ANY seigniorage reward policy value (even that set by 11111) is unfair to those third parties contributing to the burn effort since we re-mint their funds for our development purposes.


This proposal applies the 50/50 split ONLY on the on-chain taxed transaction and that is direct without re-mint. So the dev funding falls on us alone this time around. That also means, based on this proposal all Binance, other CEX, and individual burns will happen 100% without re-mint.



That implies that we will not be doing any burns out of our on-chain taxes and we will rely purely on the burns made by third-parties. Don’t forget they did start burning because we did first!

@ek826 please consider these two points. Because it is simple and easy to implement. Strange why are you not considering these two simple points. Create a seperate burn wallet for CeX and whitelist from remint simple. And whitelist binance wallets also.

2 Likes

What did you mean by not touch the burn? Do you mean leave 100% of the on-chain for burn or are you saying something else?

check who voted in favor and redelegate

That was exactly the suggested change here:

,with more cost breakdown profiles here along with a tech diagram:

Pending review by @ek826



If your issue is with the re-mint, please read the reply above to Dannaval_Morrison. I think you’ll find that this proposal is compatible with your views.
If your issue is using part of the on-chain taxes for development purposes please continue reading here:
Where will we find the money to pay for development costs to maintain and improve the chain so that all those wonderful dApps everyone is talking about are able to use LUNC?
Getting the funds transferred to the CP from that infamous multi-sig wallet is years ahead of us.
Also, the idea of gettings the funds as a loan out of the Oracle Pool doesn’t sound like it sits right with validators and some delegators.
We cannot afford to stand still we need to run…

1 Like

Why not tax the stake rewards for funding? It’s time for community to sacrifice a bit. So far most of the funding came from third parties through deceptive tactics and we all see the results.

Can we do a vote on that split?

I believe 70:30 (70% burned and 30% for community pool) would be ok. It is safe to assume that with upgrades there will be more and more dapps available on this chain and volume will pick up. So community pool will grow enough to cover development. This way there will be also some burning effect from tax… otherwise suppply will never come down.

2 Likes

We are already redirecting 50% of the rewards to the community pool.

With our current on-chain volume the 50/50 will hardly cover the cost of one equivalent L1 dev stream which is needed in order to attract the dApps to begin with in order for the volume to pick up.
At the same time if volume pickup we’ll be sending more funds to the community pool than those required for development purposes wasting funds that could contribute to the burn effort (via on-chain taxation). That is why I’m suggesting we keep the 50/50 and put a ceiling on the funds we want the AnteHandler to send to the community pool based on a pre-defined projected $ cost of development:

  • When volume is low we get 50/50 all the way BURN/CP
  • When volume is high we get a random split (favoring the burn effort) since the funds going to the CP will reach the pre-approved ceiling and their overflow will be redirected to burning. The higher the on-chain volume, the “effective” BURN/CP ratio will tend to normalize to a value where: BURN > 50 and CP < 50

Agree.

Here is the issue. I think this proposal came out before binance announcement. No one knew that Binance would reduce their burn contribution by 50%. Hence, this was not factored into the calculation that would take care of what #11111 wanted. This 50/50 means that less coins would be burned. While I fully agree that devs development falls squarely on our shoulders we cannot totally rely on the 0.2% tax revenue to fully fund developers and take part in some burning in this initial stage of chain development.

  1. Volume may fall and hence price of coin will be impacted
  2. Circulating supply may increase ,again price will fall
  3. Unforseen issues may arise, that requires more funding ex. TFL may stop their free infrastructure support.
  4. Also if binance stops burning what will happen to burn?

I have suggested another way to fund the CP from a resource that we own.

Your thoughts would be welcomed.

The Oracle Pool rewards are not going to the community pool.

  • The Oracle Pool currently has 265,551,784,524 LUNC
  • At Current Market Value of $0.000148, that equals $39,301,664
  • If 20% of this is allocated to Dev funding, that would equal $7,860,332
  • This would generate 166 months of cash for the Joint L1 task force @ $47.25k per month

In this scenario, the burns would not have to be split up and all of the burn tax would be used in burning.

1 Like

50% of the rewards go through the distribution community_tax parameter to the community pool.

Both you and @Dannavan_Morrison did raise the same approach(ish) for dev purposes. To put it plainly the suggestion is a loan from the Oracle Pool for dev purposes. Given that the oracle pool is not replenished because swaps are disabled and it feeds the validator/delegator rewards…am not sure many validators will go for it. It looks like the chain’s long-term lifeline, in my eyes at least…
Nevertheless is one more idea to be considered.

We can’t touch the OP like that. First of that, that’s where rewards for staking come from. It’s not like it’s an orphan fund which can just be dipped into.

Secondly, there is a technical issue with accessing the OP. Ed is not explaining it cause to explain it will take an hour.

But the basic lowdown is that OP CANNOT be touched without figuring out all the things it will break if we do that and the security issues that come with it. Anything that becomes accessible is also vulnerable to attacks.

It’s not a small fund and it’s not an useless fund. So we have to be very cautious about making ideas with OP.

My suggestion would be not to think about the OP for the timebeing unless how it can be accessed can be figured out by the L1 team.

Validator/delegator rewards can be increased by increasing gas fee - this can be used to bridge the funding gap for devs.

@dfunk That’s actually a VERY GOOD idea.

Increase the gas fees and maybe a bit more the contribution to the community pool in the rewards structure (community_tax). In practice is like we delegators accept to get fewer rewards from our staking so we can have more in the community pool for dev funding purposes. It can be even done without any coding, it’s a parameter change. The only handraulic thing required is liaising with the validators to change the fees entry; maybe through a text proposal to make it official!
I’m personally willing to do that sacrifice…

I would still like to see that terrible Seigniorage Rewards Policy be set back to 0 and stop affecting ALL burns and our relations with all those third parties supporting our chain.

4 Likes

Let me illustrate the benefits of this with some live data.

  • 111,804,563 LUNC was burned this week
  • Considering 10% was re-minted as per the Seigniorage Reward Policy, the amount contributed to the CP by the Seigniorage Reward Policy would be 11.1M LUNC

On the other hand:

The Seigniorage Reward Policy is pretty redundant as a source of funding and should be deprecated immediately (set back to 0) as it is causing more harm than benefit.

The Refactoring of the Burn Ante Handler isn’t needed either as the shortfall of 11.1M LUNC caused by deprecating the Seigniorage Reward Policy can easily be fulfilled by increasing gas fee (which will also benefit validators and delegators).

Any refactoring of the Burn Ante Handler to split the burn tax should be done with the Oracle Pool and not community pool so as to create maximum benefit to the overall community.

3 Likes

My problem is that if I send the tokens to the burn they are not redirected anywhere else

1 Like

You’re set. All suggestions discussed here work towards removing the remint option for third-party burns (that means CEXs and individuals)

@RabbiJebediah my old friend it is good to see you posting here, hopefully you had a blessed Hanukkah. What we should consider is that the Binance fee burns are ephemeral in nature. We should the set down more long term plans to maintain the viability of the CP irregardless as whether they burn or not. It would appear that you & I largely are in agreement on this idea (that it is good but making it governance controlled down the line is better) though I’m sure we could always find nuance to bicker over my Semitic friend.

We can also increase the per txn gas rate to say a minimum of 250 LUNC or 5 USTC (just as an example) if we find that we ultimately need to further supplement community pool inflows in addition to Mr. @ek826 proposed revision. The other benefit is that we can also use that gas hike to supplement staking APR as well, which would allow us to potentially reduce daily drawdown of the Oracle Pool, buying us further time to come up with a more long term strategy to sustaining the OP.

1 Like

Everyone, don’t give a shit to this man. He brought proposal 10983 and this is happening. Binance reduced burning support from 100% to 50% and now again he is giving advice. Even in his Agora post if you will read proposal - 10983 he challenged binance and binance showed us what binance can do. Even binance mentioned his proposal number SO PLEASE STAY AWAY FROM THIS MAN @CosmosCapybara and his ideas. His intention is to destroy lunc. Lunc is community driven. But because of his proposal binance decreased burning support. If I am saying wrong. You think why binance decreased burning support ? Everyone is taking this for granted. But it is major setback for lunc.

And thanks for Ed. Because of Ed binance still burning 50% of lunc spot and margin trading fees.

7 Likes