Cap on Communitypool with burn mechanism

The community pool is now around 3.4 M Atoms which is around 30 M Usd. I want discus and feel the waters in the community for a 4 M Atom communitypool cap. Every time a project is funded through the community pool, the pool gets replenished to 4M Atoms.

The excess Atom above 4M can get burned. This way there will always be enough Atoms in the community pool for spending and the excess will directly to the benift of all Atom holders by reducing inflation.

With a 4M Atom cap the Usd value @5 Usd/Atom = 20 M Usd
With a 4M Atom cap the Usd value @10 Usd/Atom = 40 M Usd
With a 4M Atom cap the Usd value @20 Usd/Atom = 80 M Usd
etc.

Even @ 5 Usd/Atom this should be well enough for funding purposes and the pool will be refilled to 4M.

Cap amount can be lowered/raised by further proposal from the community. pls discus if you think the cap should be higher or lower than 4M Atoms to start.

pros:

  • reduction of inflation
  • community pool will not grow to excessive amounts that will induce money grabs
  • good for marketing: “Cosmos is burning Atoms!”
    etc, pls discus/ideas

cons:

  • pls discus/ideas

I am not a developer and I have no idea if this is difficult to code. But it seems to me this is not a major coding problem. pls comment/ideas

I hope to hear ideas and input from the community, best wishes for all Atom holders :slight_smile:

add 1:
Goals:

  • reduce inflation
  • prevent community pool to increase to excessive amount while keeping a very healthy budget for funding

This discussion is NOT about: bigger issues on how to spend community pool funds, what to fund or what not to fund etc.

2 Likes

Certainly not the worst idea of all time, but I would suggest that we maybe limit the pool size to either a portion of staked supply or a portion of outstanding supply since we are still pretty inflationary (20% per year approx)

wdyt?

Yeah, that is a good suggestion. Supply now is around 350M Atoms according to Mintscan and growing, so I think a communitypool, for simplicity sake, of 1% of supply would be very reasonable.

Portion of staked supply would be more difficult I think because that can change very quickly and dramaticly as we have seen not so long ago. Percentage of total supply is more stable/predictable.

The beauty of it is that the mechanism for filling the communitypool stays the same so it will be replenished every time after there is a spend the same way it is filled now.

Thank you for your imput. I know that you can code, would a 1% of total supply community pool be difficult to code ?

1 Like

Not really, but I think that that number is probably too low. Oh actually 1% aren’t there like 350m atoms right now?

I think that this is relatively painless to code.

1 Like

Personally, I do not see the benefit of a burning mechanism for funds that go into the community pool. This is effectively just adding complexity for an outcome that can be more easily reached via other paths (burning just minted tokens = reducing inflation). If that is the desired outcome, it would make sense to adjust the community pool tax or reduce inflation based on the desired result.

It sounds like the root concerns here are:

  • inflation reduction
  • better collective management of community pool funding

However, rather than either of the above, I would rather see more effective ways to manage community pool funds that 1) are directly correlated with the Hub’s product-market fit or 2) diversify the treasury or 3) bootstrap consumer chains + generate yield or 4) fund important work for the Hub.

I’ll emphasize again that the core issues here are not solved by a community pool cap or arbitrarily burning community pool ATOM, but by finding better ways to manage the resources and parameters that we have at our disposal to drive value and growth of the Hub.

Thanks @Pookybear for the thread, i’m sure it will be an interesting discussion.

2 Likes

why burned ? we can return this excess to the stakers ?

2 Likes

its a good prop, burned or distributed… all good IMO.
yes for me

3 Likes

@ala.tusz.am Thank you for your input.

I agree that ¨1) are directly correlated with the Hub’s product-market fit or 2) diversify the treasury or 3) bootstrap consumer chains + generate yield or 4) fund important work for the Hub"
are indeed very important points in the wider discussion on how to manage the community pool. I know looking at the recent history that there are many different opinions in the community about what to fund and what not etc.

But I want to keep this discussion away from that.

This cap/burn mechanism is a relatively technical and neutral measure where I think a majorety of the community can agree on. The bigger and core discussion I think deserves a seperate preferably well structured exchange of ideas. These bigger issues are not solved here, you are correct.

The idea to reduce community pool tax is interesting. But that would affect the rate at which the community pool would replenished after a spend, so in my opinion that would not be an ideal solution. I want to invite others also to discus this point: community pool tax reduction vs burn. Very interesting :slight_smile:

Following your input I have added to the opening post the goals and scope of this discussion for clarification. Thank you :slight_smile:

1 Like

@Guinch_Roze thank you for your reply :slight_smile:
Burning and distribution will both solve the problem of the communitypool growing to ridiculas amounts. But I think that burning has the additional benefit of reducing inflation.

good prop! I’m in support of anything aiming to increase sustainability.

My main concern with this approach is similar to the one mentioned by ala.tusz.am. Capping the community pool and burning an amount after a threshold might yield a variable inflation rate depending on the spending activity of the community pool. It might also incentivize spending on a shorter time frame reducing the quality of the funding outcomes.

I’d recommend a simpler method of combating inflation that would lead to a more predictable reduction. Reducing the community pool tax would help balance this.

Another option would be to spend more from the community pool in a way that doesn’t introduce sell pressure and strengthens ATOM. An example would be providing liquidity with community pool funds on protocols that are ATOM-alligned. Providing ATOM liquidity owned by the HUB to pools can help mitigate external sell pressures while earning revenue back the the HUB.

The community pool can be the cosmos HUB’s strongest tool in reaching PMF if used properly

5 Likes

I agree with this pov strongly.

2 Likes

@nicholas Thank you for your input.

So, instead of burning after 4M is reached we can reduce community pool tax to zero at that point, untill a spend after which the comm pool tax resumes to current %. till comm pool reaches 4M again. Yeah, I think this would achieve the goals. Nice :slight_smile:

@ala.tusz.am I was mistaken in my previous response to you that a comm pool tax adjust would affect the replenish rate. That is not the case when we can just turn the comm pool tax on/of @ 4M Atoms.

Maybe this is a bit more difficult to code?

1 Like

The number is seemingly arbitrary. I think it’s probably possible for a community pool to be “too big”, though everyone’s definition of that will vary depending on their vision of what community pools should be used for.

I think with the AEZ being a focal point, the hub needs a war chest to fund it’s initiatives in that regard, in addition to whatever else Cosmos needs from the hub. So, imo, it’s too early in this new phase of the hub to be capping the pool, especially in an uncertain macro environment. For all we know, crypto could be due for even longer in this bear cycle and Atom could be sub-$5, and the community pool will look nominally small in that case.

1 Like

@tknox35 yes, this is true. The number is arbitrary. The cap of 4M is definitely a point of discussion. With the arguments you give a cap of 5M for example would be better maybe? It is definitely a good idea to have a healthy war chest. What would you concider a good cap? Maybe others can give some thoughts about the amount that would be suitable?

On the other hand, every time a spend from the comm pool is made the pool will be replenished so, even @ 5 Usd/Atom we would still have a healthy 4x5=20 M Usd comm pool. And the size of the cap can easily be ajusted up or down by future props when nescessary .

If/when crypto/Atom goes on a bull run or SEC loses agains Ripple or China and India start buying for example Atom can easily go to 30 usd. Then we would have a comm pool of 4x30=120 M usd. That would maybe be excessive for funding Hub development I think because it also gets replenished after a spend.

We also have to remember that the comm pool is not the only fund for Cosmos development. Cosmos foundation for as far as I know does not have a cap and funds Hub maintenance and development also.

You are right. The cap amount is dependant on the definition of what you want to fund with it. I think it would be very good if both funds would have clear definitions on what they fund and not fund and that there is no overlap between those. But this is a much bigger discussion. A cap on comm fund in place can maybe/ hopefully also trigger the discussion on clearly defining both comm pool and foundation funds. That would be a BIG bonus indeed, but is not my initial intention here. This discussion about defining funds needs a fundamental and well structured exchange of ideas. The initiative for that I think should come from foundation/devs/validators, not from me. It is, although related, out of the scope of this discussion here. I think it will be possible to establish as a community a reasonable workable amount (which is ajustable by further props) without having defined to the detail the boundries for spendings.

I am looking for a reasonable amount to start. 4M or 4.5M or 5M or 6M? What do you think is a good amount? When you say: no cap needed now, then at what point would a cap be logical?

Thank you for your input :slight_smile:

Going to post the same reply here I left on a similar topic. Seems to be related