1.2% Burn & Development Tax During IBC Reopening

Temporary 1.2% Burn & Development Tax During IBC Reopening.


Both sides of the tax argument have made valid points as to why a higher/lower tax is more beneficial, the tax has served to bring the community together and slowly chip away at the supply, but at the same time too high a tax will drive away developers and many large volume
traders, this proposal seeks to use an increase in tax to capitalise on periods of increased activity, whilst in the long term ensuring developers are not put off from our chain.

This proposal aims to re-visit and analyze the effects of the previous and current tax-burns, and their efficacy (or lack thereof). With past data in mind we can reach certain self-evident conclusions and chart a more effective path forward. In retrospect, it is obvious that there were missed opportunities and missteps along the way - this proposal aims to rectify that by introducing an increaed tax period that would take advantage of the upcoming IBC reopening event to greatly increase the amount of LUNC being burned, while also building up funds for development in Community Pool and finally securring funds necesary to keep the chain running by topping up the Oracle Rewards Pool.

More detailed reasoning for such changes can be read in a supporting medium article by a co-author of this proposal:

~ Short-Term ~

  • To maximize the burn rate from volume returning from Osmosis by increasing the on-chain burn fee to 0.96%
  • To replenish the Community Pool with an additional 0.24% taken from each transaction
    *To replenish the Oracle Pool with 50% of funds collected by the Community Pool fee (at a later date)

~ Long-Term ~

  • To keep the long-term tax rate lower as an incentive for builders (the final rate can be agreed at a later stage, based on how the eco system has changed.
  • To have part of the tax directed to fund the Community Pool
  • To have a part of the tax to fund the Oracle Rewards Pool
  • To have a part of the tax set aside as a collateral for USTC (perhaps creating a new pool/wallet)


  1. Agora discussion
  2. Parameter change proposal #1: to increase the tax rate from 0.2% to 1.2%
    (with 0.24% sent to Community Pool)

Parameters changes required:

“subspace”: “treasury”,
“key”: “TaxPolicy”,
“value”: “{“rate_min”: “0.012”, “rate_max”: “0.012”, “cap”:{“denom”: “usdr”, “amount”: “60000000000000000” }, “change_rate_max”: “0.0”}”
“subspace”: “treasury”,
“key”: “RewardPolicy”,
“value”: “{“rate_min”: “0.8”, “rate_max”: “0.8”, “cap”:{“denom”: “unused”, “amount”: “0” }, “change_rate_max”: “0.0”}”

  1. Proposal to fund the Oracle Pool from the Community Pool (effectively 0.12% from each transaction collected during this taxation period).
  2. Discussion and Parameter proposal #2: to decrease the tax back to lower figures.

#1 vote to be triggered approximately 9 days before IBC is reopened. If passed, the change would go into effect 2 days before IBC reopens - a safeguard not to miss the critical date.

#2 New tax rate discussion triggered after the date of IBC reopening.

#3 Vote on another tax change to be triggered at a reasonable date agreed during the second debate.

Specific dates to be discussed and coordinated with developers!

The proposal aims to synchronize short- and long-term goals, and calibrate the community on using the burn Tax rate effectively.

Historically, the burn tax has not been fine-tuned to major volume generating events, which resulted in a minimized burn rate. To illustrate that, let’s take a look at past governance proposals passed, the volume generated, and the tax rate that was in place. Let’s also try to rate these decisions in terms of effectiveness, and try to learn from those situations…

In this analysis we’ll be looking mainly at the on-chain volume, and total/circulating supply decrease. It is all about timing

  1. Staking Re-Enabled
    Background: This event had major effects on on-chain volume, with biggest volume seen since the crash. The change in volume was due to very high staking rewards APR (triple digit %s), which triggered a surge in demand for LUNC. In a few days’ time, about 7% of total LUNC supply had been moved from CEXs to Terra Station. This event was taxed at 0.00%.
    Summary: This was a major, predictable volume-boosting event, and our biggest opportunity to apply a high burn-tax rate to maximize the
    decrease in total circulating supply of LUNC. Instead, none of these transaction were taxed! It is safe to say that it was the biggest strategic mistake up to date.

  2. 1.2% Tax Introduction
    Background: This proposal was introduced at a time when staking APY has already decreased to a point where it was not a strong magnet for new investors anymore. There were no other major proposals or events at a time to reinforce the on-chain volume. The side effect of this proposal – since the momentum of LUNC social media influence was at its highest – is Binance joining the burn initiative by burning their fees collected
    from LUNC buy/sell transactions.
    Summary: This change was introduced too late to have major effect on the total supply. However, it spurred a major CEX to participate!

  3. 0.2% Tax Change
    Background: This change was done 3 weeks after the 1.2% tax was introduced. This change was promoted as a way to increase stalling onchain volume while increasing the burn rate due to higher chain activity.
    Sadly, none of these have materialized. A few days after the change took place we saw one of the lowest daily burn rates recorded while volume has failed to increase since then.
    Summary: This change had little effect on volume and burn rate. It has minimized the burn rate from another event - the introduction of new validators to Luna Classic Chain: a long-planned, known, and fully predictable volume-boosting event.

  4. Creating New Validators Function Restored
    Background: As mentioned above, this event was subject to the 0.2% burn fee instead of 1.2% for no particular reason. The 0.2% rate was in place for too short a time to have any positive effects on volume, while it totally wasted the opportunity to reduce the total supply by taxing the new validators on-boarding event.
    Summary: This bad decision was easily preventable if the introduction of 0.2% was delayed by just a few weeks.

  5. (Present Time) At this point we have another major volume-boosting event in our sight: around Christmas 2022 IBCs will reopen, and people who bought LUNC on Osmosis will be able to send those funds back to the Luna Classic chain. Many of them will also send those funds to centralized exchanges in order to sell to fiat and cash out. It is clear that there is a decision to be made in front of us. How do we interact with that opportunity based on the past decisions we made? Do we proceed passively and not take any action? Or do we start taking a proactive approach and try to gain as much of a benefit for the community as we possibly can?

This proposal identifies 4 opportunities arising from the aforementioned situation…

(1) Possibility to fund the Community Pool: With the uncertainty around the 4 million USD in the multi-sig wallet (and the threat that we might
not be able to claim these funds due to legal issues), it is rational to seek other ways to fund the development and upgrades of our blockchain.
Thus, by temporarily increasing the community pool reserves, we could build up a budget for that purpose. This method is superior to claiming
funds associated with TFL due to lack of any legal risks.

(2) Possibility to decrease total supply at an increased pace: With disappointing short-term results of the 0.2% tax on the burn rate and total circulating supply, it is natural to seek a way to redeem the situation. Taking advantage of this volume peak is a way to do it. Taxing these transaction at a higher rate could more than make up for the turtle-paced burn rate we have seen for the last few weeks.

(3) Return to long-term approach: After the expected volume peak is over, we would return to the low tax approach and keep measuring its effects on our chain.

(4) Possibility to fund the oracle Pool which is very important as at this moment we are draining that pool of funds. If we do not find a way to replenish this wallet, we are putting the whole POS system at risk.

Oracle Rewards Pool address: (terra1jgp27m8fykex4e4jtt0l7ze8q528ux2lh4zh0f)

(5) Possibility to set aside funds for the USTC repeg (future change)

This proposal has the potential to unite our fragmented community back together via agreeing on a common way forward by having learned from past events (and mistakes). The approach presented in the proposal joins multiple different paths into one. Firstly it offers a win-win situation on both short- and long-term goals. Secondly it respects both the older vision which focuses on burning our supply to 10B, and the newer/leaner approach which focuses 100% on utility and higher total supply. Finally, it offers a switch from passive, reactionary decision-making (which has failed in the past!) to a proactive way of predicting future events and adjusting our methods to make the best out of them.

This proposal is open for changes and input from the community. Anyone can participate and share ideas, which can be added to the proposal with
credit to its author(s) if found viable. Specialist advice on time-frame and dates to maximize the effects of this proposal would be particularly

After implementation, we will reassess the on-chain tax depending how the ecosystem has changed

Proposed by
LUNC Holders and Community Members
@Powski (TR Discord)
@Redne3ckFinance (Twitter)
¡Please hold primary discussion and feedback on Agora as it may be used to improve the proposal!


In order to always have the necessary financing of any projects on the Lunc network, it is enough to only move the community pool and any other income of the community to stake.Constant high income from staking will allow you to finance any projects and not to deplete community pool.And on the contrary, the income from the stake of a public pool in the future will be so great that it will allow you to name the Lunc network the richest of all others.


Excellent proposal. The only proposal to consider replenishing oracle rewards and the idea of starting to gather funds to make a USTC repeg easier also makes alot of sense. 1.2% is likely to be accepted because it was accepted last time. Great, holistic approach to the burn contribution. Now it contains the 20% seigniorage for more comprehensive onchain funding, I would feel more comfortable calling it a tax. I would maybe consider adding a section to community pool grants that would allow allocation of funds for a grant to pay dApp developers that use multiple contacts to pay themselves tax exempt. No one project should carry a large tax burden


OP, please explain the basis for deriving at the following rates:

  1. 0.96% to burn wallet; and
  2. 0.24% to CP.

Shalom :pray:

@ek826 used the slot machine analogy to support lowering burn tax to the current 0.2%. It is fair to say that we have pulled that lever and the outcome has not been better. However, returning to the 1.2% does not allow us to collect information on the ideal tax rate and only serves to penalize LUNC transfers once IBC is opened. Perhaps it is better to consider an increase to 1%, and review the on-chain activity and burn results.

I would also suggest that whatever portion of the 1% is dedicated for burns is split between burning LUNC and USTC, after allowing a portion for the community pool. There has been a lot of discussion around a re-peg and, regardless of the method, consensus seems to be that a re-peg would be very beneficial for LUNC in the long term. USTC has a much lower supply and an effort to burn off excess coins should be part of the burn movement.

Whats wrong with you? We should be disscusing of lowering the tax not increasing it. Do you want to destroy the chain or you have no idea how it works?


Whether or not the 1.2 to .2 change was good or bad is irrelevant at this point as we can’t change the past and frankly neither had/has enough time to work to determine the overall effectiveness. However, constantly flipping back and forth will help spur on the belief that the LUNC community cannot make up its mind on any serious matter and people vote as the wind blows. In the end 1.2 or .2 isn’t going to make a difference since we are talking 20 years vs. 30 years to get back to a dollar so who cares at that point. Without more dApps and repegging this coin will slowly wither and expire. People’s energy should be focused on how to make that happen.


20% of 1.2% is 0.24%, ergo the seigniorage. 0.96% is the remaining 80% to be burned

Great job, 100℅ agree. I can’t wait to vote YES!!!


there are some good points in this article, which community needs to address but the solution provided by the proposal is as bad as “Drinking poison to quench thirst”.
Yes, we should find a way to replenish the Oracle Pool and if we don’t do that as the proposal said “we are putting the whole POS system at risk” but the suggested way to fund our chain via tax on other one’s property, is like confiscation their property. while it benefits us in short term but Destroying trust in the future.
I like the idea of the Japanese community, providing undelegation ahead of 21-day time and taxing it, and using it to fund developers, oracle pool, and burn.


Great idea. Should help with supply reduction during the reopening.


I think a lot of the problem with parameter change proposal 4661 was the branding. The 1.2% wasn’t really a tax, it was a burn contribution. None of the collection was held back by the chain for spending. The only “tax” we have had on chain is the 0.02% from the seigniorage of the 0.2%. Burning is not tax. Perhaps a better title of this proposal could be:
1.2% burn contribution, inclusive of a 0.24% seigniorage to be used to fund chain development and Oracle Rewards

1 Like

I don’t agree with the proposal, we must first rebuild the ecosystem as V23, IBC, AFT, after that, review the tax issue if necessary. Keeping changing the tax all the time doesn’t make sense and I believe it won’t solve this moment.


I don’t agree this proposal. If 1.2% tax burn again, transaction will drop sharply…. I think Dapps are gonna have some troubles. It looks better that we just keep 0.2% tax burn.


Smart proposal. “Yes” from me.


NO, makes no material difference in burn and takes away speed of new Utility. I do support a .2% tax on staking rewards to replenish oracle.


Very well thought-out proposal and justification.

Nicely done, this is a YES from me!

Shalom! :pray:


Yes from me. :pray:


This will be a No from me, the 1.2 tax killed volume and caused problems with dapps and did not really make much of a dent in the supply.
Raising it may create the same problems we reduced it to solve.
This proposal seeks to also solve the problem regarding the oracle pool which is a good thing, but I don’t think this is the right way.


Great points overall. However, the brand of the chain and rationale behind our decisioning need to be considered. Also, the focus should be on utility and building and less on burn tax at this stage. We need to focus on attracting developers and build the cross chain activity, vs. look at ways to tax it, before it even began. The examples for past “opportunities” to tax made sense, however, there is no empirical evidence presented in the proposal analysis to weigh in what the outcomes may have been with different burn % in place. There may be a later time to assess this proposal with a bit of changes, but I would say that the IBC event and taxation of returning LUNC from Osmosis sends the wrong signal to those holders and apps from other chains.