Community Pool Burn Tax Reversal


4080 | Parameter change proposal

Distribute 50% Transaction Fees to the Community Pool + Increase Proposer/Validator Rewards

35% to be burned via monthly community pool proposals; 10% airdropped to ecosystem devs, 5% retained for core Terra Classic development) and increase ‘Base Proposer’ and ‘Bonus Proposer’ reward from 0.01 and 0.04 to 0.03 and 0.12 respectively.

I now ask the community & validators to vote yes to reverse this monthly burn/tax on the community pool proposed in 4080 3 months ago

No distribution model has been presented and implemented as of yet.

Reverting it now would be as simple as this proposal passing and the community being made aware of the reversion

Original Agora Text 4080


Burning our community pool is wrong on so many different levels but the main one is being a community pool, it is in place for the community to propose pool spends.

The pool’s revenue would be better used to pay for services the block chain receives to maintain its welfare and continued upkeep


The Proposal will nullify the community pool burn tax proposed in 4080 If passed

I Welcome All Questions

Kind Regards

Jay - HappyCattyCrytpo


I Agree with this proposal to Reverse the community pool burn. The community pool needs to be used for things that it was built for i.e Paying the dev teams that ensure good block chain health and continuity, helping with onboarding utility and use cases to the block chain through funding, maintenance and upkeep of the block chain. As we now have Staking re-enabled and burning initiatives are coming on chain, and the potentials for off chain burning, coin burning will take care of itself. We need the treasury for other things that ensure our blockchain will remain healthy.


Yes i support this proposal…

1 Like

i support this proposal, Best of luck HCC

1 Like

Why did your offer appear right now?Why such urgency?Why don’t you make this proposal after the introduction of the incineration tax?Or maybe you are trying to sabotage the imposition of an incineration tax with this proposal?


YES to the Proposal

I agree, great proposal :100:

Whatever is good for the betterment of lunc is fully supported by the community​:busts_in_silhouette::busts_in_silhouette::busts_in_silhouette:, yes i support

Please read the proposal you are trying to cancel carefully! I think you misunderstand what 4080 actually does.

Since it was implemented the community pool grew from 10M to 14M. The parameters you are looking to reverse will STOP any distribution to the community pool.

Am not against what you are trying to do provided it’s done correctly and balanced. Also, this is a parameter proposal so you’ll need to define the parameters to replace.



VERY POOR TIMING OF PROPOSAL - Leave things alone till after the 1.2% burn tax is implemented and is on the chain. Once the burn is in place then we can look at options for the Community Pool.


I agree this pool should go to dapps and devs. If we want to grow we need Utility. Burning will come with 1.2% tax and ustc swap.

1 Like

I would recommend to the validators on this vote to put NO with veto power.And after the introduction of the incineration tax, it will be possible to discuss the distribution of the commission.

1 Like

This is ridiculous by a ceo of a decentralised community (Google what a ceo actually is, ceo can’t co-exist with decentralisation) this pool can only be burned if a prop to burn it passes. Simply put, don’t put a prop in to burn it and it’ll grow until the terrarebels decide otherwise. VOTE NO and leave people who are capable of arranging this to do it, it’s not a game of who done what!

My aim is to reverse just the burn/tax on the community pool. I have already stated many times about supporting Dapps & spoken with vegas many times about it.

The community pool should be first used to support the blockchain as with out ensuring the future of it… We won’t be able to onboard new projects and Dapps

We can always make a change later and anyone can propose a community pool spend prop to help any Dapps onboarding


I do get what you’re trying to achieve and it’s not a bad idea, however:

  1. The proposal is not worded with enough details to include the action (it is required for parameter proposals)
  2. The timing of it all is wrong as @dbeart mentioned
  3. The portions of the transaction fee that was meant to be burned (as per 4080) is NOT currently active, so that 35% of all transaction fees currently beef up the community pool instead of being distributed.
  4. The portion of the transaction fee that was meant for airdrops (a.k.a support, as per 4080) for existing dApps is also NOT active so that 10% also currently beef up the community pool instead of being distributed.
  5. The portion of the transaction fees that was meant for Core Developers (as per 4080) is also NOT active so that 5% also currently beef up the community pool instead of being distributed.

Given the status of things above why in gods name would anyone want to stop the beefing up of the community pool and bring back a state where NOT COIN was going to the community pool.

Your point does make sense after the 1.2% activation. My advice would be to use the time you have and liaise with the author of 4080 ( @dfunk ) to collectively come up with a better allocation (and detailed proposal) since at that point in time there won’t be a need to burn that 35% portion of the fees going to the community pool.


I totally support this. Need operational stability and that costs.

I assure you this is only for the Community Pool BURN/TAX nothing else.

As stated… It is as simple as the community agreeing to not burning 35% of the pool each month.

No distribution model has been presented and implemented as of yet.

Meaning… No one has set up a multisig wallet and put it in to play


Like I said I understand what you are trying to achieve :wink:. That portion of the equation you are interested in is handled by a smart contract, not the parameters set using prop 4080.

The/A distribution model was presented and voted for with prop 4080 and is coded in a smart contract by its’ author here: dfunk_contracts/contracts/luna-distributor at master · dfunk009/dfunk_contracts · GitHub
about to go live anytime now! It’s the Core Dev recipient addresses that are not defined afaik and can see in the contract so those funds still will end up in the community pool.

Liaise with the author to (maybe) postpone deployment and come up with a supplemental proposal ref. the allocation and tweak his smart contract to that end.

1 Like

Why not TFL address? Are they officially decided to not work for Luna Classic chain?

Core Devs can be any devs appointed to work on the core chain and can be from many communities provided they do actually contribute to the chains’ code evolution :wink:

Imo, TFL can be another dev community alongside TR that can share development tasks, if they so wish to, and get paid for it just like any other community developer should/must. As it stands the development team of the TR community is the leading LUNA Classic chain development team, so task appointment falls to them; I hope more will come forth and that team expands over and above TR into something also decentralized so as to avoid a siloed structure…maybe using an Agile methodology style of operation.

One thing is for sure, this chain’s future is bright…
Rock on and prosper :metal:

1 Like