New Economic Policy for Terra Classic: Set of 4 Proposals to Align Incentives

[Tynos]

This is a bit of paradox…The more price is going down the more funds we need for devs because they are paid based on $ value not LUNC value. This topic will be a never ending story.
At some point if the price is going down the rabbit hole I guess paying devs become irrelevant because LUNC itself becomes irrelevant.

In other projects that I worked as collaborator I was paid a fix amount in that coin, not in fiat money. I don’t understand why Lunc has to be different.

Regarding Ed’s calculations I don’t know what to say…I’m not a programmer but I know he was completely wrong when he posted all those charts based on machine learning stating that lowering the tax rate will bring lot of volumes.

You could be the best programmer in the world but it doesn’t mean you are a good business analyst, economist, etc

[Korek_Aksosek]

(the amount of luncs in CP(now) + the amount of luncs that will be added in 2 months) x the price of luncs IN 2 MONTHS (no one predicts this neither Edward Kim nor me nor any machine) If the price goes up good if it goes down then we have end because it’s already bad

[Korek_Aksosek]

I’m not even talking about OP. I think the validators see what’s going on. If they can’t count such simple things, or don’t want to see them, they shouldn’t be validators.

[petes-fan-club]

potentially.
Pholuna, and rexx seem to be gathering support

[wagnerdalcin]

You have my support, too

[Seany22]

Support for this looking good. I’m pleased. Just make sure the Dapps are properly whited.

Apart from that well done so far.

[notat9963123]

Hi ! maybe you can see this post.

Certik audit for dflunc

Hello mr nikos, dflunc is deflationary protocol with the aim of reducing luna classic supply. Their source code is open source and you can find it on their Twitter page pinned tweet, here’s is a link to the Twitter page: https://twitter.com/DFClunc?t=Ucc-Q-JJQSd1kVx2xfpKdw&s=09 For evidence here are tweets from known luna classic community members: Strathcole: [Screenshot_20230510_125022_Twitter] Happy cat crypto: [Screenshot_20230510_125118_Twitter] Lbun: [Screenshot_20230510_125006_…

[Ana]

unfortunately human beings are too stingy to trade with “high” rates for a better future of the currency and burn, it would be better not to increase these rates and in adding new ways to introduce the currency in stores, online stores, crypto games and betting games and encourage the use of currency , to help burn

[Korek_Aksosek]

That’s true. However, over the last year nothing has been built that would actually help us. And the w chain is on the verge of what I call the PRICE DEATH SPIRAL. If this is not implemented, it predicts about 4-6 months to this event. If something is actually built and adds value to the chain, I will personally make a proposal to lower the tax. Until then, you need to keep the chain alive.

[PastelRanger456]

my vote is yes for all of these

[grass_haha]

Strongly disagree on No.4, this will open the floodgate for smart contract to be exempted from taxes.
If No.4 passed, even if dapps build back on LUNC and people started using them, it will generate a lot less tax / burn than current situation as these activities on chain will not be taxed.
Furthermore, the limited income source for community pool currently for tax will be stripped away.

This also creates further unnecessary questions about which dapp contracts should be whitelisted and why other dapps should not be in the community.

[JESUSisLORD]

@grass_haha

This also creates further unnecessary questions about which dapp contracts should be whitelisted and why other dapps should not be in the community

According to dfunk’s prop for the smartcontract exemption it’s exempting the following:

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

• MsgExecuteContract
• MsgExecute
• MsgInstantiateContract"

This would apply across the board, not isolated to a particular dapp or dapps, as far as I am aware. From his thread he reported:

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

I suggest you review the prop specifically [Proposal] Exclude Smart Contraction Transactions from the scope of Burn Tax as it’s not detailed in this thread the particulars, and you can update your comment if suitable.

[dfunk]

@JESUSisLORD

This would apply across the board, not isolated to a particular dapp or dapps, as far as I am aware.

There was a loophole with this approach as highlighted by a member of the Terraswap team. As a result it was decided that it would be better to whitelist dapp contracts (similar to Binance whitelisting).

This has been discussed here:

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

Hi @StrathCole - thank you for your detailed feedback. For the sake of simplicity, I’m going to breakdown your argument into 2 major points: The implications of this if Binance whitelisting proposal goes through 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 insignific…

And also here:

[CODE v1.1.0] Optional Feature # 1 - Wallet Exemption to On-chain Tax

yeah the impact is not much but the possibility of it creating a loophole in the burn tax exists, as also pointed out by a terraswap team member here: [Proposal] Exclude Smart Contraction Transactions from the scope of Burn Tax - #69 by terraswap_io whitelisting contract executions seems like a better option from an implementation perspective. is this something that can be considered in the next release?

And also here:

@dfunk

The 130 validators are all the supervising committee that we need. Whitelisting of dapps can be done via governance proposals the same way Binance whitelisting was done.

[JESUSisLORD]

@dfunk

There was a loophole with this approach as highlighted by a member of the Terraswap team. As a result it was decided that it would be better to whitelist dapp contracts (similar to Binance whitelisting).

Thank you for correcting my understanding.

What did Terraswap mean when they said this? Could you explain this for me? Quote: “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.”

So this means basically each dapp would apply by governance to be added to the whitelist and approved or rejected by vote? Something like this?

[dfunk]

What it means is that a wallet to wallet transfer (MsgSend) could be wrapped by a contract execution (MsgContractExecute) and so if MsgContractExecute is exempted completely, there could be a way to bypass the burn tax (wallet to wallet transfers) via contracts.

Which is why a whitelisting process was selected to avoid bad actors trying to bypass the tax.

[JESUSisLORD]

@dfunk

What it means is that a wallet to wallet transfer (MsgSend) could be wrapped by a contract execution (MsgContractExecute) and so if MsgContractExecute is exempted completely, there could be a way to bypass the burn tax (wallet to wallet transfers) via contracts.

Which is why a whitelisting process was selected to avoid bad actors trying to bypass the tax

Okay thank you for the explanation, I’m okay with the whitelisting option given the issues with the prior method. Is it expected that once the feature is in place, dapps are to raise a proposal on agora to be whitelisted by governance vote?

[dfunk]

v1.1.0 introduced a new type of proposal (different from a parameter change proposal) that adds and removes addresses from a tax exemption list.

@ek826

AddBurnTaxExemptionAddressProposal

type AddBurnTaxExemptionAddressProposal struct {
	Title            string     // Title of the Proposal
	Description      string     // Description of the Proposal
	ExemptionAddress []string   // List of addresses to be added to tax exemption
}

Example JSON

{
  "type": "treasury/AddBurnTaxExemptionAddressProposal",
  "value": {
    "title": "proposal title",
    "description": "proposal description",
    "exemption_address": ["terra1dczz24r33fwlj0q5ra7rcdryjpk9hxm8rwy39t","terra1qt8mrv72gtvmnca9z6ftzd7slqhaf8m60aa7ye"]
  }
}

RemoveBurnTaxExemptionAddressProposal

type RemoveBurnTaxExemptionAddressProposal struct {
	Title            string     // Title of the Proposal
	Description      string     // Description of the Proposal
	ExemptionAddress []string   // List of addresses to be removed from tax exemption
}

Example JSON

{
  "type": "treasury/RemoveBurnTaxExemptionAddressProposal",
  "value": {
    "title": "proposal title",
    "description": "proposal description",
    "exemption_address": ["terra1dczz24r33fwlj0q5ra7rcdryjpk9hxm8rwy39t","terra1qt8mrv72gtvmnca9z6ftzd7slqhaf8m60aa7ye"]
  }
}

The current version of this only includes wallets and not contracts. Once upgraded to include contracts, dapps can use this to propose whitelisting of their contracts, which would then be voted upon by validators who will decide if they would like to approve or reject the proposed contracts from exemption.

[Seany22]

This prop is passing and we are seeing volume and price move…who would have guessed eh!

Lol congratulations on returning the paperhands to our chain.

Fingers crossed over the next few days

[wagnerdalcin]

@Seany22

This prop is passing

Congrats, @dfunk

[Jasmine_Aurora_Olivi]

Wouldn’t it be a mental barrier to future devs because each one would have to make a proposal first and hope it will pass, before whitelisting? Making them reluctant to join the chain. This is such bad timing right after parity is achieved . Isn’t there another way to make them automatically whitelisted without any loopholes?