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

[dfunk]

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

@StrathCole

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.

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)

@StrathCole

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).

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.

@terraswap_io

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

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:

@dfunk

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)