they talking about hype coins who just came out xd like pepe or lady lol
people think bull market come and spamming shit about lunc !
if we managed to take precautions to go with the flow we need to be ready around june.Russia its gonna accept crypto so another wave from there will jump here
How is this related? Will they start paying salaries in crypto in Russia? Or will they place it on the Moscow Stock Exchange?
There is a requirement to register crypto wallets with the tax office. Russia, of course, is a country of vegetables, but not to that extent. Whoever wanted and could, has long been in cryptocurrency. Other peasants
1 Like
In ustc. Soon. 
Fyi,
I’ve raised support/feature tickets with both TR and TFL to expose the wallet exception management proposal types @dfunk mentioned earlier on in this post under Rebbel Station and Terra Station respectively.
That is to expose the governance capability required by 11516 and be ready once the code is extended to support contract exceptions as well.
1 Like
Sorry for overlooking, but is it possible to have pre-crash data ( i.e. transaction types ) for comparison as we have much fewer dapps post-crash.
Send Transactions is a part of income for LUNC ecosystem, but aren’t burn tax comes from Contract Executions ( usage of dapps on chain ) also an important part for exponential growth for LUNC ecosystem? No.4 will take this part away?
proposal passed.
blockheight to occur (12,902,400), estimated date (23-May) and time (10pm UTC)
6 Likes
Burn tax (currently) comes from the following transaction types:
- MsgSend - Sending from one wallet to another
- MsgMultiSend - Sending from multiple senders or to multiple receivers (taxed once)
- MsgExecute - Bundled dApp and smart contract transactions (each bundled is tx is parsed and taxed)
- MsgSwapSend - Swapping, then sending to another wallet
- MsgInstantiateContract - Creating a new smart contract
- MsgExecuteContract - Smart contract transaction
Yes, burn tax comes from contact execution transactions but their contribution is minimal in comparison to send transactions (at least post-crash). At the same time, we need to make the chain competitive when it comes down to attracting L2/dApps/Utilities (No.4) in order to increase our volume and benefit from the tax burn on those send transactions pouring out of those L2/dApps/Utilities core capabilities.
Hi @dfunk ,
I just saw this in the description:
Note: The burn tax has been repurposed from Tobin tax and so apart from increasing the rate to 0.5%, I would also like to recommend to change the name of Burn Tax to Tobin Tax.
I am wondering if you meant Stability Tax (the previous treasury module stability tax on transactions using Terra stablecoins that are not swaps, which was turned off initially with proposal 172 - now extended as the burn tax) rather than Tobin Tax?
The only reason I ask is that the Tobin Tax (the “discourage front-running” fee applied on TERRA STABLE <> TERRA STABLE swaps) and Spread Fee (the “maintain a constant product during times of volatility” fee applied on LUNA V1 <> TERRA STABLE swaps) are both market module taxes and still activated (well, the Spread Fee is not since those swaps are disabled currently, but the MinSpread parameter is still activated).
I hope you are having an awesome day today 
If not mistaken the Stability Tax = Tobin Tax, we just extended the treasury module so that it’s applicable over and above its application on stablecoin swaps 
Still am not sure if we should really refer to it as Tobin Tax though!
The reasoning is:
The burn tax value currently affects only native coins because swaps are disabled. Should the last be enabled I would think the configured value would also apply as a Tobin Tax on stablecoin swaps. So this tax has a dual function in two distinct capabilities of our chain:
- Tobin Tax on stablecoin swaps (currently disabled)
- Deflationary Tax (burn tax) on native coins
We might have to de-couple them sometime in the future before stablecoin swaps are enabled.
Understand we have to trade off potential future growth for current situation, will there be re-evaluation of situation to disable this exemption of tax to smart contracts ( No.4 ) i.e. if x % of transactions are from MsgExecuteContract & MsgExecute for a sustainable month or milestone of number of dapps have come back on chain?
@aeuser999 @godoal While this was discussed, I have not put this name change in the proposal. Based on community feedback, we should stick to the nomenclature of “Burn Tax”. This nomenclature is well understood and adopted by the community, both on-chain as well as off-chain (CEXs, wallets, dapps, etc)
5 Likes
It fits our attractive image of meme better. Burn tax it is.
3 Likes
Hi @dfunk ,
I was more asking since I remembered there being a distinction between the stability fee tax and the tobin tax. I went ahead and looked them up again, and they are different. Although, I will say that the stability tax is not very clearly defined in the columbus-5 documentation, although a little clearer in the columbus-3 documentation.
Here is what I found:
TL;DR:
-
Stability Fee Tax: Treasury module based tax, that is capped, on all transactions that are “stable coins” that are not swaps.
-
Tobin Tax: A Market module based fixed fee added to swaps between “stable coins” to prevent front-running.
-
Spread Fee: A Market module based minimum adjustable fee, that is adjusted upward during times of volatility, to maintain a constant product between the fiat value of the LUNA v1 pool and the size of the “stable coins” pool, and is added to swaps between LUNA v1 and “stable coins”.
Longer Explanation:
-
Stability Fee Tax is a treasury module based tax called the “Tax Reward”, as one of the three macroeconomic indicators which corresponds to the Tax Rate policy lever (macroeconomic in terms of system wide).
- It is defined as “Income generated from transaction fees (stability fee) in a during the epoch” and its monetary lever is defined as “the amount of income coming from Terra transactions, limited by tax cap”. There is a note on the Fees page in the documentation about the stability tax that defines it the clearest (before it was turned to 0% in proposal 172, and the burn tax functionality repurposed the stability tax with [merged code]):
-
Stability Fee Tax: “the stability fee tax rate… used to be charged on any transaction using Terra stablecoins, excluding market swaps.”. In other words it is a tax on transactions that happen using stable coins, but those transactions are not swaps (whereas Tobin tax is on swaps).
-
You can see the “T” formula variable is for Tax Rewards, and is used in the formula for the Tax Proceeds section which is tied to the Tax Rate and Tax Caps. The parameter that sets it is in the Treasury space in the key Tax Policy, just as the Burn Tax is (which also uses that key).
- Since the Stability Fee Tax is a lot less clearly defined, here is the proposal discussion that turned off the Stability Fee Tax in Proposal 172 originally.
-
-
- It is defined as “Income generated from transaction fees (stability fee) in a during the epoch” and its monetary lever is defined as “the amount of income coming from Terra transactions, limited by tax cap”. There is a note on the Fees page in the documentation about the stability tax that defines it the clearest (before it was turned to 0% in proposal 172, and the burn tax functionality repurposed the stability tax with [merged code]):
Thankfully the Fees page defines Tobin Tax and Spread Fee much more clearly:
-
- It is a market module based tax, and its parameter is in the market space in the parameter key TobinTax
-
- It is a market module based tax, and its parameter is in the market space in the parameter key MinSpread
Just sharing that since it took a while for me to piece together the Stability Fee Tax (what it actually was) - and where it really was defined in the documentation. It seemed like it was somewhat wrapped in obscurity other than in the code, a passing note, and one proposal discussion. Passing it along if helpful (if not, just disregard).
On the naming, I heard one person say we should instead call it a community buy back program (rather than burn tax).
But, really I just noticed what you mentioned about the Tobin Tax, so I went back to check up on it again. Feel free though to let me know though if I have missed anything in my thinking (I would be thankful).
I hope you have an awesome day today
1 Like
The market module does not have a Tobin Tax parameter. I was under the impression it was phased out, maybe am mistaken. Could it be the parameter is hidden somewhere else?
Yea, it bounced around. So, here is what I found from looking it up in the code (for the sake of those reading who do not know, columbus-5 is the current mainnet for Terra v1):
Research:
Columbus 3: The TobinTax parameter was in the parameters in the Market module in v0.3.x (and also had a parameter IlliquidTobinTaxList, also in the Market module, not listed in the documentation for columbus-3, but seems similar to what they ended up doing in v0.4.x):
- https://github.com/terra-money/classic-core/blob/v0.3.1/x/market/internal/types/params.go#L17-L26
- And the v0.3 documentation (ie. columbus-3): https://docs.wcdc.me/docs/dev-spec-market#tobintax
Columbus 4: The TobinTax parameter moved from the Market module to the Oracle module in v0.4.x (ie. columbus-4)(into the WhiteList parameter key) . This now allowed setting a specific TobinTax on each denomination for stable coins that are whitelisted (rather than a value for all stable coins, and a specific one for stable coins that were not very liquid):
- No longer a param in Market Module:
- Now a parameter in the Oracle Module:
- Here is how they stated it in the proto-docs for that version in the code:
-
Tobin Tax… sdk.Dec that stores spread tax for the denom whose ballot is passed, which is used by the Market module for spot-converting Terra<>Terra.
-
Columbus 5: The TobinTax parameter is still listed in the documentation as in the Market Module for columbus-5 documentation. However, the proto-docs for v0.4.x (ie. columbus-4) do not include the parameter in the Market module any longer. The proto-docs for columbus-5 do show it in the Oracle module in the Whitelist still, and also not in the Market module, but still acknowledge the note that it is " is used by the Market module for spot-converting Terra<>Terra".
Conclusion:
Thank you for bringing that up @godoal (it made me have to research what happened, and when TobinTax moved from the Market module space). A bit obscure to be sure. The documentation for columbus-5 needs a little update on that point.
So, all that to say, even though the TobinTax is still used by the Market module, the parameter lives in the Oracle module space now, in the key Whitelist (one tobin_tax parameter for each “stable coin”). The TobinTax parameter can be viewed here:
I hope you have an awesome day today
Truly excellent detective work @aeuser999 
That means the below is of no concern any longer as it’s inaccurate.
P.S. In light of that; We really need our chain documents updated, maybe work for Q4!
Fyi, from the TR Agora forum:
3 Likes
A few days in and apart from freak days where we burned 300+ million on chain this seems to be working well.
Working well. Good job
2 Likes
Well we are now a bit into this.
Where is the volume loss tax haters said there would be?
The community pool is up, the OP is up and burns have increased from 15-20mil a day to 50-60mil a day and clay reports that the other day we burnt 600mil and put around 120mil in the community pool.
It’s clear now that the 1.2% tax was taken away too fast and it was a knee jerk reaction to the whole market going down and suffering in the bear.
This was the data I think we needed.
Does it need increasing again? Honestly I’m not sure, but I think at the very least we need to reflect on the missed opportunities, burns and funding the community wasted over the last…6 months or whatever it was.
The factions and infighting in this community could be the end of it.
As parity fast approaches we need to support more than just simply bring each other down.
With the burns now working better, parity, utility and repeg should be the focus. NOT just focused on one of these things. But all of them.
This is hands down the best prop and situation that makes me feel positive again about the LUNC coin which I haven’t felt since the crash and bounce.
Excited to see what Dflunc brings to the table next and everyone else
2 Likes