[Proposal] Exclude Smart Contraction Transactions from the scope of Burn Tax

Not sure about that @Kevin_Park, we did disable the seigniorage option (Prop 11242) so there’s no more re-minting taking place for third-party burn initiatives (like Binance and individuals).

What they are asking for now is to be excluded from on-chain transactions as well.

Also, those wallets look surprisingly like end-user (though I saw a validator as well) wallets:

1 Like

What do you mean by mechanism? A lot of smart contracts use MsgExecuteContract transactions. The volume is low now is because we don’t have many live Smart contacts but it doesn’t mean we will not have many more in future. A foreward-looking approach is better than just analyzing history data only. My personal opinion only.

2 Likes

The mechanics as in, “we allow the engine of the dApp (the smart contract) to operate without blocks (tax) in place in order to reap the higher rewards of what the contract does”, meaning the MsgSend.

The scenario I have in mind, and please correct me if I’m wrong, is that of a DEX. The buy/sell/swap action is called all the time (high-speed bot trading) and it’s based on contract execution, but the actual taxable value out of this is the amount bought/sold/swapped at the end. At least that is what the evidence (in this proposal) points to…

Still need to do some checks on those Binance wallets and cross-ref with the usual daily traffic (a day before 2022-09-08 will do). That might yield some info that makes this prop not worth going forward with because of that future Binance exception work :expressionless:
As always, we need data and evidence to make the most informed decision…

1 Like

Burn tax is an economic policy that needs to be adjusted basis demand/supply. Considering LUNC supply maybe higher than its demand at the moment, I would be in support of raising the burn tax.

Having said that, I personally feel that the target rate of the burn tax should be 0.35%. This is basis the Tobin Tax, which the burn tax has been re-modelled after. However, this is just my personal view, and since this is not what I am proposing with this proposal, I would appreciate if we do not digress too much into this at the moment.

The bigger issue is that a dapp user shouldn’t be expected to pay both burn tax and gas fees as it becomes economically unviable for the user. Given that dapp contract executions only account for ~3% of the burn tax, it makes no sense in having them for those type of transactions - which is what this proposal aims to solve.

3 Likes

Even if this is the case (which hasn’t been substantiated), the burn from MsgExecuteContract would still be ~6%. Compare that to an increase of burn tax to 0.3% (50% increase), or 0.35% (75% increase) and you can clearly see the benefits of removing the burn tax on MsgExecuteContract transactions outweighing the cons.

1 Like

@dfunk Development will have to be set in only one direction.If smart contracts are tax-exempt now because >3% now, all future dApps will be designed based on tax-free.This means that taxes cannot be applied again when the usages of smart contracts increases.
Specific examples of what difficulties this proposal should be passed should be given. You’re the only one who knows what kind of project you’re working on. Other developers are possible, but if you’re impossible, that’s your problem. There is a reason why others refuse.

@godoal perseek already explained why Binance’s Wallet Usage and Whitelist were used. You should refer to the data of better analysts than you. He is committed to the community for free. And just because you’re not on the TR team doesn’t mean you’re not related to them. Your incitement is obviously related to Vegas’s recent mention of a 1.2% tax rate after being inactive for more than a month. And refrain from using spam & abuse accounts. No one opposes a good proposal. There’s a reason why there’s a controversy.

1 Like

That is correct - but usage of smart contract will not increase if a user has to pay both burn tax as well as gas fees. With my current solution, the overall burn amount could increase by 50-75% (by raising burn tax), while sacrificing 3-6% of the burn tax - the net result would be more burns.

Also, not all dapp transactions would be excluded from the burn tax - MsgSend transactions would still continue to pay tax - so an overall increase in dapp transactions would still ultimately result in more burns via wallet transfers.

Also, I’m not sure if you’ve seen the latest announcement by Binance but you should take a look if you haven’t already: https://www.binance.com/en/support/announcement/binance-will-support-the-terra-classic-lunc-network-upgrade-936229a46dfb4b78abe0b80b20174ba5

Binance has supported both Proposals 11242 and 11243 which were authored by me with inputs from @godoal .

Your feedback and constructive criticism is welcome but would request you to look at previous proposals and their benefits to the community before making baseless allegations.

Your argument is a contradiction. The reason why they update the core of LUNC is because LUNC is listed in binance. It’s a completely different matter for them to support core update and support prop. Distinguish between technical and ideological support. And this update has nothing to do with this proposal. Binance’s announcement of the suspension of burn was made after the proposal was passed. They decide by looking at the results after the proposal is passed. If you want to instigate, please use a proper fact.

Point taken. I have nothing further to add to your comments other than the case that has been presented. Thank you for your inputs and the constructive criticism. Have a nice day :slight_smile:

Thanks for the info, it’s definitely interesting material and fills some gaps. The point am investigating is slightly different though and is closely related to the long-term viability of this proposal.

I am related mostly to everyone you see, talk to, and (some) admire from the old guard, not just @Vegas. I still want the tax to be brought back up to its previous levels until a better burn solution is in place…still waiting for that swaps activation.

You keep repeating the same story; I’ll say it once again, I have only one account and it’s the one am writing to you now, and its been since I joined the revival of the chain effort…I have no interest, or the time, in playing around with unnecessary chatter. I’m after effective solutions to take away our problems. And yes I have skin in the game since I am a delegator myself so anything bad happening to the chain will affect me as well.

Thanks for that didn’t know about it :slight_smile:

1 Like

A hard no for me.

This relies on having the same volume with a higher tax. But we will most likely see another drop in volume as soon as tax is raised, even if it is “only” doubled.
Especially High-Volume users are quite tax sensitive.

A heated discussion is a good phenomenon, but it is better to refrain from slanderous comments. Decentralization begins with respect for diversity.
I couldn’t read all comments. But I understand that it is largely divided into two opinions.

Exclude tax from smart contracts could provide a better environment for developers. However, the issue of fairness arises. A non-developer might think it a privilege. You don’t have to blame them for not understanding the development. 95% of investors are non-developers. Their opinions should also be respected.

This proposal has faced many objections because there are no results or examples of targets. It’s not specific and has a big impact on the future direction of chain. If the structure of a particular development project necessarily excludes Tax from the smart contracts, we might consider applying a limited fixed-term white list. Wouldn’t it be possible to suggest a reasonable reason why dApp should be included in the white list and persuade why this dApp to provide public benefits (liquidity) to the chain?

If this proposal is one of the steps towards achieving the agenda for a particular team (ex : back to 1.2% tax burn), you can ignore my comment. :pray:

3 Likes

Why is it that whenever someone talks about a possible raise of the burn tax they are immediately affiliated with Terra Rebels? Do you know that more people than the Terra Rebels support a higher burn tax? You know the 1.2% passed with near unanimous support originally? Many community members including myself were very disappointed when it was dropped to make way for minting. Look at everyone who supported that garbage. I was shocked. The promised high volumes never appeared, it was false. We should have higher burn tax, and if dapps can be exempted as a means of achieving this then I absolutely support it. There is nothing wrong with that. I’m not saying that is the proposers intention, but I personally support this proposal for that reason, as a means to increase the burn tax. I am completely open about it. “Oh but what about the dapps” has been the primary reason for keeping the burn tax low and that reason should be no more.

1 Like

@JESUSisLORD Everyone’s ideas can’t be same. Even if you look at my proposal, I suggest tax buyback & burn, not just tax burn. The rate doesn’t matter if it’s 1.2% or 0.2% in my case.
But that doesn’t mean you need to blame the other person. A logical and persuasive proposal will be adopted. If a particular group’s political movement goes in the direction they intend, it’s also part of the DAO. We get stressed out watching political news every day in reality. This is what it is :sweat_smile:
I expect a separate inspection team to be created within the LUNC chain. We need groups that bridge the gap of knowledge between the general public and the development team and help them make the right choices. It’s like a consumer report.

2 Likes

I like this approach - whitelisting dapps from contract execution taxes only (not wallet to wallet transfer taxes) that have a demonstrable product-market fit (measured by TVL or any other reasonable parameters). There may be idealogical debate around this, but makes a lot of sense from a practical perspective.

Are there high volume wallet to wallet transfers (MsgSend) or high volume contract executions - such as swaps on DEXes (MsgContractExecute) for dapps? I haven’t seen any cases for the former, only for the latter.

1 Like

Especially it is whales or other owners with bigger holdings that move from one CEX to another or on/off-chain for liquidation or delegation.

1 Like

those are not high volume - that’s a one time transaction.

say if a whale moved 1B LUNC from an exchange to on-chain for delegation and consider a 1% burn tax on this transaction - he would be able to delegate 1B - 10M = 990M

At the current APR of 24.7%, he would be able to recover this amount within 15 days of delegation.

Sorry to say but your narrative seems to have changed from high volume to high value - and this prop seems to not create a negative effect for either.

1 Like

High volume in this context for me didn’t matter if it is multiple small tx or one big as both incur the same tax (besides gas fees) - Station also always referred to “volume” for the overall amount of moved coins, not tx count.

From December 1st, 2022 we had ~785B MsgSend overall.
125B of that were transactions with an amount of >= 1B in a single tx (45 tx from 28 distinct wallets, which does not include binance-internal tx), 186B with an amount >= 100M (866 tx from 230 wallets, excluding the 1B+ of course) and
24B of it were transactions with an amount < 1M in a single tx (257,000 tx from 26,600 distinct wallets).
What I meant is that users with big transactions are (as far as I am aware) more sensitive to tax than the smaller ones.

Also your maths don’t take into account the binance whitelisting. 202B (2880 tx) (not included in the above 785B) was from Binance-internal wallet movements (deposit → main wallet). So tax income will anyway drop by ~20% (MsgSend only!) with that whitelisting.

During the 1.2% tax we had ~215B MsgSend volume, 31B of that where tx > 1B (12 tx with 9 distinct wallets), 42B >= 100M (159 tx from 77 wallets) and 11.6B tx < 1M (102,000 from 16,000 distinct wallets).
Of course this is all speculation, but compared to the current volume (~16% 1B+, 24% 100M+, ~3% low amount) it was different with high tax (~14% 1B+, 19.5% 100M+, ~5.5% low amount).

Before tax was in place (and also before staking was re-enabled) the 1B+ transactions made ~39% of all MsgSend, 100M+ transactions ~42% and those < 1M only ~4% of the overall LUNC moved. Again, binance internal movements excluded.

This might all be completely unrelated, but my personal(!) opinion is that high-amount movements react much more sensitive to each tax adjustment than lower amount movements. As they make a high percentage of the volume (in coins, not tx) this will probably affect tax income.

So let’s say we raise tax for sends to 0.35% (+75%). Binance will probably get whitelisted if the community doesn’t want them to stop burning. Contract executions are excluded from tax. High-amount tx will get less (hopefully not much), overall tx volume will also likely go down a bit due to tax raised. I doubt we can reach a +50 to +75% in tax income.

By the way, when we talk about LUNC the numbers for contract share of volume seems quite correct, but when talking about USTC also (which has the same tax implications) it’s ~15% of the USTC volume, mostly terraswap and auto-trading I think.
Anybody can gladly check my numbers, maybe I have a mistake in there.

However this all now has drifted quite far away from the original proposal done in here as to me it seems it is highly related to a following tax adjustment so not only this proposal itself but also the implications that come with it should be taken into account.

1 Like

How exactly is Vegas, one of the people who helped revive LUNC a “stopping the progress of LUNC”
I can very much see the contributions Vegas has made to the chain, all of them positive.
What has been your contribution given you are here all pitchforks and straw???