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.
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!
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.
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.
Going to repost in this topic
Thanks for the new proposal Sam.
I think these changes leave more room for maneuvering the future once the governance mechanism has been put in place.
1.2 is the best revision so far. I appreciate all the work you guys are putting in despite having to put up with constant critiquing all day by plebs like myself.
Jae’s photon concept seems to be an effective solution to the monetary policy issues that arise from the changes in staking and liquidity trends. Photon also supports expansion of the ecosystem.
will the proposal only signal that the community desires the R&D process around the scheduler and allocator to begin or will it also commit us to “atom 2.0,” to a traunch system to fund and trust councils, assemblies, and dao’s to transparently administer cosmos payment for order flow?
what are the tranches funding? If funding proposals had 11 days instead of 14 days, why are DAO’s and councils or human judgement necessary?
Is seems like the whole DAO system is just to use the communities capital to rebalance their asset portfolios. “actively seek to fund incentive-aligned communities that can credibly aid in achieving the Allocator’s mandate” seems to translate to: subsidize core dev projects with atom from thin air that doesn’t count until a project holding atom as reserve currency gets over levered on the bad side of a trade, or exploit, etc.
the shell game DAO structure and all the “guarantees” flying around in the allocator part of the WP is broken. it reads as if you are proposing that the hub create portfolio DAOs and facilitate insider trading between chains through those DAOs via a third party beneficiary…
what does this proposal signal to be an acceptable % of founders, developers, and early investors of that third party beneficiary can safely occupy within the councils and assembly?
Thanks for all the hard work to mitigate adjustment requests from the community. After having meaningful discussions and following modification, I believe the current ATOM 2.0 whitepaper is fully agreeable from the community perspective. From my own viewpoint, let me summarize core modification from the original white paper as below:
- 4M community pool issuance
→ The community governance should have the authority to approve suggested Treasury and Assembly structure.
- 4M * 10 tranches issuance to Treasury
→ Cosmos Hub Charter approved by governance is the condition for 4M*10 tranches issuance.
→ Each tranche issuance should be approved by governance.
- Safety measure for decreasing security subsidy
→ Suggested safety measure protects dPoS security of Cosmos Hub when the decreased security subsidy fails to incentivize enough staking ratio.
→ Decreasing with fixed percent has too stiff speed in early period where the new revenue is relatively uncertain. I would like to recommend decreasing with fixed amount of ATOM so that we have enough time to evidence enough revenue before security subsidy level becoming too low.
- Each budget subcomponent should be approved by the community governance
→ This process allows community to express their opinions about each separate budget plan before aggregated to single tranche send-out proposal. The community can selectively reject part of the entire yearly budget plan so that it can be revised and proposed again by the Assembly until it has majority agreement from the community.
i noticed that v1.2 doesnt address anything from the document linked in Prop80. are you guys going to address any of those Atom 2.0 risks and points of failure before the first signaling proposal?
Tbh I think the big short one is a little misguided. Hub investments into IS consumer chains do not represent liabilities. That should be pretty self-evident.
The cosmos minimalism one is also kind of all over the place argumentatively. I appreciate the sentiment that the Hub should be minimal, which is why as much functionality should be pushed to consumer chains as possible. IS will allow the Cosmos Hub chain to remain one of the most minimal and secure in the ecosystem. There are risks around the Treasury being deployed effectively, of course, but if you work backwards from the premise that the objective is for ATOM to be the premier interchain reserve, then (1) the ATOMs need to come from somewhere so the Hub needs a Treasury and (2) bootstrapping demand by deploying into the best risk adjusted opportunities requires a layer of delegated entities that can negotiate and run complex strategies, there’s no way around this.
Now you can start with different premises. That ATOM’s main function should NOT be the preferred interchain reserve, or that ATOM should be but it will happen inevitably with zero work or resources from the Hub. However I strongly disagree with both of these assertions.
oh, i didnt write it, its not my philosophy on minimalism or anything like that. the other day i looked at it, and It just happened to be a more complete list than my own, of all the possible risks that emerge based on 2.0.
I think that photon could solve liquid staking governance problem by using it instead, and be the payment layer using colateralized atom=photon and fund first consumer chain on ICS2
ATOM can still be the interchain reserve
*not to be disparaging to the ATOM 2.0 moniker, no preference what stuff is called so long as it has solvable issues.
Atom2.0, why not refined into several function to vote, disposable through atom2.0 is difficult to achieve consensus, now the dispute is whether the Treasury need so much money, it would dilute the holder of the atom.
is there a contemporary estimate for the annual labor costs associated with paying all the various council members and assembly people involved in 2.0?
Yes, it is a good proposal.
I just realized that prop 26 was the OG of this. I specifically remember that it was rejected =)
Voting is up and clear YES from us.
Enough has been talked and this is the best way to move forward.
Yes, it is a good proposal.
MEV only exists until the market inefficiencies that yields it are resolved.
Atom 2.0, rather than striving to resolve these market inefficiencies, proposes gambling the capital of ATOM holders on sustained monetized exploitation of market inefficiency in the hope that MEV, payment for order flow, and monetizing governance will generate enough revenue to make up for the lost revenue spent on under-discussed and under-disclosed projects and expenses.
Atom2.0 virtue signals innovation and growth, yet covets the inefficiency that will theoretically sustain it.
What are the expected monthly labor costs over the first 36 months for implementing the yet to be defined number and purpose of 2.0 councils, assemblies, etc.
Did Atom2.0 intentionally monetize liquid staking votes with anonymous voting out of curiosity relating to the dollar value of democracy?