Change log
- 2024-06-25 Final post and archive
- 2024-04-18 Created initial post
UPDATE
Due to the move from Full set Security to partial set security and then ICS2 and permissionless on- and offboarding of consumer chains (CHIPs Discussion phase: Permissionless ICS), we consider the original proposal to have lost part of its purpose.
We still think that some of the steps developped here have an added value: Particularly we think that consumer chains wanting to join the ICS should stick to the principles guiding the AEZ and should from themselves produce clear and transparent information layed out in the steps detailled below:
What is the chain proposing, what are they bringing to AEZ? How do they imagine conflict resolution to work to prevent worst case scenarios of being kicked out of the AEZ?
We think incumbent chains should present these information before making the step to ask for a Chain ID.
Summary
This signaling proposal has two objectives:
- Accelerate the discussion on a standard workflow in the AEZ.
- If the different pieces of the proposed workflow find large support: Kickoff the creation of such standard workflow.
The proposed steps are based on the results of the Cosmos Citizensâ Assembly (see here and here) improved by discussions with stakeholders of the AEZ.
The proposal here applies for Full set security, not for partial set security.
Details
Principles guiding the AEZ
Purpose and utility: Producer and consumer chains should be aligned in their purpose and there should be value, utility, or a common goods dimension to creating a new chain. It should provide a real-world application. If something is of central importance to the AEZ, it should be considered (LSDs, NFTs, Dex).
Economic incentives: The balance between the cost of security and return on investment for validators should be long-term positive. There should be a clear value (monetary or other) in return for ATOM stakers. The AEZ should prefer to use ATOM for operations.
Moral alignment: There should be an alignment. It should be for the benefit of the majority and not only the minority and support the vision of the ecosystem.
Tokenomics compatibility: This compatibility should be ensured to avoid inflationary pressure and the risk of overwhelming ATOM.
Technical alignment: The technical ability of teams should be strongly assessed, their technical alignment with the rest of the hub can be looser in order to support innovative technical designs without tight restriction.
Understandability: This principle refers to the fact that the onboarding, management, and offboarding process should be easy to understand. Understandability also refers to the fact that the solutions proposed by the chains need to be easy to understand for the cosmonauts (purpose / how the solution intends to solve something).
Onboarding
Overall Principles
These principles should be the same for new chains (not yet built) and existing chains (already working, just connecting to AEZ), while making space for a differentiated concrete process on some aspects like tokenomics, or alignment.
Phase 1: Request to Join AEZ: Purpose and value proposition
The following questions have multiple acceptable answers, and they should be addressed in the first template to support Cosmonautsâ understanding of the proposal:
- What is the AppChain, its purpose, its value proposition, and its motivation to join AEZ?
- Why is the project viable for all parties involved?
- How does the chain consider the added value of AEZ for its security?
- Why the chain proposes to join the AEZ as an appchain, rather than deploying a smart contract to an existing smart contract chain within the AEZ, which might help reduce some infrastructure and validator costs?
- How will the chain benefit from the AEZ?
- How can it be beneficial for the Hub, the validators, and the chain? (example: ComposableFi)
- What are the possible conflicts? How does the chain propose to resolve them?
Milestone: template filled and published in the Cosmos Forum in the category: AEZ with the namer [INITIAL ONBOARDING PROPOSAL].
Phase 2: Motivation and value discussions
Following the first template proposal, the chain and the community should enter in a series of AMAs and community sessions (the candidate chain community and Atom community). The candidate chain should clearly provide a summary of the discussions, issue resolution, and a report outlining the changes made to the original proposal.
Milestone: template improved on the Cosmos Forum in the category: AEZ with the namer [IMPROVED ONBOARDING PROPOSAL].
Phase 3: Second ârequest to joinâ template: Tech and financial analysis
Following the first round of discussion, the chain prepares a more detailed proposal adding the following bricks:
- Finance analysis: What is the tokenomics modeling, is it fair on competition? (Imagine Archway wants to join, but Neutron is already on it and has a similar offer), how to justify competitiveness?
- Tech analysis: Is anything missing in terms of tech? Is it secure for the hub to host? What happens if a chain secured by the hub is down?
- Offboarding Methods: What are the metrics that will be monitored after onboarding? What will be the metrics that will trigger concerns? What is the worst-case scenario and how to handle/mitigate it?
Beyond this document, the chain should run a Simulation: The chain should simulate the state of the AEZ for validator & community before and after onboarding through the testnet program.
Milestone: template improved on the Cosmos Forum in the category: AEZ with the namer [FULL ONBOARDING PROPOSAL].
Phase 4: Forum Proposal and AEZ Review
Once the full proposal is ready, the candidate chain should enter a final phase of community review holding AMAs, and community sessions. This process allows the chain to revise the forum proposal and write the final formal proposal.
Milestone: Final proposal on the Cosmos Forum in the category: AEZ with the namer [FINAL ONBOARDING PROPOSAL].
Phase 5: Onchain vote
Once the chain feels that the proposal is mature enough, it should publish it as a full Governance Proposal and go to an onchain vote.
Milestone: Final proposal onchain.
Phase 6: Governance proposal follow-up
If the proposal passes, the chain moves to the technical onboarding and the management process. If the proposal fails, the process can loop back to phase 4 for improvements and further discussion.
Managing Chains
Overall Principles
The goal during management is to ensure accountability and trust. The following dimensions are part of the management process: Economic performance, technical performance, contractual performance (making sure that the âcontractâ covering the chainâs technical roadmap and commitments is respected), and governance.
Not all chains can be described by the same metrics so a degree of flexibility is needed.
Monitoring of economic metrics
The economic metrics have to be adapted to the nature of the chain (e.g. defi vs smart contract). They encompass the following dimensions: Transaction volume, TVL, Active wallets, # contracts deployed, on-chain activity, Integration with other ecosystems, codebase, userbase, and revenue for Validators.
The economic performance will be monitored in terms of the price of the token of the partner chain in relation to the ATOM token. This would allow monitoring if the chain is underperforming or overperforming the Hub in relative terms rather than in absolute terms.
Monitoring of qualitative metrics
The second dimension of monitoring aims at capturing a more qualitative set of criteria: Chain performance, reputation, respect of the Roadmap, open source code, Level of nurturing and mentoring from the AEZ to the consumer chains, and Fit into the community.
Monitoring of technical metrics
In that domain, two key metrics are central: first a monitoring of possible known vulnerabilities in the chain binaries, and secondly, if the safety of 1 chain could affect the safety of the hub itself.
Tools for monitoring
Monitoring relies on 4 tools:
- An AEZ explorer, like mintscan to see AEZ chain metrics: This would allow to follow the revenue, and the treasury management
- A report every 3 months: This report should cover all dimensions of monitoring: economics, technical, qualitative and focus on risk management.
- A regular review of the advancements, for example during Cosmoverse. This review should allow validators to have an input on performance and be part of the review.
- A Review SubDAO focusing on analysing those metrics and publishing them.
The monitoring should aim at ensuring good governance. It should allow chains to follow the evolution of the AEZ.
Offboarding and conflict resolution
Because there has been no experience with offboarding yet, this part of the proposal is focusing on forecasting reasons, on both sides, for a split. Then it outlays the general principles and approach that should be followed.
Why would a chain leave?
The chain becomes bigger than Cosmos: Much of the value that the AEZ provides is the scale of security work and the size of the token holdings. For a small chain, the size of the treasury protects against attacks. If a partner chain becomes bigger than Cosmos Hub, then it may no longer need the security.
The economics are no longer beneficial: Either because the chain has not achieved enough revenue, or because the costs of AEZ make the chain not profitable, the economic conditions cannot sustain the relationship.
The chain has found a better option: A better ecosystem, or one with a different technology or direction that the chain prefers.
The chain sees AEZ as not delivering on their commitments: Even if the relationship provides value, they may believe that they are being taken advantage of, they are not getting the growth they expected from joining AEZ, or AEZ made commitments that they are not fulfilling.
The chain is no longer aligned with the AEZ vision: They may have had a change of vision, or they see AEZ heading in a direction they donât agree with. Or they may believe the conditions are too restrictive and they want sovereignty.
The chain may feel unable to resolve conflict: Politics. Conflicts of interest, disagreements with the community.
Why would AEZ want to remove a chain?
The economics are no longer beneficial: Either because of low adoption and activity, the chainâs performance, or because the cost structure is not making the chain profitable for Cosmos to support. The chain is putting the AEZ at a greater risk than its âvalueâ for the community / AEZ members.
The chain is no longer aligned with the AEZ vision: The chain is heading in a direction AEZ doesnât agree with or is creating unnecessary conflict in the community, or violates an agreed upon Code of Conduct.
AEZ sees the chain abusing the ecosystem: If the chain is being predatory or parasitic on other chains in the ecosystem, or if they created a conflict of interest.
AEZ sees technical or security issues: Technical issues could be unmet goals or unexpected difficulties in meeting the roadmap. Security issues might be the extraction of value due to exploits from the partner chain.
What principles should drive resolving conflict in AEZ?
Clear onboarding agreements and effective monitoring will resolve many concerns without ending in offboarding. The general principles we see are:
- Clear & visible boundaries: the onboarding proposal should have clear goals and boundaries set.
- Ongoing communication: Regular check-ins should monitor satisfaction, and there should be regular meetings that would prevent conflicts from escalating. All parties should remain available for conversations.
- Small spaces for resolution: When complex issues arise, such as technical issues and evolutions of the roadmap and prioritization in both teams, the conversation should be held in a smaller group. The AEZ should establish a council with other AEZ members, or a group in charge of dispute resolution, to avoid having âtoo many cooks in the kitchenâ. Only then hold a governance vote.
- Thought, not emotion: discussions about conflict remain professional, using expert opinions and concrete evidence.
- Good skills and methods: AEZ should develop templates for resolution, and practice non-violent communication.
Forum post link
Governance votes
The following items summarize the voting options and what it means for this proposal:
YES -
NO -
NO WITH VETO - A âNoWithVetoâ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of âNoWithVetoâ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.