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

@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???

Hi :slight_smile: Greeting from a member of Terraswap

It’s surprising that contract execution occurs only 5% of the whole txs.
I value overall tax exemption on contract execution, but its side effect should be checked in advance. If the tax exemption includes a nested MsgSend call on the contract, contracts wrapping a plain MsgSend will be popular and do harm our tax burn wave.

5 Likes

Hi @StrathCole - thank you for your detailed feedback.

For the sake of simplicity, I’m going to breakdown your argument into 2 major points:

  1. The implications of this if Binance whitelisting proposal goes through
  2. Tax sensitivity to bigger wallets (1B+ LUNC)

1. The implications of this if Binance whitelisting proposal goes through

Even if the tax income drops by ~20% (MsgSend transactions), the share of contract executions will will rise to ~3.7% (instead of ~3%). This is still an insignificant number and doesn’t change the outcome of the proposal. The pros still outweigh the cons.

2. Tax sensitivity to bigger wallets (1B+ LUNC)

So if I understand this currently - ~14% of the MsgSend volume came from 1B+ wallets when tax was 1.2%, while ~16% of the MsgSend volume now comes from 1B+ wallets when tax is 0.2%(!)

And correct me if I’m wrong here, but I’m just gonna take a step back to state this:

By reducing tax from 1.2% to 0.2% (6X reduction in tax), we ONLY gained an additional 2% in MsgSend volume from 1B+ wallets!

This would actually indicate the reverse of what you are saying - Big wallets are in fact not sensitive to tax that much.

Conversely, dapp users are much more sensitive to tax which is what this proposal aims to exclude - resulting an overall net benefit to the ecosystem.

Thanks for this feedback and this is a very valid concern raised by others in the community as well.

The solution to this is to whitelist the dapps rather than completely excluding contract execution taxes from a code level. This was discussed in my previous post. Sharing it again:

5 Likes

@lunc_nymph
This comment better explains it. Even if we exclude the smart contract transactions from the tax, in the long run, by making it cheaper to run a contract, we also encourage “volume” in the form of MsgSend, which will be subject to the tax. Essentially, the exemption will do what the proponents of the 0.2%(falsely) claimed the 0.2% tax will do.
Except this time, we will be able to encourage volume to dApps without breaking them due to high taxes on smart contracts and also be a liberty to raise the tax on MsgSend transactions.

2 Likes

Based on the metrics provided by @godoal, only 3% would be the impact on the current burns but it would encourage much more build on LUNC for adoption.

2 Likes

Looking forward to voting YES on this proposal.

2 Likes

Only one proposal to reduce the amount of tax for burning, which in the end does not lead to anything good! The tax system only works well when everyone pays!

So, it turns out the Binance wallets contribute very little to our CP and about 10% to the “conventional” burn since they have been consolidated. Before consolidation, they were contributing around 35% to our burn on the sample day used.
Also, MsgExecuteContract represents less than 2% of the CP funding since Binance consolidated its wallets. It was 33% when all Binance Wallets were active on the sample day used.

Fyi, I have taken three random days as the point of analysis and tried to capture both the burn and smart contract contributions of the Binance and all other wallets so we can see all the pieces in the chessboard and have a better understanding of how future changes will probably affect us. More specifically, one day before the Binance wallets were merged, one after they (Binance) started using only the merged wallet, and finally, one where they (Binance) were using the merged wallet but with our new fees model.

Please find excel supporting evidence

, and database scraped source data.

Feel free to dig in and make your own discoveries…

2 Likes