#4 Signaling Proposal: Archway Governance Process & Framework

**Type**: Signaling Proposal **Title:** Archway Governance Process & Framework **Summary:** The Archway Foundation puts forward an operating framework for on-chain governance proposals with the objectives of: - Agreeing on a standardized proposal process - Providing clarity around the community’s role within the Archway Protocol - Gathering and incorporating feedback from the community as a whole **Details:** ***1. Proposal Types:*** The Archway community will be able to vote on community treasury use, network upgrades, parameter changes, intent signaling, and a few others as further set out below. *Non Technical Implementation Proposals:* - Signaling proposal: These proposals intend to demonstrate support on certain topics or ideas for the community, which are not reflected through on-chain implementations - Community Pool Spend Proposal (community-pool-spend): This type of proposal enables the community to allocate community pool tokens to initiatives and projects with the purpose of furthering the Archway ecosystem *Technical Implementation Proposals:* - Parameter Change proposal (param-change): This type of proposal allows updating chain parameters - Cancel Software Upgrade (cancel-software-upgrade): Cancel the current software upgrade proposal - Clear Contract Admin (clear-contract-admin): Submit a clear admin for a contract to prevent further migrations proposal - Execute Contract (execute-contract): Submit a execute wasm contract proposal (it can be run by any address) - IBC Upgrade (ibc-upgrade): Submit an IBC upgrade proposal - Instantiate Contract (instantiate-contract): Submit an instantiate wasm contract proposal - Migrate Contract (migrate-contract): Submit a migrate wasm contract to a new code version proposal - Pin Codes (pin-codes):Submit a pin code proposal for pinning a code to cache - Set Contract Admin (set-contract-admin): Submit a new admin for a contract proposal - Software Upgrade (software-upgrade): Submit a software upgrade proposal - Sudo Contract (sudo-contract): Submit a sudo wasm contract proposal (to call privileged commands) - Unpin Codes (unpin-codes): Submit a unpin code proposal for unpinning a code to cache - Update Client (update-client): Submit an update IBC client proposal - Update Instantiate Config (update-instantiate-config): Submit an update instantiate config proposal. - Wasm Store (wasm-store): Submit a wasm binary proposal ***2. Proposal Process:*** The following steps should be expected and strongly enforced by the community when setting up a proposal. Proposals that don’t follow these standards, with the exception of emergency proposals, should be considered incomplete and thus should not be passed. *Step #1: Socialization [Min 3 - 7 Days]* Goals: - Informing the community - Determining if viable - Improving upon idea Actions for proposer: - Introduce the idea to the community by posting it to the [Archway public forum](https://gov.archway.io/), according to the templates available in the [Archway docs](https://docs.archway.io/community/governance/governance). - [Clear Contract] [IBC Upgrade] [Execute Contract] [Cancel Software Upgrade] [Instantiate Contract] [Pin Codes] [Sudo Contract] [Unpin Codes] [Update Client] [Update Instantiate Config] [Wasm Store] = Must be on Discourse for a minimum of 3 days. - [Community Spend] [Signaling] [Param Change] [Software Upgrade] = Must be on Discourse for a minimum of 7 days. - Identify those individuals, projects and groups that will likely be interested in your proposal. Reach out and ask for feedback from key stakeholders and groups - Join at least 1 community governance call to discuss the proposal with the wider ecosystem. If you are not able to join the regular community call, then you should contact the governance moderator to schedule a call to discuss the proposal - Help foster a thoughtful and respectful conversation - Actively participate and respond to comments and questions - Incorporate aligned community feedback into your proposal - Evaluate if the proposal should move into the Formalization stage *Step #2: Formalization [Min 3 Days]* Goals: - Creating a well-formed proposal - Defining relevant outcomes, parameters, entities, actors, commitments - Assuring completeness Actions for proposer: - Synthesize the ideas gathered and formalize into clear request - Use a [proposal template](https://docs.archway.io/community/governance/governance) to ensure all necessary information has been included. Please make sure your proposal follows the appropriate format provided in the Archway docs - Note: proposal templates can be refined through community governance via a signaling proposal - Present formalized proposal to community for feedback *Step #3: Implementation [On-chain Voting]* Goals: - Submitting the proposal for on-chain voting process - Accessing resources available for proposal deposit and seek sponsorship Actions for proposer: - Submit via the CLI, see guide [here](https://docs.archway.io/community/governance/governance#cli-walkthrough) - Follow [proposal submission guides](https://docs.archway.io/community/governance/governance) - Optional: Seek sponsorship. If the proposer does not have sufficient funds for the minimum deposit, a request for a sponsor should be posted in the [Governance forum](https://gov.archway.io/c/governance/11) - Promote that the proposal is live and on chain on Twitter, the Archway Discord, Telegram, and other relevant community channels - Depending on the nature of the proposal, there may be follow up actions needed after the proposal passes or fails *Emergency Upgrades:* In some emergency circumstances, such as the discovery of a critical protocol-level bug, this standard governance process may be too slow to resolve urgent issues. In these cases, a quicker response may be necessary to prevent damage to the system, the loss of assets, or to maintain the confidence of users and stakeholders. Therefore, emergency upgrades may require direct communication and coordination with network validators to ship a code fix alongside a chain halt, rather than pass this through a protracted proposal process. In these extreme cases, ensuring the integrity and survival of the network takes precedence over regular governance procedures. It’s therefore crucial that any such actions are transparently communicated during/after the fact, and that they are the exception rather than the rule. ***3. Proposal Format:*** All proposals should follow a standard structure that includes key elements, to ensure all information presented cleanly and consistently: - Type: Type of proposal - Title: Short yet descriptive title - Summary: Short paragraph on what changes are being suggested, why, and how they benefit the Archway protocol and ecosystem - Details: A deeper dive into what is being proposed and the details surrounding the proposal - Proposal Type Specific Content (*optional*): If any additional information that can be useful to address specifics such as links to relevant documents, links code repos, or examples, list of multisig accounts, sponsors, etc. - Financial (*optional*): If seeking community funds, outline a specific budget amount that indicates general line items on how money will be spent, with a clear outline of timelines, deliverables, and outcomes - Forum Discussion: Link to forum discussion of socialization process - Proposers: List of contributors involved in the writing of the proposal ***4. Voting Power:*** Voting power is determined by stake weight at the end of the voting period and is proportional to the number of total ARCH participating in the vote. Only staked ARCH tokens count towards the voting power for a governance proposal. Unstaked ARCHs will not count toward a vote or quorum. Only tokens staked with active validators will have voting power. Inactive validators are able to cast a vote, but their voting power (including the backing of their delegators) will not count toward the vote if they are not in the active set when the voting period ends. ***5. Voting Options:*** - By voting yes, you agree with the proposal and would like to see it passed - By voting no, you disagree with the proposal and would not like to see it passed in its current state - By voting abstain, you are recognizing this proposal is irrelevant to you and would not want your vote to be counted in either direction - By voting no with veto, you fundamentally disagree with the proposal and would not like to see it reworked nor revisited If there are sufficient NO WITH VETO votes, the depositors will lose their funds. The depositors will also lose their funds if a quorum of over 33% is not reached. In each case, the funds will be burned. ***6. Current Parameters:*** Current parameters are set at the below values. The community will be able to change these as they see fit. - Voting period: 7 days - Quorum: 50% - Passing threshold: 33.40% - Veto threshold: 33.40% - Min deposit: 5,000 ARCH **Forum Discussion:** [Signaling Proposal: Archway Governance Process & Framework](https://gov.archway.io/t/signalling-proposal-archway-governance-process-framework/126) **Proposers:** Michael Cullinan, one of the Directors of the Archway Foundation. Michael has been a core contributor to the Archway Protocol for the last 2 years. This proposal incorporates valuable input and feedback provided by Valeria Salazar and Ethan Illingworth from [Phi Labs](https://philabs.xyz/), as well as David Fortson of [LOA Labs](https://loalabs.io/). Additionally, it has been influenced by governance discussions and frameworks established by [the Regen community](https://commonwealth.im/regen/discussion/11611-upgrade-candidate-governance-processes-and-community-spend-proposals), as per David's suggestion.