Refactor Burn AnteHandler and deprecate Seigniorage Reward Policy

The 1.2% was reduced and justified for dapps. But no pivotal dapps appeared, we just greatly slowed the burning. I don’t know how you can budget 5 million dollars a year for dapps that don’t exist. That’s not a good way to do a budget.

Like I said before, if we increased the burn tax to 1.2%, and 90% was burned, 10% to community pool it would bring $1.46M per year at current price and current volume. This is enough for base L1 work. We need to focus on the basics first. Blockchain upgrades, parity with LUNA and good high quality consistent burning by us ON-CHAIN. The next step after this is to apply pressure on exchanges to adopt the 1.2% on buy/sells (or 0.6% buy 0.6% sell) off-chain.

Whitelist their internal wallets of the big exchanges so they aren’t hit by the tax for internal transfers, and do a big burn campaign both asking them and Binance to even increase their burns. By us having a good on-chain burn we have more credibility in asking the exchanges to burn. If we don’t even burn properly we can say nothing to them.

Burns bring hype, new investors and price momentum. It’s very easy for price to 3x (we recently went 6x). If price 3x we would be bringing in $4.3M in the community pool each year. If we went 6x to the recent high that’s $8.58 M per year (that’s at current volume 20 billion daily, it could be way higher). That’s a good amount for our needs right now the 90/10 split with 1.2% for CP funding.

We also have the $2.2M in the LUNC wallet which is in the process of being released to the community pool, we don’t have an emergency need for funding.

We’ve had months now to trying the strategy of low tax 0.2% hoping it would increase volume, and waiting for mystery dapps that haven’t been created yet. This is a poor strategy which has not worked, the price has crashed continually and on-chain burns went way down. This is not the answer. We need to focus on burning now.

6 Likes

You sound like someone who can’t think for himself. I am sure You will eat shit if Ed/Zaradar told you to. Listen, LUNC without significant burns is a Shiitcoin. It’s SHIB v2. These “smart nerds” are securing their monthly salary for years, from you and me in the name of “building”. Can’t you see, it will take LUNC 5 years to killl a zero and these Devs won’t bother about getting there fast, as long as they are making 10s of thousands $$ a month by giving the community Hopium that they are “selflessly” working for the chain. Why can’t their new L1 Task force apply for Binance’s new grant program? Binance clearly said that devs working for LUNC can apply for their grant. Instead, they want to take all the money from our broke community pool and make us even more broke. 50-50 Tx split is being greedy. Not helping the community. These nerds’ “genius” proposals made Binance to hold their on-going burn campaign. But yeah, you do you. Keep supporting them blindly.

I believe Ed mentioned in a previous AMA he went out on his own and applied under the grants program for LUNC already, so that’s already been done. It may be better to apply again under the L1 group with TGF, as Binance specifically mentioned it. It has been a real problem that the burn movement has been disrespected. First only giving 3 weeks for the 1.2%, we should have kept pressure on exchanges to adopt it off-chain, then came minting, then 50% mint, now these poor decisions are coming back to the community in terms of price crashes, Binance rebukes.

2 Likes

It also worth mentioning that prop 5234 never mentioned the seigniorage will apply to voluntary burns. We or at least I found out only after implementation. All the discussions were related to on-chain tax.

When prop 10983 was discussed, we were assured that ED will get Binance feedback before any implementation, did you guys heard anything? Only silence after implementation.

So don’t be surprised now when you the level of trust going down the rabbit hole…

This argument might have worked on someone else, but we kicked Zaradar out of the private Discord channel we setup back then to gather all legacy validators and reach an understanding on how we can proceed in restoring governance and unfreezing the chain just because he was too emotional and would derail the process. So NO I don’t follow a certain developer, I (as a singular member of the community) like having many developers that ask the community via Agora for funding based on a submitted proposal which the community deliberates and votes on.

Cannot disagree with that, I was warning people against it and still am against that stupid 50% seigniorage reward policy. But the fact that a proposal that stupid did pass puts the blame on us as well for not making it known to the community and getting involved in the discussion more fiercely with arguments, not insults.

If the tax burn is set to 1.2% and you CAP the CP contribution level to $100K per month = $1.2M per year does it matters if those 1.2M come from a 50/50 or 90/10?
To use your example @JESUSisLORD , using the 1.2M CAP the effective burn rate of a 90/10 split would be 92/8 because the excess $26K (out of the otherwise uncapped $1.46M) LUNC equivalent would be sent to the burn address. The exact same effective burn rate you’ll get using that CAP and the 50/50 split! All the 50/50 is doing is filling the CP portion up to the CAP faster and no more. Everything over and above the $1.2M will be redirected for BURN.
:wink:

Spot on! We are getting somewhere now. That is why I am trying to focus everyone on the actual problem point we are trying to solve here which is below, everything else is missing the bull mark :wink:


All discussions appear to lead to a singular question we (the community) need to answer before going into percentages. That is:
How many $ are we (the community) willing to allow for development purposes on a monthly basis?

2 Likes

Yes if the CP is capped and excess goes to burns is another workaround.

It however, has two distinct disadvantages:

  1. Poor symbolism. 50/50 just plain sucks. It looks bad. We just voted to overturn a grevious 50% mint proposal and going back to take 50% of burns is just an unpleasant concept. Symbolism is important for investor confidence and 90/10% shows high commitment to burns and thus high confidence. Coupled with removing mints is step 1, we take 2 steps forward for 90/10, and 3 steps with reintroducing the 1.2% tax. The 50/50 feels like one step forward 2 steps back.

  2. It seems that most of the developer types would not support a cap on community pool funds as they have many ideas about $ millions needed for future dapps etc.

4 Likes

Nice train of thoughts. What I was referring to is the “40%” tax that investors may not have an appetite for.

In effect are you saying we should forget the “50/50 hard-code” and use parameter changes whether 50/50 or 90/10 etc,?

Yes you are right the 40% might be too aggressive, but am still allowed to dream :slight_smile:
I don’t mind the hard code tbh because it’s irrelevant when you get to the bottom of it. What matter is all of us decide how many $ we want to be allocated out of the on-chain tax for dev purposes.

Cannot disagree with that really, maybe a 60/40 fixed split is a better middle ground

You are saying that but haven’t honestly seen many serious proposals requesting money from the CP or any particular objection to dev funding collection CAP. I personally don’t like the “blank check” approach where we (the community) perpetually provide a salary to a specific dev team or individual.

At the end of the day, this is a community-owned chain and can have multiple developers and teams of developers. The WHO, L1 Taskforce, TR, TFL, Pepa Pig, or Paw Patrol is irrelevant. What we need to do is make sure we have the funding so that when any developer team or individuals come up with a proposal for the betterment of the chain we can fund them, or not, by voting on their submitted proposal specifications.

3 Likes

es que esa es la solución…no hay que darle más vueltas

We also need to find the oracle pool not just community pool

1 Like

In my opinion the 50/50 was put in place when Binance informed @ek826 that Binance will not support his donations being used for funding the CP. Ed knew from that point that the amount needed to fund devs would need to come from the 0.2% on chain tax. With respect to binance decision to to lower their burn contribution by 50%, I think that came in as surprise and hence the burn amount will be negatively affected by the “50/50”. We must remember the 50/50 was mentioned in @ek826 previous L1 Task force proposal, even before the passing of proposal #11111. Ed was “making certain” the CP would be able to fund the L1 team. That no parameter change, and only a program upgrade could reverse that hard code.

Whether re-minted or “hard-coded” 50/50 ,it will still be 50/50. If 100% of of the tax goes to the burn wallet and you re-mint 50% to the pool what difference does it make if the split was made automatically? This 50/50 came about as a result of Binance discussion with Ed.

Help me understand. I may be wrong?

1 Like

The difference is the non-hardcoded 50/50 (AS IS) also re-mints part of the BURN contributions made by third parties like Binance, CEX, Validators, and Individuals in addition to the on-chain tx TAX collection. While the hard-coded 50/50 (Default Proposal) is only applied, according to this proposal (if it passes), only on the on-chain tx TAX collections.

Thanks for the explanation. It would appear that everyone was okay with the “AS IS” . Couldn’t the issue have been resolved with the addition of a “voluntary burn wallet address”?

A lot of us were not happy with it tbh, but the proposal passed under my radar (to speak for myself) so shame on me for that.

If you add some semi-realistic fictional numbers to those Burn contributions in the (AS IS) you can clearly see why Binance were not happy and said what they said recently:
i.e.
Binance Burn = 6B LUNC
Individuals Burn = 0.5B LUNC (let’s pretend we were that good!)
On-Chain Tx TAX Burn = 0.5B LUNC (let’s also pretend that’s how much the 0.2% yield)
Total = 6+0.5+0.5 = 7B LUNC [that would normally be sent ALL for BURN]
With the 50/50 (50 Burn / 50 Segniorage Reward Policy) the chain would mint 3.5B LUNC and put them back in the CP. So the chain itself yield 0.25B for burn and CP and somehow 3.5B made it back to the CP. I can hear someone saying “Thank you daddy Binance and Individuals for your contribution to our community pool”

Yes, but that re-mint caused by those coins not going to the voluntary burn wallet would still poke some people’s eyes…so not so good from an optics point of view

2 Likes

I thought I was the only stupid one saying this here and on twitter. I dont want pills to be pushed down my throat. Some people are like, since it’s @ek826 and @Zaradar then everything is good. NO! Question and comment on everything you want explanation on. @ek826 recommends you do so. We have to be very careful when we vote “YES” on any proposal.

1 Like

The problem with decentralisation is that it only works to an extent. The LUNC community have been looking for a leader or leadership team continually since the crash, like a man looking for something to hold onto when floating in the sea. First it was Terra Rebels. The community was united behind the vote for staking, 1.2% tax and the proposal which signalled for exchanges to adopt the 1.2% off-chain, all unanimous votes. The hype and burns were there and the price reflected this with a 600% move. The community naturally looked to the people with the greatest expertise when making decisions, that is developers. They became the de-facto leaders. However, just because someone can code does not make them a good leader or that their vision for LUNC is correct. They are technical professionals, not necessarily quality leaders.

For example, from long ago Ed always spoke that he didn’t believe in the 1.2% tax, same with Zaradar and others. It was given 3 weeks before Ed wrote the Medium article supporting the change to 0.2%. He also supported and was instrumental in the minting of LUNC. Both of these were extremely poor decisions. Only now when Binance threatens to pull all burn support is it revealed that we could have had code to never allow minting in the first place.

Developers are concerned about getting paid and continuing to get paid. A worker is worthy of their wages. But the developers should serve the community, not the community serving them. They should be advocating for the will of the community, not theirs. Hence their proposals will always put the greatest chance of getting paid. The 50/50 proposed here is really wrong, but whether what we say will have any influence on it remains to be seen. Developers are the de-facto leaders of this chain, that is obvious. Just remember they have often made poor strategic and governance decisions in the past, and do need to be held to account.

6 Likes

The conflict if I may add is that cz believes in burning and based on your article if @ek826 did not believe in the 1.2% burning, he shouldn’t be advising @ClassyCrypto on his1.2% proposal,unless his views have changed.

You are 100% correct. I asked that question a long time ago and was informed that it could not be done any other way based on how the coding was written. But now it seems that it’s a no brainer.

We need a team to represent us retailers. Decentralization is not working for us.

4 Likes

@ek826 and the L1 Joint Task Force Team authors. Please take time to browse through the ammendment proposal which I feel is necessary to implement to your proposal.

I tried to address the issues with your prop that were simply to painful to read - like centralising the control over the Burn Paramater and Political-like narrative around the Burn/Pool split.

Everyone in the LUNC Community has expectations of the L1 devs to fix the issues we have at their core and in my opinion (and many in the community) this cannot be went ahead with as is.

4 Likes

It is hard for people to wrap their heads around the fact that the chain is owned by the community and we are all responsible for all decisions around it. That also means we need to be actively engaged with what is going on.

As you said, it feels like people want to offload that responsibility to another TFL and DK and retain the right to point their finger at them when something goes wrong…it’s easier after all to blame others for mistakes than oneself.

2 Likes

So what is the amount of $ do you (ALL) think we should collect in our wallet (Community Pool) via on-chain tax for development purposes?
NOTE: The money in the community pool is not automatically distributed to the developers, whoever needs dev funding will still need to raise a proposal and we’ll have to vote on whether we release the funds to them or not

Cost Profile 1

Based on the proposal cost breakdown here and here (two major dev projects running in parallel).
The cumulative cost comes down to:
$141.75k + $125k = $266.75k over a period of 3 months,
or $266.75k / 3 = $89k per month
There are 4.34524 weeks in a month, hence that last value gives us the weekly cost for such a development schedule described above: $89k / 4.34525 = $20k per week

Question 1: Do you think $89k per month is too much?

Cost Profile 2

We start small so we are lean in terms of our community pool management.
For example, we make sure we can support at least L1 development cost and we add a bit of overhead, like a quarter of the L1 dev cost, which will build up over time (1 year) to allow us to support funding of another large development project. Using the L1 development cost values again here we get:
$141.75k + $141.75k/4 = $177.1875k over a period of 3 months,
or $177.1875k / 3 = $59k per month
or 59k / 4.34525 = $14k per week (there are 4.34524 weeks in a month)

Question 2: Do you think $59k per month is too much?

Why set a limit?

So as we don’t populate our community pool with stagnant coins which could otherwise contribute to the BURN effort. We collect and keep what we need to help develop the chain and burn the overflow and that is over and above our usual burn contributions as outlined on the technical design diagram (Proposed Changes) below:

P.S: I have rounded up/down here and there to get easy-to-read numbers

1 Like