Final Vision Plan for LUNC to $1+

Thank you very much for your idea

5 Likes

I don’t think we should stop the tax or further break it down. Increasing the tax is better in my opinion. So we increase which further decreases supply and also increases the cp while exempting dapps from tax. Seems like a good plan and I will support this.

4 Likes

I am on board with reducing supply by increasing burn tax.
Reduction in volume leads to price increase.
This is in addition to utility being created in parallel.

I suggest to keep it 1.5% off chain,just like on chain.
Let the CEXs who agree to the plan keep 0.3% as incentive and burn the 1.2%(send to LUNC burn address).This would incentivise them further to implement LUNC burn tax.

Both on chain and off chain burn 1.2% and use the other 0.3% for own purpose.
Investor would see the same 1.5% uniformly across on /off chain. Further, having 1.5% on chain vs 1.2% off chain may lead to shifting of investors from.one side to other.

1 Like

I believe if we can get the exchanges to agree, they will consider it more of a charitable decision on their part to adopt the 1.2% burn tax off-chain, I believe they won’t be interested in taking the 0.3%, as they won’t want to tax their users anymore than necessary. That’s why a flat 1.2% burn tax they apply is important, it’s historic with LUNC’s recovery movement and was wrongly abandoned after 3 weeks on-chain.

Having the higher on-chain tax of 1.5% is part of what incentivises LUNC users to send their LUNC to a participating exchange to sell. They incur 0% deposit transfer to a participating exchange as their deposits are exempt from on-chain tax. Then it’s a 1.2% burn tax to sell. For an exchange who doesn’t participate, it’s a 1.5% on-chain tax and 0% burn tax to sell, so a 0.3% difference. So LUNC users are incentivised and rewarded to use a participating exchange to sell their LUNC. This helps us convince exchanges they are preferred and incentivised, and will see them being favoured by LUNC sellers.

If we had a flat 1.5% on-chain and off, we lose the distinguishing feature between participating exchanges and non-participating exchanges.

Furthermore, we have the same burn tax of 1.2%, that’s how we can ask the exchanges to apply it off-chain. Understandably on our own on-chain movements we apply an extra 0.3% to fund ourselves including all of the needs for the chain. This is more than reasonable.

For me it’s important to tax exchanges the minimum possible who comply with the 1.2% burn tax off-chain, they need to be tax incentivised and preferred over non-participating exchanges, and there should be no bloat or extra keeper taxes as I believe exchanges will refuse them, it won’t help, and they will not want to tax their users anymore than necessary, and if they wanted they can increase their own base exchange transaction fees.

You are welcome to your view but I believe how I have set-up the plan is best to achieve our goal of the 1.2% off-chain burn tax adoption, and a good and reasonable tax and funding rate for our chain.

2 Likes

Another wrong assumption on your side. Since the user is not exempt, it will incur 1.2% when he sends to CEX wallet to trade.

The plan calls for deposits to the exchange hot wallet to be made exempt. The on-chain tax is normally 1.5% under my plan, so it should be zero when sending to them. We already have a mechanism to exempt exchange internal wallets from on-chain tax by whitelisting them, which Binance has. My proposal would be similar but for deposits only. If that is too difficult or cannot be done (I have reached out to the L1 Team about it already), whitelisting their entire hot wallet can be discussed and it would come as a separate proposal if that is the only option there. I only wanted to exempt deposits so withdrawals incur the on-chain tax, so we don’t diminish our on-chain volume much.

5 Likes

Read Ed Kim explanation again. BOTH wallets must be in the whitelist, otherwise the tax will incur. A whole new logic would have to be introduced to achieve your plan.

1 Like

Woah. Didn’t know about this. Nice find bruh.

1 Like

Thank you for the constructive comment @wagnerdalcin. I have shared this with the L1 Team and let them know and for their feedback. I have already reached out to them about the deposit tax exemption earlier, but I included the link you shared which was helpful. The tax exempting deposits is an important incentive that I would certainly want in the plan.

2 Likes

Nice to see you opening up for criticism. That’s one thing I’ve been tryin to point all along. If you do a one-side exemption, all tx to/from that wallet would be tax-free. Add DApps exemption and you have little to none on-chain tx that would be taxed. Burns on-chain would rely only on swaps.

And then you have the higher on-chain tax. One outcome would be volume being driven off-chain, that by your plan would lead to less burns. Or another possible outcome is more people staking (it’s tax-free), which would increase OP depletion even further.

1 Like

I’m open to reasonable and fair comments about my plan, and have been all along. The deposit exemption to exchanges only applies if they agree to do the 1.2% burn tax off-chain, so it won’t apply immediately but when we can secure their support. Withdrawals from the exchange to the wallet will still incur on-chain tax. Also sending between wallets will still incur on-chain tax. We only miss out on-chain tax on directly sending to participating exchanges. Non-participating exchanges will still incur the tax. But if they burn the 1.2% off-chain for us it will be more than worth it. On-chain volume rises dramatically when LUNC’s price is increasing, as I have observed during previous LUNC moves, so the pump we get from the increased burns with the 1.2% off-chain is going to offset any volume loss on-chain. This and the fact the tax is changed from 0.2% to 1.5% we will see a dramatic increase in funding rate and on-chain burns, even if there is some loss due to deposit exemption of participating exchanges. Overall it’s well worth it to do a deposit exemption. That’s why I said I didn’t want also a withdrawal exemption. When anyone wants to stake they will still contribute to on-chain volume. Overall I believe the move is well worth it.

1 Like

This is wrong dapps subject to exemption only account for a tiny fraction of on-chain volume, from dfunk’s thread:
" 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."

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

I didn’t know the reason behind these figures before this, but I guess I do now, since I had been coding some stuff on LUNC last few weeks.

You see, this is a superficial figure and I’ll explain why :slightly_smiling_face:

This is not a true representation of the apps on the chain because coders are using a function called “BroadcastTx” as the primary function for doing anything on the chain. Writing this function is faster than writing a contract and making people execute a contract. Using the BroadcastTx does the signing and sending in one transaction so all programmers are using this function instead of the ExecuteContract function.

That does NOT means that there are no apps on LUNC.

I realised this cause I used the same functions in my code also and there is no ExecuteContract in my code. Writing contracts in Rust is difficult. Much easier to use Terra.js and get something done. Only if contracts are absolutely required, do we use it.

This is a problem with Cosmos in general and how they have designed their contracts. In Cosmos coding, there are 3-4 ways of doing one thing. So, the MsgSend figures won’t give you the proper idea about the app usage.

MsgSend can be done in one step:
https://classic-docs.terra.money/docs/develop/sdks/terra-js/multisend.html

ExecuteContract is done in three steps:
https://classic-docs.terra.money/docs/develop/sdks/terra-js/smart-contracts.html

You misread my quote. It says exactly that:

  • your plan has the potential to have only MsgSwap taxed since you are exempting MsgSend based on destiny wallet (little to none);
  • and since your plan encourages sending assets to CEX (higher on-chain tax + exemption on deposits), it will greatly reduce MsgSwap on-chain.

Hope it’s clear now

Hi @arunadaybasu, my point in my plan is to exempt dapps from on-chain tax so they won’t be harshly effected by our raising of the on-chain tax.

My proposal here states that the proposal from @dfunk should be implemented to this end:

And from the prior thread https://classic-agora.terra.money/t/vision-plan-to-achieve-1-lunc/50412:

We can start there and look at what else is suitable, subject to governance.

The exemption only applies to sending to participating exchange hot wallets who adopt the 1.2% burn tax off-chain. That means we lose that on-chain volume. But we still have withdrawals from them, and ordinary other on-chain transactions. As I said in my prior post, it’s worth it for us overall to offer that deposit exemption.

Swaps within Terra Station wallet using the two DEX’s should have the 1.5% on-chain tax. If they swap from LUNC to USTC it’s a 1.5% tax. If they instead wanted to bypass this and send the LUNC to exchange to sell, they incur 1.2% burn tax fee. Then convert USDT to USTC (0.1% exchange fee). But if they don’t want to hold USTC on an exchange, and want to send back to their wallet, it will cost them 1.5% to send back the USTC. So now they’re at 2.8% tax versus just 1.5% if they stayed within the wallet. If they’re okay holding USTC on exchange it’s cheaper to swap by sending LUNC there and swap to USTC, they incur 1.3% tax instead of 1.5%, so cheaper by only 0.2%. It’s also more inconvenient to leave the wallet for swaps. There may be some volume loss there on DEX’s but it’s not likely to be much for the reasons I stated.

Overall we are looking to achieve the 1.2% burn tax off-chain. This is the whole point of the plan. If this succeeds then amazing. If we can’t succeed in 6 months we can roll back the tax changes. It’s an attempt to secure the goal of significant off-chain burns. Getting worried about possible on-chain volume losses is something to consider, but not the main point, and actually we will actually get massive on-chain volumes if we succeed in the off-chain burns (as I said, LUNC on-chain volume goes way up when LUNC pumps). You can’t say on-chain volume will be lower, because if off-chain 1.2% burn tax is successfully implemented, LUNC price will skyrocket and we will see a big boost in on-chain volume. Before then, while we have the 1.5% on-chain tax and are still pursuing off-chain burns, there is no deposit exemption in place yet. That only comes when exchanges agree.

3 Likes

@JESUSisLORD Is the plan to raise a proposal for each step and we tick it off as we go along?

1 Like

Can you share some metrics ?!?

We can back tax to 1.2%. But another points no working.
And we need pool for repeg. Any burns useless more, waste of time, no effect.

This proposal is a straightfoward and effective way to reduce the supply. We need the hype back, we need LUNC to reach higher highs. We also need to fund our CP for further development. You have my vote, thank you.

2 Likes

Yes you have mentioned this. But how are you gonna do it?

What Ed is saying is that the sender and receiver wallet both need to be whitelisted.

Which means that the user in my app needs to be whitelisted in order to ensure that the transaction between the user and me is non-taxed.

Doing this on a technical level in some apps where the wallet changes continuously might be impossible unless we have a contract for whitelisting wallets and an API/SDK along with that to continuously keep adding new wallet addresses to that whitelist.

For example if you did that with Binance, then they would need to whitelist every single account address of LUNC that they have. Which might be in millions of addresses.