I appreciate the link, but as you already mentioned: These are potential ideas. They can and may be well-thought-out, but are not fleshed out to a degree to put them in to practice yet and, more importantly, are still not incorporated into the white paper. I think a lot of stakeholders cannot vote in good faith for this proposal.
Well, fortunately the proposal is not yet to a vote. It’s still in the feedback period. So it’s a good time to give feedback on it. There are various discussions happening in different threads about this section of the proposal.
What are the main hurdles to voting on this in separate parts?
I’m sure it’s an emotional strain on core contributors especially since governance is messy. On the other hand it seems that the end goal of the whitepaper, with some caveats, could be achieved if some unknowns within the economic engine could actually be proven out before a full overhaul of the tokenomics gets voted on.
It seems that a vote on the Scheduler and Allocator would pass. A one time issuance of 10-20M ATOM into the treasury to get the economic engine going would seem more reasonable as well. Throughout this time the main inflationary dynamics would not have to change. The treasury would be governed like the Community Pool, which has already done a decent job at funding initiatives. This is until a proper governance framework has been put in place and voted on, which would then take control of the treasury.
Once ICS has launched and we see the Scheduler and Allocator play its parts, we will have more data on revenues to the hub and how liquid staking is being used. At that point the governance framework will be in place and it should be easier to vote on new tokenomics since there will be data to back up the framework and a governance mechanism to manage revenues and potentially newly issued ATOM.
I’d not be surprised if 6 or 9 months into ICS + Allocator + Scheduler, an entirely new tokenomic model comes out of this framework with the newly acquired data. If the model proposed in the whitepaper still is the one that makes the most sense then the vote should be easier to pass.
From an outside capital allocation perspective it 's clear that a lower inflation rate is preferable but overall the main issue as ATOM ‘meme’ coin has been its lack of utility, NOT its inflation. Since there is common agreement that ATOM inflation will have to be lower in the future, a transition phase which keeps the tokenomics intact but starts to produce utility and value for ATOM holders is actually bullish mid and long term. Knowing that revenue is accruing and the economic engine is working would create a significant demand rush for ATOM as new holders would want to receive staking rewards from an inflation rate that is to be phased out.
To add to this (and thanks @NjB!) inflation can also already be capped. People don’t mind making the inflation different than what we have today. The main issue with the inflation is that after 3 years it is prospected to be 0 without knowing what we get in return.
So now starting with a model where inflation is already decreasing slowly will most likely also pass governance. And later on we can always adjust to the final form if people know better what to expect.
1 Like
Hi everyone! I’d like to thank you all for the lively and thoughtful discussion. As promised, I’m posting an update to the paper. The revision includes some minor typo fixes (s/o @Ticojohnny for finding a few). But the substantive changes can all be found in the Issuance section as a direct response to community feedback. The TLDR here is:
- Rather than capitalizing the Treasury all at once, the process will be split into 12 equal tranches, each subject to a separate ATOM vote, providing greater accountability as the social, infrastructural system matures.
- The 300,000 ATOM per month tail issuance will be directed via ATOM vote to one or more chosen addresses. For example, by selecting the distribution module address as the destination, issuance would flow to Validators, Delegators, and the Community Pool per the existing staking reward logic.
Additionally there have been a number of requests for more clarity on the Cosmos Hub Charter described in the paper, which would provide additional controls on the use of Treasury funds, the relationship between the Assembly and token-holders, and many other details about the social architecture of the Cosmos Hub. You can find a very provisional draft of the charter in a separate forum post, which we hope will be taken up by the community and adapted as deemed appropriate.
Here’s the updated paper link!
Finally, because the Charter is a key element of the proposed system, we’d like to give the community one additional week to read over this document and analyse the preliminary contents in conjunction with the paper. I’ll be making a proposal containing the version of the paper linked in this post on October 31st 
. If the proposal passes, it will imply that the Cosmos Hub should establish a charter. The hope is that the community can come together to adapt and finalize this document over the coming weeks, making a subsequent proposal when ready.
2 Likes
Hello Cosmos fam. This is your friendly neighborhood cryptoeconomist again. Due to some turbulence on our descent, we have adjusted our course to target a different issuance schedule.
This new issuance schedule addresses three key points of feedback: 1) funding to the treasury is too high, 2) funding to treasury should happen in multiple tranches rather than in a single vote, and 3) tail emissions should go to the distribution module, not to the treasury.
This new schedule proposed 48M Atom to the treasury (down from 55M) and for this Atom to be issued in tranches of 4M each. I created a model to show what this could look like. The model assumes that tranches are approved annually, but actual tranche approval would depend on the rate at which we as a community want to fund the treasury. Note that 100% of tail emissions are going to the distribution module, the distribution module assumes a 5% “tax” that goes to the community pool, and the security subsidy decay rate reduced from 10% to 6.5% so that it more closely trends toward the steady-state security subsidy amount. Model below:
3 Likes
Although there are great aspects such as atom 2.0 ICS, but the revenue in this not very identity, this is to sacrifice the interests of holders of the atom. And I worry about the Treasury funds use.
3 Likes
Thanks all for the lively discussion. A few things I would propose modifying in the latest proposal that I think would mitigate many of the concerns we’ve been hearing:
-
The tail issuance rate to stakers should be moved out of the whitepaper. The whitepaper proposes that issuance should transition from exponential to linear but the timing and details of that transition will require more data, discussion, analysis, etc. Voting on the paper should not be a commitment to a specific numerical reduction in staking rewards, but rather a commitment to move issuance away from the exponential regime in a manner to be determined in the future by charter/governance.
-
The community pool needs a top up. First to ensure the community has the resources necessary to govern effectively, but also to bootstrap the entire treasury and assembly system on a community controlled basis, see that is proceeding effectively, and then to ensure the community has the resources to participate in the assembly for the long term. I would propose a 4M ATOM mint direct to the community pool, before anything happens with the treasury. Would additionally be supportive of an increase to the community pool tax rate (currently 2%).
-
As already proposed in the latest version, there should be a fixed number of possible future mints to the Treasury, and each mint should require ATOM vote to pass. Only thing I might suggest is reducing the number of them from 12 to 10. Of course given these require ATOM votes, some of them may never come to pass.
In summary, the paper should not yet enforce specifics of how staking rewards will change in the future, it should include a mint to the community pool, and it should slightly reduce the total number of tranches minted to the treasury.
Would be eager to hear from folks if this kind of change would sufficiently address their concerns.
9 Likes
Sounds like a good adjustment imo. I see and feel a lot of sentiment around the staking rewards. Moving that out of the whitepaper while still giving clarity what people can expect regarding their staking rewards is a good thing.
Then it will enable people to actually look like what ATOM2.0 really entails and have a discussion on the content of the revised whitepaper. My best guess is that we are not that far out, so it can be possible to move fast.
Ruging delegator rewards, by changing them from ownership of the chain (Atom) to a mix of IBC fiat (inflationary emissions from various consumer chains), privatizes the chain over time. It funnels governance of the chain away from the community as a whole and centralizes the chain under the council’s arbitrarily subsidized entities of similar ideology with a greater proportion of chain ownership at the same time reducing the say and ownership of the community as a whole &
resulting in the reduced ability for delegators to vote contrary to the council.
a %tax to the community pool inherently reflects the performance of the council and its subsidization policy which should increase proportionally to its successfully increasing growth of the hub. It also makes it so delegators continue to be rewarded with ownership of the chain for securing the network if acquiring atom is not gate kept by the treasury.
Hi, a cosmos pleb here. I understand that under this new vision, ICS will be a main source of revenue for Cosmos stakers. Anything else? Does the Interchain scheduler + allocator duo generate any revenue, and if so, will any of that go to the stakers?
Overall, I believe a shared economy is a good and more resilient economic model. That means that Cosmos stakers need to have a share of every revenue stream of the Cosmos hub, and the same goes for the Treasury/community pool.
If you’re an Interchain Security consumer chain there is an expectation that fees are being used to pay for security, therefore these fees are automatically sent to the distribution module, becoming staking rewards. The Scheduler and Allocator will themselves be consumer chains, so a portion of revenues will also be sent to the distribution module automatically. However, the idea is that the remaining funds will go to the Treasury first. The Assembly (including the Community Council) will then allocate this capital so as to improve the long-term welfare of the Cosmos Hub and ATOM. This would include sending Treasury funds back to the distribution module if deemed the best use of capital.
2 Likes
Thanks for the response! I appreciate the effort from you and everyone else involved in the process.
This reminds me of the Hamilton/Treasury moment in the beginning of the US history. The Republic will not survive without a strong federal government with a deep war chest. On the other hand, rebels certainly do not want to end up with a dictatorship. How to proceed from here? The whole Cosmos community needs to take time to figure it out. Hoping to settle this extremely complex and delicate issue with just one vote is a fantasy. Everyone needs to be mentally prepared to go through many iterations until we find the perfect balance.
1 Like
Hello and thank you for this proposal, however: 100% of the issue after 36 months allocated to the treasure, and 0% to the stakers seems very excessive to me, why such a clear ratio? Compromise is often better accepted. For now my vote will be no .
removing Atom issuance to delegators privatizes the hub under the treasury and takes ownership from the community. the Atom 2.0 proposal moves to replace community ownership of the hub by replacing Atom delegator rewards with consumer chain emissions. Turning the treasury into the gatekeeper of hub ownership & is headed by a council that distributes that ownership to themselves and developers they feel share the privately owned vision of the hub or can grow the ecosystem. I doubt it would take 36months to organize a cohort of validators to form a supermajority stake to overcome dissent through veto if such a feedback loop passes governance.
Hi Everyone,
I’ve made a new draft with the changes mentioned in Ethan’s post above. To reiterate:
- There is no precise commitment to tail issuance at this time, it is left for community discussion within the Charter.
- The Community Pool gets a 1-time mint of 4M ATOM.
- The number of tranches minted to the Treasury is reduced from 12 to 10.
All of these changes are to the Issuance section. The only other addition is a single line requested by Hyung Yeon Lee of @bharvest, which is to the Assembly section and reads: “Prior to final budget proposal, the Cosmos Assembly must give ATOM holders the opportunity to provide positive signal on budget subcomponents.”
Expect an on-chain vote on October 31st!
10 Likes
Really appreciate the improvements made.
So the choice here still would be to vote on 1 big proposal instead of breaking it down into several different proposals? I think it would be risky since there are lots of changes and one may not agree with all. Or will it be covered by the Charter?
This signalling proposal will include the version of the paper posted above. However there will be a subsequent proposal with an initial version of the Charter, and numerous proposals following with specifics, refinements, additions. The way I would think about this proposal is it tells core teams to do the following:
- Work on the gov upgrades required for the Councils and Assembly
- Work on the stated issuance for the Community Pool and Treasury tranche system
- Begin the R&D process around the Scheduler and Allocator
These will have subsequent proposals for directional approval/budget, and eventual upgrade proposals at a later date.
This proposal will also signal that the Community should:
- Continue work on the Charter
- Begin forming the Council and Assembly organizational structure in preparation for the required on-chain facilities
- Engage core teams to discuss and refine the technical components develop more robust social processes, eg. reporting and budgeting
Without this signalling proposal core teams have no mandate to work on anything apart from liquid staking and interchain security.
3 Likes
Cool! Super clear.
This proposal will only cover the ground, but for the details, we still need to work on it together with the Devs and the Community.
I believe this should be made very clear when the voting is on, so there will not be any miscommunications.
Thank you.
Going to repost in this topic
1 Like