New-account limits on this forum currently permit one embedded media item and two links. To preserve the complete proposal, charts, evidence, and references without removing important material, the full discussion draft has been published on Commonwealth:
For which Target should that be - Oracle Pool, or…what is the Point that we want Put down again our Volumen, if we have some.
But why I am not wondering , the Burn Tax a yearly reminder.
And on Commonwealth- I start reading - but serious what in the h… you did.
To much text and for an Proposal I would like to see max and DIN A4 format what not grab my time for the Burn Tax - i know now how it ends 
1 Like
-
we’ve had 4 years to replace the burn tax, we have not come up with any better solutions. there is almost 0 utility to speak of.
-
since the supply is still enormous, we should accept that we are still in the “burn” narrative instead of “utility” narrative - focus on burns should be prioritized (we may add quick-unstaking fees, deletion of old/inactive supply, manually burning the TFL wallets that have remained etc.)
-
the transfers that have been executed on-chain most likely would’ve been made anyways, regardless of the tax rate
-
higher burn tax might incentivize CEXes to ask for a whitelist in exchange for some benefit to Terra blockchain (i.e. off-chain burns etc.)
-
if we remove the tax/lower it further, that might induce Binance to end their burn program. Increasing the tax will have no negative impact on Binance.
-
even if this prop would fail, it would be good to gauge community’s (validator) sentiment. Since no validator actively discusses these proposals, I would even like to reduce the deposit from 5 to 1 million. Why pay 5 million to get slapped in the face with a VETO from a validator who never bothered to discuss the proposal publicly.
-
if you’re serious about this proposal, it should be a parameter change proposal not a text proposal
1 Like
you can use AI to summarize any larger texts for you
1 Like
Ok I can - but it was this time an real interest behind to read them.
But yes I do it 
2 Likes
First of all, thank you for the tremendous amount of work that went into this proposal. The level of research, historical references and on-chain data is impressive and deserves recognition.
However, we believe one important aspect is missing from the economic analysis: the total cost of using Terra Classic compared with competing blockchains.
When an investor, trader or developer evaluates where to deploy capital, they rarely look at a single parameter in isolation. They compare the overall cost of using each ecosystem.
Today, many major ecosystems operate with relatively low trading fees. Ethereum L2s, Osmosis, BNB Chain and many Cosmos chains generally expose users to transaction costs well below 1% for typical DeFi operations.
With the proposed 1.5% burn tax and the upcoming 0.35% MM2.0 spread fee, a swap executed through the Market Module would face a nominal cost of approximately 1.85% before gas, slippage and market price impact.
For arbitrage, the situation becomes even more significant.
An arbitrageur rarely performs a single transaction. A typical strategy consists of buying on one market and selling on another, meaning a round trip. Under the proposed fee structure, that could represent approximately 3.7% in cumulative protocol fees before gas and slippage.
Many arbitrage opportunities are significantly smaller than that threshold, meaning they would simply never be executed. Yet MM2.0 is specifically designed to encourage arbitrage, improve price discovery and contribute to the USTC repeg.
This is why we believe the combined fee structure deserves more attention than the burn tax alone.
We also believe that historical comparisons with 2022 should be interpreted carefully.
In 2022, Terra Classic still had a substantially larger community, higher liquidity, more speculation and significantly greater on-chain activity than it has today.
Today, the ecosystem is considerably smaller. TVL is much lower, DEX activity is limited and attracting new capital is arguably more important than maximizing taxation.
A fee increase that might have been sustainable in a much larger ecosystem may have a very different impact on today’s Terra Classic.
Finally, MM2.0 already introduces a new recurring source of burn and Oracle Pool funding through its 0.35% spread fee. Rather than evaluating the burn tax independently, we believe governance should first observe how the complete economic model performs in production.
Personally, we (DarkSun validator) would prefer to deploy MM2.0 first while keeping the current burn tax. After several months of measurable data, governance could then optimize the overall fee structure based on real network activity rather than assumptions.
In our opinion, Terra Classic should optimize the total cost of using the network, not each fee independently.
Thank you for taking the time to respond. The concern about total network cost is fair. The difficulty is treating 1.85% and 3.7% as settled costs for every MM2.0 swap.
The plan voted on in #12188 says the 0.35% spread should replace the chain tax on Market Module swaps rather than stack with it. If the finished version follows that rule after any tax change, an MM swap would pay the spread instead of both charges. Two MM legs would cost about 0.7%.
A real arbitrage trade may also involve another venue, transfer tax, withdrawal charges, gas, slippage and price impact. Its total cost depends on the route and cannot be calculated simply by doubling one fee.
Checks on the current MM2.0 code found some routes charging only 0.35% and other routes charging about 1.845%. That inconsistency needs to be resolved before MM2.0 is activated. It shows that 1.845% is possible in the unfinished code, but it is not a universal MM2.0 fee and it is not created or approved by the present tax proposal.
MM2.0 is not running in production. #12188 was only a signal, the implementation remains open and unfinished, and there is no approved activation date. Ordinary Market Module swaps are also effectively unusable under the live 100% minimum spread. There is currently no MM2.0 production data to observe.
MM2.0 also does not already provide a new recurring source of burns or Oracle Pool funding. Its liquidity would initially come from redirecting 60% of tax proceeds already collected by the chain. New spread income would depend on actual swap volume. The plan itself shows that LUNC burning may be lower, equal or higher depending on swap direction. MM2.0 may eventually help, but it is not producing those benefits today and not guaranteed.
The point about the smaller ecosystem is also fair. That is why the proposal uses recent archived 2026 collections for its illustration rather than treating 2022 as a forecast. The historical comparisons are included as context and do not claim that the tax alone caused changes in activity.
After the rate fell from 1.2% to 0.2%, indexed transactions recovered partly, but gross LUNC tax fell by 61.5%. When the rate later increased from 0.2% to 0.5%, the selected transaction figure was about 2.1% lower while gross tax was about 2.84 times higher. That does not guarantee the result at 1.5%, but it supports measuring the result rather than assuming that a higher rate must destroy activity.
As submitted, #12223 carried the live gas settings forward and proposed changing the tax rate from 0.5% to 1.5%. Those settings should continue to be monitored until execution.
Under the current 80% burn, 10% Community Pool and 10% Oracle Pool allocation, the nominal rates would each triple at the same taxable activity before caps and rounding. Actual collections may change with activity, exemptions and tax caps.
Waiting for MM2.0 and observing it first is a valid preference, but that option is currently open ended because there is no launch date or production data. A possible fee problem in unfinished future code should be fixed before that code is activated. It should not be treated as a cost created by the burn tax proposal being considered now.
The burn tax is already live, measurable and funding burns and both pools today. MM2.0 is a separate future decision.