[CODE v1.1.0] Optional Feature # 3 - Burn Tax Split to Community Pool

Technical Development
1

Introduction

Given the status of the signaling proposals, we would like to begin the discussion around the software features to be included in the next release (v1.1.0). This discussion is around the implementation of Optional Feature # 3 - Burn Tax Split to Community Pool.

Previously, the community utilized the seigniorage RewardWeight parameter to remint a portion of the burned supply to the community pool. This was confusing to many people in the community. This code explains the creation of a new parameter that does not utilize the seigniorage remint policy, but has an independent ability to directly send a percentage of the on-chain tax to the community pool. The initialization of this parameter will be 10% community pool, 90% burn as noted in governance proposal #11111, which was the consensus before the Binance requests to turn off seigniorage (and are being alternatively handled by feature #2).

Technical Code Description

Please see the following for the code that will be included for this feature.

Test Results

Test Split Tax:

  • Tests several burn tax split rates called %split_rate
  • Tax deducted from user to FeeCollector (first check to see if FeeDecorator has the correct tax amount)
  • Check the transaction to BurnTaxFeeDecorator
  • Check if Community Pool has the amount of tax*%split_rate
  • Check if Total Supply has less amount of tax*(1-%split_rate) than that in the beginning (since tax*(1-%split_rate) is burned)
  • Check if FeeCollector has zero amount (since 100% tax is sent to Community pool and Burn)

Burn Tax Split Governance Test

  • Setup a node
  • Submit a param gov to change BurnTaxSplit
  • Output BurnTaxSplit before and after gov vote

Upgrade Check: core/upgrade-test.sh at main ¡ classic-terra/core ¡ GitHub

Ensure that state migration in x/treasury module works

Governance Parameters

This is a parameter change proposal that can be controlled in the following way,

{
“subspace”: “treasury”,
“key”: “BurnTaxSplit”,
“value”: “0.50000000000”
}
5 Likes
2

Support Binance request 100%.

2 Likes
3

@ek826 Excellent work Ed and the L1 team! Thank you!

2 Likes
4

@ek826 any comments on this: Signaling Proposals around 3 Optional Features in the next release - #8 by dfunk

Basically the idea is to split the burn tax to the distribution module instead of CP, from where it is already split 50% to CP. The reason for doing this is to also incentivise stakers due to the depleting Oracle Pool.

2 Likes
5

Very good.

6

Hi @dfunk do you feel like this is really necessary? There is a much more direct way to achieve this by use of gas fees. Having the burn tax pass through the distribution module, which has another parameter, is quite confusing. For example, if burn tax/ cp split is 90/10, and distribution module cp/stakers is 40/60 then to compute the final staker contribution would require chained calculations.

Also then changing the distribution module would have upstream effects on 2 dependent variables. Wouldn’t it be more simple just to say if you would like to increase staking rewards, then increase gas fees?

1 Like
7

The transaction type that generates the maximum amount of gas fees is MsgDelegate transactions. So to get a higher staking APR we don’t just need an increase in gas fees but also an increase in delegations. Given that our staking ratio is only ~14%, we have lots of room to grow (for instance Terra 2.0 staking ratio is ~48%).

We need to offer better incentives to stakers to increase delegation (especially given that the Oracle Pool is depleting and does not generate income due to disablement of market swaps). Splitting the burn tax to the Distribution Module will ensure that there is funding for both stakers as well as for CP for development.

There would be a total 3 variables actually that will define the overall economic policy on the chain:

  • Burn Tax Rate - currently at 0.2%, increasing this would generate more funding for the overall chain (there is already a proposal to increase this to 0.8%)
  • Burn Tax / Distribution Module Split - Can start with 80/20, 80% burn, 20% to the Distribution module
  • Distribution Module / CP Split - Currently set at 50/50

If we are able to incentive stakers and increase our staking ratio, performing these calculation would be the least of our worries :slight_smile:

Moreover this ensures a broader alignment with the community making sure both CP and delegates are funded.

Screenshot 2023-02-18 at 11.40.38 PM
Screenshot 2023-02-18 at 11.40.38 PM1156×1388 145 KB

Given where our staking APR stands today in comparison with other cosmos chains and given the fact that our staking APR is constantly reducing, diverting a part of the burn tax to distribution module will be needed sooner than later. Since this feature is already under development, it would make sense to have this in v1.1.0 only.

Let me know your thoughts - thanks!

1 Like
8

Thank you @ek826 and @dfunk , I just wanted to give my opinion on this.

If the 0.8% passes a 75%/25% gives us nice flat figures of 0.6% burn 0.2% CP. Ease of figures is a valid factor to the community, especially when something is parameterised.

This 3x our burns and 2x our dev funding (from 50/50 of 0.2%).

But we do absolutely need to fund the oracle rewards pool. Dfunks idea would be for example using my figures, 0.6% burn, 12.5% CP, 12.5% oracle rewards pool (0.1% and 0.1%). I’m okay with that.

But I wanted to point out the other available alternative is a parameterised CAP on the community pool which overflows 100% to the oracle rewards pool.

This is my preferred option which lets us fund dev 100% to the CAP as this is a high priority, the CAP can be changed if higher or lower need arises, and all overflow is to oracle rewards pool.

Thank you both.

1 Like
9

Hi dfunk,
thanks for the great feedback. Let’s keep the discussion going, but given our limited timeframe for the v1.1.0, modifications that gain consensus will have to be implemented in the next version.

As for the APRs, other chains are fueled by inflation. Evmos has like 70% inflation, juno has 20% for example. The fact that lunc is deflationary and has competitive APR is quite a differentiator.

@JESUSisLORD thanks for the feedback. Is a cap necessary? If there is a desire to fuel staking rewards over CP, the distribution module/CP parameter can be changed to favor staking. Alternatively, if the CP is over funded, a community spend prop can send excess to the oracle.

1 Like
10

Hi Ed thank you for the reply.

A CAP is not necessary at this time, as we are not overfunded yet. People have different opinions on funding, but for me I don’t think we should have mountains of LUNC in the CP, but should have a certain limit.

But if and when a higher tax is approved, we are likely to see CP funding rates higher than 0.1% from on-chain tax, plus our gas fee contribution of 50% will cause the CP to climb rapidly. At a 0.8% tax and if 25% goes to CP (0.2% it’s around a 1.5B funding rate per month).

In that event, rather than needing to process governance votes every time we want to trim the CP which is super inefficient, we can have a CAP we can adjust by parameter, which allows overflow to the oracle rewards pool.

The CAP becomes relevant when we get to the point of having a lot in the CP, so keep it in mind as an option, but is not relevant yet. I see it as a nice option to fund the oracle pool, as CP gets #1 priority to the CAP, then #2 is oracle.

Do you mean the distribution module for gas fees which is 50/50 CP/stake could be adjusted to for example 100% stake 0% CP? So gas fees alone could be oracle pool, and CP funding can come from exclusively tax AnteHandler split? Is that what you mean? Sorry if I misunderstand.

The only issue I see with that is that the CP funding rate by the tax split if the tax is raised, the CP funding rate will be much higher than the gas fee funding rate. So CP will be overweighted compared to oracle pool. The gas fee rate from what I checked recently was around 210M LUNC per month, but a 0.1% rate to CP (50% of 0.2%) brings 750M and a 0.2% rate to CP brings 1.5B per month. So it’s not proportionate. If we instead have a CAP on the CP then 100% of CP funding will also go to oracle pool at some point (when CAP is reached). I like it because it prioritises needed Dev funding to the CAP, and we have a built in mechanism for funding the oracle pool.

Say for example our CP rate was 0.2% from the tax. After a 6 months, despite L1 costs, accruing on average 9B - 2B for L1 we have 7B in the community pool depending on volumes. Maybe LUNC is worth a lot more by then and we don’t need so much in the CP, and could divert the overflow to oracle pool after imposing a 6B LUNC cap for example. My idea of the cap was 2 to 6B LUNC. Whenever a spending prop is made, the pool immediately starts filling to the CAP. When no spending is needed, all excess flows straight to the oracle pool so we hit it with a big funding rate to really help it long term.

I think at this time it doesn’t apply but reconsider if our CP grows fast with a bigger funding rate. I support a bigger tax so we can get more burns but also more funding for both CP and oracle pool.

I am happy for you just to hear the idea and think about if it will be relevant later. I am thinking of LUNC’s long term even years later, being deflationary and having competitive staking rewards is one of the biggest benefits to our chain. I hate those inflation taxes on other coins. If we stay deflationary we can be a store of value, a staking haven, and be used for transactions for years to come.

Thank you for all your work for LUNC and persistence. God bless you. Christopher.

11

With regards to the Oracle pool funding. While I do see the issue emerging over time, perhaps we can explore this option in Q3 ,especially if price action does not compensate for a possible decline in APR.
Right now however, we do have a lot of funding issues , not just for L1,but a lot of items that we passed proposals on ,but we are yet to incentivize through funding. Most of them are L2 items that the community seems to have forgotten we passed via proposals and yet such items will increase in number when we reach parity and as more dApps come on-chain.
The extra funds coming from the burn tax increase should go to the CP but be used for L2 development as currently, it seems the gas fee increase an only fund L1 development, and yet we also need to incentivize L2 development as well.

12

hey ek, sure - that’s understandable

Lunc is not completely deflationary since the Oracle Pool rewards contribute to increase in circulating supply (even though total supply is deflationary, circulating supply is inflationary).

The APR in my opinion is not competitive because it’s constantly decreasing. Had it been competitive, our staking ratio would be higher - which it is not.

Incentivising stakers is key to getting volume from CEXes back on-chain.