diff --git a/docs/articles/advanced/governance/Evmos-DAO/Evmos-DAO.md b/docs/articles/advanced/governance/Evmos-DAO/Evmos-DAO.md new file mode 100644 index 0000000..a1cd0f3 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Evmos-DAO.md @@ -0,0 +1,13 @@ +# **Evmos DAO & Community Governance** + + +## **Evmos DAO** + +**Evmos DAO** is the community-led & organized decentralized organization dedicated to the Evmos Network, which aims to continue its part in building the Evmos ecosystem. + +The DAO operates under the Interim Constitution, passed by the Evmos community in Proposal #51. + +The **Evmos Governance Framework** is still a work in progress and will be rolled out modularly. Like the Interim Constitution, the Framework will likely change and evolve as the network matures and grows. + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Governance-Overview.md b/docs/articles/advanced/governance/Evmos-DAO/Governance-Overview.md new file mode 100644 index 0000000..cd83ba1 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Governance-Overview.md @@ -0,0 +1,17 @@ +# **Evmos Network Governance** + +Governance is the process of interaction and decision-making among the stakeholders of a given system or organization. It is also the way rules, norms and actions are structured, sustained, regulated and upheld. + + +## **Truly Decentralized, Community Governed Network** + +The Evmos network, like other Cosmos-based chains, utilizes `on-chain governance` for all protocol level execution of proposals via the `gov` module included in the Cosmos SDK. This gives the community full control of the network, including complex parameter changes, distribution changes, treasury pool spending, and even upgrades to the network. Anyone who holds or stakes EVMOS can participate in these votes, regardless of the voter's validator choices. Immense power is given to the community to govern and dictate the future of the chain. + + +## **Limitations and Shortcomings** + +While the governance module in Cosmos SDK is sufficient for on-chain governance, there are limitations and shortcomings of the module that make it difficult to conduct off-chain governance - a crucial component for a DAO to be able to operate efficiently. Furthermore, the Cosmos ecosystem is lacking the innovative DAO management toolings that EVM-based DAOs have at their disposal. We hope to bridge the growing gap in innovations and tools between Ethereum and Cosmos with the deployment of interoperable tools onto our EVM, opening up a new world of tools for IBC chains. + + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Governance-Voting.md b/docs/articles/advanced/governance/Evmos-DAO/Governance-Voting.md new file mode 100644 index 0000000..1c474a0 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Governance-Voting.md @@ -0,0 +1,52 @@ +# **Governance Voting** + + +## **Voting Period** + +The voting period is currently a fixed 5-day period. During the voting period, participants may select a vote of either `Yes`, `No`, `Abstain`, or `NoWithVeto`. Voters may change their vote at any time before the voting period ends. + + +## **Voting Options** + + + +1. **Abstain: indicates that the voter is impartial to the outcome of the proposal. +2. Yes: indicates approval of the proposal in its current form. +3. No: indicates disapproval of the proposal in its current form. +4. NoWithVeto: indicates stronger opposition to the proposal than simply voting No. If the number of NoWithVeto votes is greater than a third of total votes excluding Abstain votes, the proposal is rejected and the deposits are[ burned](https://evmos.community/governance/voting#burned-deposits). + +Voting NoWithVeto provides a mechanism for a minority group representing a third of the participating voting power to reject a proposal that would otherwise pass. This makes explicit an aspect of the consensus protocol: it works as long as only up to[ a third of nodes fail](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html). In other words, greater than a third of validators are always in a position to cause a proposal to fail outside the formalized governance process and the network's norms, such as by censoring transactions. The purpose of internalizing this aspect of the consensus protocol into the governance process is to discourage validators from relying on collusion and censorship tactics to influence voting outcomes. + + +## **What determines whether or not a governance proposal passes?** + +There are four criteria: + + + +1. A minimum deposit of 192 EVMOS is required for the proposal to enter the voting period + * anyone may contribute to this deposit + * the deposit must be reached within 3 days (this is the deposit period) +2. A minimum of 33.4% of the network's voting power (quorum) is required to participate to make the proposal valid +3. A simple majority (greater than 50%) of the participating voting power must back the `Yes` vote during the 5-day voting period +4. Less than 33.4% of participating voting power votes `NoWithVeto` + +Currently, the criteria for submitting and passing/failing all proposal types is the same. + + +### **How is voting tallied?** + +Voting power is determined by stake weight at the end of the 5-day voting period and is proportional to the number of total EVMOS participating in the vote. Only bonded EVMOS count towards the voting power for a governance proposal. Liquid EVMOS will not count toward a vote or quorum. + +Inactive validators can 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. That means that if I delegate to a validator that is either jailed, tombstoned, or ranked lower than 150 in stake-backing at the time that the voting period ends, my stake-weight will not count in the vote. + +Though a simple majority `Yes` vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass, a `NoWithVeto` vote of 33.4% of participating voting power or greater can override this outcome and cause the proposal to fail. This enables a minority group representing greater than 1/3 of voting power to fail a proposal that would otherwise pass. + + +### **How is quorum determined?** + +Voting power, whether backing a vote of `Yes`, `Abstain`, `No`, or `NoWithVeto`, counts toward quorum. Quorum is required for the outcome of a governance proposal vote to be considered valid and for deposit contributors to recover their deposit amounts. If the proposal vote does not reach quorum (ie. less than 33.4% of the network's voting power is participating) within 5 days, any deposit amounts will be burned and the proposal outcome will not be considered to be valid. + + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Interim-Constitution-of-Evmos-DAO.md b/docs/articles/advanced/governance/Evmos-DAO/Interim-Constitution-of-Evmos-DAO.md new file mode 100644 index 0000000..88366c4 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Interim-Constitution-of-Evmos-DAO.md @@ -0,0 +1,77 @@ +# **The Interim Constitution of Evmos DAO** + + +## **Preamble: The Evmos Mission** + +We, the Evmos Community, formally declare our shared beliefs and mission to build and assist in growing the Evmos network. We strive to be the leading EVM network in the Cosmos Ecosystem, utilizing the Cosmos SDK modules, Tendermint's consensus engine, and the Inter Blockchain Protocol for a fully decentralized, censorship-resistant, interoperable chain. The Evmos network, our community, and our governance processes must strive to play a role in laying the foundation for a more equitable, hyper-connected, decentralized future. + + +## **1. The Evmos Community** + +The Evmos Community (“community”) is a general all-encompassing term that comprises various groups that are participants in the Evmos network. The level and degree of participation may vary by group, but the common denominator of all members of the community should be the shared interest in the continued growth of the Evmos network. + +**1. Protocol Developers** - this group of developers focuses mainly on improving the Evmos network on the protocol level; this group includes core developers as well as individual contributors not considered as core team members. + +**2. Network Validators** - network validators are key members of the community responsible for securing the network through the Tendermint proof-of-stake consensus mechanism. + +**3. Network Delegators** - network delegators are the predominant group that assist in network consensus and security by delegating power to validators through the staking of tokens. + +**4. Workstream and Committee Members** - workstream and committee members are those that work to improve and grow the Evmos network on a non-protocol level. + +**5. Community Leaders** - workstreams and special projects, although not required, may have an appointed leader to steward and lead his or her group. + +**6. Application Developers and End Users** - application developers and end users are those that develop, deploy, utilize, interact, transact, and ultimately bring value to the Evmos ecosystem. + +While the aforementioned groups make up the majority of the community, the definition and composition of the community are not strictly limited to these groups. + + +## **2. The Evmos Governance Framework** + +The Evmos Governance Framework (“framework”) is the foundational set of guidelines and processes developed for the community and network contributors to follow and flourish. The framework should be designed to recognize and incentivize contributors and curate a culture that creates long-term, positive-sum interactions between all community members and the Evmos ecosystem. + +The framework is to be proposed and adopted separately from the Constitution. The Constitution shall take priority over the Governance Framework and should be regarded as the supreme guiding document. + + +## **3. Guiding Principles and Values** + +**1. Progressive Decentralization:** The Evmos network aims to be as decentralized as possible, in the context of network validation as well as governance and finances. While network resiliency and the decentralization of power is paramount, we recognize the need to proceed with strategic and scientific-based planning. The community must not haphazardly rush into decisions that may potentially destabilize the chain or provoke a strong negative community reaction. The community will take the stance of progressive decentralization as we research and analyze the social, legal, and/or financial ramifications our decisions may potentially have. + +**2. Neutrality and Non-Partisanship:** We believe in the principles of equality for all and must act in accordance with this core principle. All groups and community members have equal access to information, equal rights, and equal responsibilities, as defined by this Constitution. No one group or community member should be favored over any other members. No one group or community member should be disfavored over any other members. We define “favor” as an unfair benefit that is not a direct consequence of provable effort and actions done, in alignment with our mission and goals. We define “disfavor” as an unfair punishment or loss of opportunity that is not a direct consequence of provable actions done against Evmos’ mission and goals. + +**3. User-Centrism:** Evmos is specialized to provide a unique EVM experience in the Cosmos ecosystem. We must therefore continue to optimize for 1) user adoption and 2) the qualities that contribute to steady growth: network liquidity, improvement of user experience, data sovereignty, stable production of blocks, educational resources, strong governance, etc. + +**4. Agnosticism:** Evmos should maintain neutrality as a chain with roots in both the Ethereum and Cosmos ecosystems. While the governance of Evmos may be reliant from time to time on other networks or tools, the Evmos community should retain a stance of neutrality. Community members must leave tribalism at the door; we should refrain from engaging in political debates that are not directly relevant to improving the Evmos network. + +**5. Cross-Chain Diplomacy:** Evmos is a network with a long history in the decentralization movement, with inspirations, ideas, protocols, and allies in various networks. Our community will come from a wide range of blockchain communities. Cross-chain collaborations, outreach initiatives, diplomacy missions, and continued participation in events are highly encouraged — especially with chains from the EVM and IBC ecosystems. + +**6. Consensual Collaboration:** While the Cosmos SDK’s implementation of governance is relatively permissionless, this does not mean anyone is entitled to work or compensation. Proposals will be assessed by the community on their merits alone and eventually voted on. In addition, proposals must follow the Governance Framework of the Evmos network and adhere to the principles outlined in the Constitution. + +**7. Sovereignty to Work:** The purpose of the Governance Framework is not to micro-manage proposals or teams. Sovereignty will be given to those that are working in accordance with the original proposal passed by the community, and are not in violation of any governance processes or principles of the Constitution. + + +## **4. Removal of Community Leaders** + +All community members appointed to a role of higher responsibility, including workstream members, may be removed via a formal vote on-chain. The Governance Framework shall outline the appointment, removal, and appeals process, along with a detailed dispute resolution guideline. + + +## **5. Constitutional Rights** + +Constitutional rights protect the members of the community from any unjust or cruel treatment by another member or the DAO itself. The Governance workstream shall amend a Bill of Rights to the Constitution as soon as a general consensus can be confidently reached. + + +## **6. Constitutional Amendments and Revisions** + +The community holds the power to propose an amendment to the Constitution by following the standard Evmos Proposal Lifecycle. The reasoning for the amendment must be justified and petitioned. If possible, there should be an attempt made to resolve the issue before a proposal for amendment is initiated. + + +--- + +**Validator/Community Code of Conduct and Constitutional Rights** + +We recognize that this Constitution is missing a few key topics — however, we also see the need to tread carefully in these sensitive and controversial topics. While it is inarguable that these are necessary components of the Constitution, there was clear signaling that we needed more time to allow for the natural growth of the community before we could formally ratify some sections with confidence. We pledge to continue our research and continue to engage with the community to find general consensus on the best step forward. + +While some topics will be amended into the Constitution when they are ready, most will likely be implemented through the Governance Framework. + + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Definitions-of-the-ECP-Framework.md b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Definitions-of-the-ECP-Framework.md new file mode 100644 index 0000000..d3e61fb --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Definitions-of-the-ECP-Framework.md @@ -0,0 +1,91 @@ +# **Core Definitions and Concepts** + + +## **Proposal Types** + + +### **On-Chain Governance** + +On-chain governance refers to all protocol-level execution of proposals using Cosmos SDK's `gov` module. Anyone who holds or stakes EVMOS can participate in these votes, regardless of the voter's validator choices. + + +### **Off-Chain Governance** + +Off-chain governance refers to all community decisions that do not require an on-chain protocol-level change. These types of decisions include various topics and concepts, from passing meta-governance proposals to forming special task forces or workstreams. + +All proposals are assumed to be `On-Chain Proposals` until the necessary infrastructure and toolings for `Off-Chain Voting` is established. Cosmos SDK's `TextProposal` will be used for `Off-Chain Proposals` for the time being. + + +--- + + +## **Proposal Types by Category** + + +### **Protocol Proposals** + + +
ModuleCodebaseParametersDescription
authcosmos-sdkMaxMemoCharacters TxSigLimit TxSizeCostPerByte SigVerifyCostED25519 SigVerifyCostSecp256k1The auth module specifies the base transaction and account types for an application. Ref.
bankcosmos-sdkSendEnabled DefaultSendEnabledThe bank module is responsible for handling multi-asset coin transfers between accounts and tracking special-case pseudo-transfers which must work differently with particular kinds of accounts. Ref.
distributioncosmos-sdkcommunitytax baseproposerreward bonusproposerreward withdrawaddrenabledThis simple distribution mechanism describes a functional way to passively distribute rewards between validators and delegators. Ref.
governancecosmos-sdkmin_deposit max_deposit_period voting_period quorum threshold vetoThe module enables Cosmos-SDK based blockchain to support an on-chain governance system. Ref.
+ +Additional Protocol Proposals: `slashing`, `staking`, `transfer`, `feemarket`, `claims`, `inflation` + +--- +### **Community Proposals** +Proposals that only require to be posted as a `TextProposal` on the Cosmos SDK - _Most commonly used for meta-governance proposals._ +--- +### **Workstream & Special Initiatives** +Proposals that request any type of funding from the `CommunityPool` or the DAO's treasury to form an in-house workstream (team, squad, sub-DAO, guild) or project with the direct purpose of benefiting the Evmos ecosystem. + +#### **Workstreams** + +Workstreams are typically DAO-funded teams with a recurring budget with no termination date (i.e., Community Outreach, Marketing & Creative Services, etc). More information on workstreams can be found on the DAO Workstreams page. + +Workstreams are the sub-units of how Evmos DAO advances its purpose. A workstream is a group of people actively working on tasks that align with Evmos' Constitutional Values and community-run initiatives. As such, ratifying workstreams sets boundaries on what is and isn't in the scope of Evmos DAO's governance. + +Anyone may start a workstream and gather momentum behind it by posting on Commonwealth. Until a formal proposal for a budget is made, this workstream is considered “informal.” A workstream can be as broad or narrow as its initiators like, but workstream proposals must satisfy the following criteria: + + + +* Have a clear objective that aligns with Evmos' values and objectives as listed in the [Constitution.](https://evmos.community/constitution) +* Distinguish itself from or explicitly state its improvements on existing workstreams. +* Propose clear budgets and timelines for producing outcomes, all in line with the budget proposal flow. + +Workstreams have five potential states. Each of the five states and the requirements for a workstream in each state are outlined below: + + + +* **Informal:** The workstream is not funded by the DAO and has not made a formal proposal with its goals and a budgetary request. +* **Proposed:** The workstream has made a formal proposal to the DAO for a working budget. +* **Active:** The workstream is active and funded by the DAO. +* **Inactive:** The workstream has been discontinued and is no longer being funded by the DAO. + + +#### **Special Initiatives / Projects** + +Special Initiatives and Projects are DAO-funded projects with a set budget and "completion" goal or date (i.e., Governance Tooling Project, Event Sponsorships, etc.) + + +--- +### **Protocol Incentives + Evmos Specific Proposals** +
ModuleCodebaseParametersDescription
revenueevmosEnableFeeSplit DeveloperShares AddrDerivationCostCreatereference
incentivesevmosEnableIncentives AllocationLimit IncentivesEpochIdentifier rewardScalerreference
erc20evmosregister_coin register_erc20reference
evmevmosExtraEIPs ChainConfigreference
+ +--- +### **Network Upgrades & Security** +
ModuleCodebaseParametersDescription
crisiscosmos-sdkConstantFeeThe crisis module halts the blockchain under the circumstance that a blockchain invariant is broken. Ref.
upgradecosmos-sdkMsgSoftwareUpgradex/upgrade is an implementation of a Cosmos SDK module that facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version. Ref.
+--- + + +## **Proposal Phase & Identification Tags** + +**You do not need to know the proposal phase and identification naming conventions! A Governance Council member will assist -- the content below is for reference.** + +Proposal Phases are denoted as: `[IDEATION]`, `[PRE-PROPOSAL]`, `[PROPOSAL]`, `[VOTING]` for the 4-phases, and `[PASSED]`, `[REJECTED]`, `[DEFERRED]` for proposals in the other stages. Refer to the [Proposal Lifecycle](https://evmos.community/governance/proposals/lifecycle) page for more information on proposal lifecycle phases. + +Proposal Identification Tags are only required for Governance, Workstream (subDAO), and Community Treasury Related Proposals Only + +The `ECP-#` tag will be assigned and added by a Governance Council member in the `Phase 2: ECP Formalization` or `Phase 3: ECP Signaling` phase. **You do not have to worry about adding in the tag yourself.** + +These tags are for internal tracking and organization purposes. Make sure to check the [Proposal Submission Guidelines](https://evmos.community/governance/proposals/submission) for more information on how to properly prepare your proposal for on-chain voting. + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/ECP-Submissions-Guidelines.md b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/ECP-Submissions-Guidelines.md new file mode 100644 index 0000000..1d002a4 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/ECP-Submissions-Guidelines.md @@ -0,0 +1,230 @@ +# **Proposal Submission for Voting** + + +## **Preparing the Proposal Payload** + +Many proposals allow for long form text to be included, usually under the key `description`. These provide the opportunity to include[ markdown](https://www.markdownguide.org/) if formatted correctly as well as line breaks with `\n`. Beware, however, that if you are using the CLI to create a proposal, and setting `description` using a flag, the text will be[ escaped](https://en.wikipedia.org/wiki/Escape_sequences_in_C) which may have undesired effects. If you're using markdown or line breaks it's recommended to put the proposal text into a json file and include that file as part of the CLI proposal, as opposed to individual fields in flags. + + +### **Attaching Metadata** + +**YAML Frontmatter** + +Although not a technical requirement, it is highly recommended that you upload your complete proposal onto IPFS with the following metadata at the very beginning. For more information on YAML frontmatter, refer to[ this documentation.](https://assemble.io/docs/YAML-front-matter.html) + +--- + +title: Launching the Evmos Liquidity Incentives Program + +authors: Tricky, Benny Lava, LPX + +proposal: ECP-PS-1 + +type: CommunityPoolSpend + +funding_amt: 2000000 + +discussion: https://commonwealth.im/evmos/discussion/6977-prevote-kickstart-defi-on-evmos + +polls: https://bafybeieyr4vsc3gubivurtvvuunhmkl3uqvsuv3zuag34gnh3xzgdyzcpe.ipfs.w3s.link/polls.json + +govreviewed: true + +created_at: 2022-09-17T19:14:49.280Z + +--- + +At the end of the on-chain proposal, provide the IPFS hash or IPNS link to the proposal with the metadata with a simple `IPFS: <hash or link>` at the end. This data will be used in the future for indexing and analysis purposes for off-chain governance. + + +### **Text Proposals** + +`TextProposal` are used by delegators to agree to a certain strategy, plan, commitment, future upgrade, or any other statement in the form of text. Aside from having a record of the proposal outcome on the Evmos chain, a text proposal has no direct effect on Evmos. + +**TextProposal Example Payload** + + +### **Community Pool** + +For community pool spend proposals, there are five components: + + + +1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals +2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal +3. **Recipient** - the Evmos (bech32-based) address that will receive funding from the Community Pool +4. **Amount** - the amount of funding that the recipient will receive in atto-EVMOS (`aevmos`) +5. **Deposit** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal + +**Community Pool Spend Payloads** + +In this simple example (below), a network explorer will list the governance proposal as a `CommunityPoolSpendProposal`. When an observer selects the proposal, they'll see the description. Not all explorers will show the recipient and amount, so ensure that you verify that the description aligns with the what the governance proposal is programmed to enact. If the description says that a certain address will receive a certain number of EVMOS, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise). + +The `amount` is `1000000000000000000aevmos`. This is equal to 1 EVMOS, so `recipient` address `evmos1mx9nqk5agvlsvt2yc8259nwztmxq7zjq50mxkp` will receive 1 EVMOS if this proposal is passed. + +The `deposit` of `64000000000000000000aevmos` results in 64 EVMOS being used from the proposal submitter's account. There is a minimum deposit required for a proposal to enter the voting period, and anyone may contribute to this deposit within a 5-day period. If the minimum deposit isn't reached before this time, the deposit amounts will be burned. Deposit amounts will also be burned if quorum isn't met in the vote or if the proposal is vetoed. + +**CommunityPoolSpend Example Payload** + + +### **Parameter Change** + +Changes to the `gov` module are different from the other kinds of parameter changes because `gov` has subkeys,[ as discussed here](https://github.com/cosmos/cosmos-sdk/issues/5800). + +For parameter-change proposals, there are seven components: + + + +1. **Title** - the distinguishing name of the proposal, typically the way the that explorers list proposals +2. **Description** - the body of the proposal that further describes what is being proposed and details surrounding the proposal +3. **Subspace** - the Evmos module with the parameter that is being changed +4. **Key** - the parameter that will be changed +5. **Value** - the value of the parameter that will be changed by the governance mechanism +6. **Denom** - `aevmos` (atto-EVMOS) will be the type of asset used as the deposit +7. **Amount** - the amount that will be contributed to the deposit (in `aevmos`) from the account submitting the proposal + +**ParamChange Proposal Example** + +In the example below, a network explorer listed the governance proposal by its title: "Increase the minimum deposit for governance proposals." When a user selects the proposal, they'll see the proposal’s description. This proposal can be[ found on the Evmos network here](https://commonwealth.im/evmos/proposal/7-increase-the-minimum-deposit-for-governance-proposals). + +Not all explorers will show the proposed parameter changes that are coded into the proposal, so the delegator should verify that the description aligns with what the governance proposal is programmed to enact. If the description says that a certain parameter will be increased, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise). + +Users can query the proposal details with the evmosd command-line interface using this command: + + +``` +evmosd --node https://tendermint.bd.evmos.org:26657 query gov proposal 7 +``` + + +{ + + "title": "Increase the minimum deposit for governance proposals", + + "description": "If successful, this parameter-change governance proposal will change the minimum deposit for future proposals from 10 evmos tokens to 64.", + + "changes": [ + + { + + "subspace": "gov", + + "key": "depositparams", + + "value": {"mindeposit":[{"denom":"aevmos","amount":"64000000000000000000"}], + + "max_deposit_period":"1209600000000000"} + + } + + ], + + "deposit": "20100000000000000000aevmos" + +} + +The deposit `denom` is `aevmos` and `amount` is `20100000000000000000`. Therefore, a deposit of 20.1 EVMOS will be included with this proposal. At the time, the EVMOS mainnet had a 10 EVMOS minimum deposit, so this proposal was put directly into the voting period (and subsequently passed). There is a minimum deposit required for a proposal to enter the voting period, and anyone may contribute to this deposit within a 5-day period. If the minimum deposit isn't reached before this time, the deposit amounts will be burned. + + +## **Submitting the Proposal** + +For information on how to use `evmosd` binary to submit an on-chain proposal through the governance module. + + + +1. `evmosd` is the command-line interface client that is used to send transactions and query Evmos +2. `tx gov submit-proposal param-change` indicates that the transaction is submitting a parameter-change proposal +3. `--from mykey` is the account key that pays the transaction fee and deposit amount +4. `--gas 500000` is the maximum amount of gas permitted to be used to process the transaction + * the more content there is in the description of your proposal, the more gas your transaction will consume + * if this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail + * the transaction will only use the amount of gas needed to process the transaction +5. `--gas-prices` is the flat-rate per unit of gas value for a validator to process your transaction +6. `--chain-id evmos_9001-2` is Evmos Mainnet. + * the testnet chain ID is `evmos_9000-4`. For current and past testnet information, please look at the[ testnet repository](https://github.com/evmos/testnets) +7. `--node` is using a full node to send the transaction to the Evmos Mainnet + + +### **Testnet Submission** + +You may want to submit your proposal to the testnet chain before the mainnet for a number of reasons: + + + +1. To see what the proposal description will look like +2. To signal that your proposal is about to go live on the mainnet +3. To share what the proposal will look like in advance with stakeholders +4. To test the functionality of the governance features + +Submitting your proposal to the testnet increases the likelihood that you will discover a flaw before deploying your proposal on mainnet. A few things to keep in mind: + + + +* you'll need testnet tokens for your proposal +* the parameters for testnet proposals are different (eg. voting period timing, deposit amount, deposit denomination) +* the deposit denomination is in `'atevmos'` instead of `'aevmos'` + +evmosd tx gov submit-proposal \ + + --title=<title> \ + + --description=<description> \ + + --type="Text" \ + + --deposit="1000000atevmos" \ + + --from=<mykey> \ + + --chain-id="evmos_9000-4" + + --node <testnet-address> + + +### **Mainnet Submission** + +This is the command format for using `evmosd` (the command-line interface) to submit your proposal on-chain: + +evmosd tx gov submit-proposal \ + + --title=<title> \ + + --description=<description> \ + + --type="Text" \ + + --deposit="1000000aevmos" \ + + --from=<mykey> \ + + --chain-id="evmos_9001-2" + + --node <address> + +Use the `evmos tx gov --help` flag to get more info about the governance commands + + +## **Deposit Period** + +The deposit period lasts either 3 days or until the proposal deposit totals 192 EVMOS, whichever happens first. + + +### **Deposits** + +Deposit amounts are at risk of being burned. Prior to a governance proposal entering the voting period (ie. for the proposal to be voted upon), there must be at least a minimum number of EVMOS deposited (192). Anyone may contribute to this deposit. Deposits of passed and failed proposals are returned to the contributors. + +In the past, different people have considered contributions differently. There is some consensus that this should be a personal choice. There is also some consensus that this can be an opportunity for supporters to signal their support by adding to the deposit amount, so a proposer may choose to leave contribution room (ie. a deposit below 192 EVMOS) so that others may participate. It is important to remember that any contributed EVMOS are at risk of being burned. + + +### **Burned deposits** + +Deposits are burned when proposals: + + + +1. **Expire** - deposits will be burned if the deposit period ends before reaching the minimum deposit (192 EVMOS) +2. **Fail to reach quorum** - deposits will be burned for proposals that do not reach quorum ie. 33.4% of all staked EVMOS must vote +3. **Are vetoed** - deposits for proposals with 33.4% of voting power backing the `NoWithVeto` option are also burned + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Proposals-Framework.md b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Proposals-Framework.md new file mode 100644 index 0000000..fc8424a --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/Proposals-Framework.md @@ -0,0 +1,25 @@ +# **Proposals Framework** + + +## **Evmos Community Proposals (ECPs)** + +ECPs are standardized proposals subject to voting that (once enacted) regulate and define the behavior of the Evmos DAO's Governance system, and provides a funding mechanism for special projects and workstreams. + + +## **The Evmos Community Proposal Framework** + +The Evmos Community Proposal (ECP) Framework sets the guideline for all subsequent ECPs to follow. This ECP is the foundational ECP that provides the necessary templates, processes, and guidelines for working within the framework and defines the key roles required for the operation and enforcement of the ECP process. + + +### **ECP Framework Components** + +**1. Definitions of the ECP Framework** - _Defines core concepts of the ECP Framework and the different types of proposals._ + +**2. The ECP Lifecycle** - _Defines the formal stages in the life cycle of proposals from conception to approval, rejection, or deferral._ + +**3. ECP Standards and Templates** - _Defines the processes, rules, and components required for all proposals before going to vote._ + +**4. ECP Submission Guidelines** - _Defines the proposal submission procedures and guidelines for on-chain voting._ + + +Document created by the Evmos DAO, https://evmos.community diff --git a/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/The-ECP-Lifecycle.md b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/The-ECP-Lifecycle.md new file mode 100644 index 0000000..ad77070 --- /dev/null +++ b/docs/articles/advanced/governance/Evmos-DAO/Proposals-Framework/The-ECP-Lifecycle.md @@ -0,0 +1,90 @@ +# **The Evmos Community Proposal Lifecycle** + +Phase 1 - Discussion + +Phase 2 - Formalization + +Phase 3 - Signal + +Phase 4 - On-Chain Vote + + +## **Phase 1: Discussion & Ideation** + +The purpose of this phase is to vet ideas with the active Evmos community members. Each idea for a proposal should have its own Commonwealth thread, and discussions should be as narrowly focused as possible. Anyone can participate and is encouraged to provide feedback in this phase of governance. The goal of Phase 1 discussion is to gain a rough community consensus, and refine the idea so that it can be formalized. The thread author should make an effort to address all comments and take them into consideration. + + + +* **Minimum Duration:** 48 hours +* **Forum Tag:** `[IDEATION]` + + +## **Phase 2: ECP Formalization** + +Phase 2 is where the idea is formalized into an ECP that includes all of the criteria specified in the ECP Template. It must be a clear and complete description of the proposed enhancement. All ECPs must have the following core components, **with additional/varying sections for certain proposal types (refer to the[ templates page](https://evmos.community/governance/proposals/templates))**: + +Title: Short and sweet, with the[ correct tags](https://evmos.community/governance/proposals/definitions#proposal-phase--identification-tags) prefixed. + + +--- + +**Summary** - A brief, high-level summary of what changes are being suggested. Summary should be a single sentence, or a bulleted list. + +**Authors** - List of authors and contributors involved in the writing of the proposal. + +**Abstract** - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the motivation and specification sections. Someone should be able to read only the abstract to get the gist of what this specification does. + +**Motivation** - The motivation section should describe the "why" of this proposal. What problem does it solve? What benefit does it provide to the Evmos network? + +**Proposal Type Specific Content** + +Make sure to double check your proposal type to see what[ additional information or details are required](https://evmos.community/governance/proposals/templates). **Especially for funding proposals!** + + + +* **Minimum Duration:** 72 hours (3 days) +* **Forum Tag:** `[PRE-PROPOSAL]` + + +## **Phase 3: ECP Signaling (Temperature Check)** + +At any point during Phase 2, the author may finalize the ECP by initiating a community temperature check. To do this, the author must change the tag of the forum post to `[PROPOSAL]`, and add a forum poll to gauge the community sentiment. + +Proposals should only move to Phase 3 once the author has considered all community comments, responded to all concerns and questions, and believes that the proposal is ready to go on-chain for a final network-wide vote. Proposals in Phase 3 should not be edited further with the exception of minor mistakes. + +**Forum Tag:** `[PROPOSAL]` + + +## **Phase 4: On-Chain Voting** + +If the signaling polls in Phase 3 show an overall positive sentiment and no major issues are brought up, the proposal may be submitted on-chain for the formal voting. Submission guidelines[ are listed here](https://evmos.community/governance/proposals/submission). + +**Forum Tag (Depending on Outcome):** `[VOTING]`, `[PASSED]`, `[REJECTED]`, `[VETO]` + + + +## **Other ECP Statuses** + + + +* **Withdrawn:** Assigned when a member withdraws their proposal, or if the proposal is abandoned with no activity. **Forum Tag:** `[WITHDRAWN]` +* **Deferred:** Assigned when a proposal has been deemed as not ready or not a priority but can be re-proposed at a later date. This status can be assigned during Phase 3 with a failed forum poll or signaling. **Forum Tag:** `[DEFER]` + + +## **Governance Council & Core Devs** + +**Governance Council** + +The Evmos DAO Governance Council may "fast-track" a proposal onto on-chain voting for time-sensitive and urgent matters. The Council must provide the community a post-mortem on why the Council deemed it was necessary to forego the Proposal Lifecycle. If the community deems that the decision was made in bad faith, the Community is encouraged to engage in discussions and hold the responsible parties responsible through disciplinary actions or even the removal of Council members through an on-chain vote. + +**Core Developers** + +Core developers are not bound to the ECP Framework for network and protocol related proposals. It is expected, however, that thorough testing and due diligence is performed by the developers for all network upgrades. It should be noted, however, that network upgrades must still go through the process of on-chain voting. + + +## **Assistance & Review** + +All proposers are welcome to approach the Governance Workstream for assistance in any part of the Proposal Lifecycle. In addition, proposers may request a formal review of the proposal before going on chain. + + +Document created by the Evmos DAO, https://evmos.community