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

Governance & Proposals
1

Summary
This proposal aims to exclude contract executions by dapps from the scope of Burn Tax.

Motivation
When the proposal for burn tax was introduced by @ek826 , the following transaction types were included in the scope of the burn tax:

  • MsgSend - Sending from one wallet to another
  • MsgMultiSend - Sending from multiple senders or to multiple receivers (taxed once)
  • MsgSwapSend - Swapping then sending to another wallet
  • MsgExecuteContract - Smart contract transaction
  • MsgExecute - Bundled dApp and smart contract transactions (each bundled tx is parsed and taxed)
  • MsgInstantiateContract - Creating a new smart contract

The transaction types related to governance, staking and swaps were excluded from the scope of the burn tax. The following transaction types were excluded:

  • MsgDelegate - Delegation of LUNC
  • MsgWithdrawDelegationReward - Withdrawing of staking rewards
  • MsgSwap - Swapping of stablecoins

and some other trivial governance and staking related transactions.

Based on on-chain data of transactions collated by @godoal , the burn tax generated in a single day by the various taxable transaction types are as follows:

  • MsgSend - 57,084,943 LUNC
  • MsgMultiSend - 0 LUNC
  • MsgSwapSend - 0 LUNC
  • MsgExecuteContract - 1,319,533 LUNC
  • MsgExecute - 0 LUNC
  • MsgInstantiateContract - ~0 LUNC

In a nutshull,

  • ~97% of the burn tax comes from Send Transactions (MsgSend, MsgMultiSend, MsgSwapSend) - particularly MsgSend transactions,
  • while only ~3% of the burn tax comes from Contract Executions (MsgExecuteContract, MsgExecute, MsgInstantiateContract) - particularly MsgExecuteContract transactions.

Burn tax on smart contract transactions does more harm than good as it drives away dapps and on-chain utility due to the additional fees and code complexity, while adding very little to the burn amount.

Pros of excluding burn tax from smart contract transactions:

  • Lower transaction fees on smart contract transactions
  • Better dapp interpretability with other smart contracts platforms like CosmWasm
  • More utility and gas fees generated for the network, which would result in more rewards for stakers and more funds sent to the community pool

Cons of excluding burn tax from smart contract transactions:

  • ~3% less will be burnt

Proposal
Should this proposal go through, the following transaction types will be excluded from the scope of burn tax:

  • MsgExecuteContract
  • MsgExecute
  • MsgInstantiateContract

The code changes for this will be implemented by the L1 Task Force led by @ek826

Note: Special thanks to @godoal for the on-chain analysis.

11 Likes
2

That’s good!Stimulate the on-chain activities.
Yes for sure.

4 Likes
3

So if there is no tax on dapps then can people stop using the argument we can’t raise the burn tax otherwise it will throttle dapps? If it’s only 3% of burns, and it frees up the possibility we can at least double the burn tax then I would support.

4 Likes
4

Yes, once dapps have been removed from the scope of burn tax, the burn tax can be increased as it won’t throttle dapps anymore. :slight_smile:

4 Likes
5

Well since you put it like that, with sensible arguments, I would say Yes.

5 Likes
6

I need to think about this some more but my initial thought is this makes sense. I know the folks at Luna Burning Knights would appreciate this passing.

1 Like
7

I don’t think that will change anything, tbh. And I am making heavy use of contracts.
It would only benefit users, not contract owners.
For example user buys an NFT:

  • User sends 1,000,000 to the contract with MsgExecuteContract which is then no longer taxed.
  • The contract internally has to use MsgSend to forward the coins to the project owner or seller. That still would be taxed.

So the user doesn’t pay tax anymore, the recipient of the money still does (or the contract). It would unequally prefer some contract use-cases above others. Either tax or no tax. But not excluding limited use-cases from it.

And I say that while I am affected by that myself as I manage ~30 active contracts on chain currently, number growing.

2 Likes
8

Aligning interests between users and owners is true to the spirit of decentralisation.

Ideally a contract owner would want to provide benefit to its users so they can use the contract - which like you said this would. The contract owner can raise funding via issuance of tokens for the dapp, which can be owned by its users and use that funding to onboard as many users as possible to get product-market fit.

Since contract executions would become cheaper for users, at least one part of the equation gets resolved. For the contract owner, the business model should be able to absorb the on-chain expenses, which might force operating margins to be lower (at this point) and so the business operation would need to rely more on scale than on margins - which again would be possible since users would benefit from this.

4 Likes
9

100% support. Essentially, we can raise the burn tax without having to affect utility.

4 Likes
10

Whit this prop in place we could increase the burn tax again to previous levels.

6 Likes
11

You are talking about projects mainly that use an own token for example. That is not feasable for smaller projects or things like a marketplace (makes no sense).
As said it would save our users tons of taxes, but I don’t think it is worth it. Binance requests whitelisting of wallets from tax, this idea exclude contract executions from tax, …
It’s like a gradual removal of the tax from chain with more and more exceptions. Either we have a tax or we haven’t.

1 Like
12

I’m not talking about specific dapps - I’m talking about having a business model for dapp owners that aligns with the interest of their users. You have already mentioned that this would benefit dapp users so there’s no argument there. Amazon (a marketplace) was unprofitable for many years until it turned profitable - the trick is in scaling to millions of users which Terra Classic has, and those millions of users would benefit from this.

If Amazon is a far stretched example, we can look at something closer to home. 70% of the TVL of Terra 2.0 is generated by Astroport, which has its own token. If a token model is better for a dapp owner, maybe they should consider that - since they might benefit more from network effects.

The dapp owner should prove its business model and product-market fit first and then assess the pros and cons of the existing on-chain expenses.

Those are specific to Binance owned wallets - I believe around 30 of them. That would not exclude taxes for users of dapps such as Terraswap or Astroport or other dapps on chain.

4 Likes
14

This prop is backdoor Reminting and against binance whitelist wallet address. And i request every major validator don’t support this type of prop because this prop is like prop - 5234. This proposal will bring too soon. We should have to wait and watch what is the result of prop - 11242 and 11243 then change something on burning and filling community pool. So think carefully before voting.

16

No, I disagree with this proposal. Don’t you know what tax means?
The reason why Binance can request a whitelist is that the amount of burn with their transaction fee is higher than the amount of burn on the on-chain.
Their demands are justified, reasonable, and consequently help the chain. And they’re outsiders. They have the right to reject the tax which decided of LUNC proposal.
Your prop is only to ask for Tax exemption privileges. It doesn’t help the chain. Rather, it will set a bad precedent. Don’t put Binance and you on the same line.
If a restaurant asks the government to exempt it from taxes in order to increase sales, should the government approve it? If so, abolish all burn tax systems. Developers are not privileged.
In particular, @Vegas who succeeded in stealing against the community snoopes back to Agora makes us question the true meaning of this proposal. I’m surprised at his impudence. please get out our space.
If your team is not capable of handling 0.2% tax, please go to another chain. There are many free tax chains.

4 Likes
17

Please explain!
That’s not even in the context (or related) to the proposal.

It will allow us to increase tax, as mentioned by previous community members, without worrying if it affects the contracts used by DEXs and other dApps.

3 Likes
18

What about having two different taxes? Contract executions being less taxed than send transactions.

19

@godoal It’s a hasty decision. Don’t try to brake constitutional law easily. Other deflation chains run smart contracts without any tax exemption. Their tax rate is more than 10 times of LUNC.
The plan for L1 task force is full until March. Let them concentrate on their work. This proposal doesn’t matter if you consider it after March.
Binance said it would monitor the chain by March 1. Don’t let them stop burning with your unnecessary prop. They’re going to decide that they don’t have to pay the burn tax from trade fee if they know that the smart contracts doesn’t pay the burn tax. they are not stupid.

1 Like
20

This proposal has to do with dApps, not Binance

3 Likes
21

It doesn’t say anything about two taxes. It excludes MsgExecuteContract from the existing taxation system. So we exclude 0.005% out of the 0.2% total tax in order to streamline how dApps work in our chain.

No it’s not, we’ve been going around in circles every time we want to increase tax because “it will affect dApps and all those contracts”. After this one No More…

The change is as simple as deleting the transaction name from a list in the tax module L1 coded. I would be surprised if it takes more than 5’. It does matter since it makes the chain contracts lean again and all its’ dApps lean again.

Please check the math above to see the scales we are talking about.
Binance’s beef (rightfully) was the seigniorage re-mint which is history as of tomorrow anyway.
After all they won’t be charged either for MsgExecuteContract transactions.

3 Likes
22

Could you please expand more on the use cases you’re running in terms of smart contracts where this type of change wouldn’t be a net benefit? We’re looking to gather more information about this matter so our delegators can make an informed decision.

3 Likes