Hi there! Here’s Vlad, Head of Community and PR at Citadel.one.
This topic was inspired by recent discussions on prop. 72, prop 73 on Cosmos Hub and by a number of proposals on other cosmos ecosystem networks. As you might know, when making governance decisions, Citadel.one is following the Validator Constitution that describes conditions for “Yes”, “No”, “No with Veto” and “Abstain” votes. For a long time it has proved to be a very useful document in making informed and unbiased decisions when voting on most of the proposals.
After proposals 72 and 73 went on-chain our team has got an idea that the Validator Constitution can become a universal handbook for all validators and help them make weighted decisions on proposals, and also a standard or at least a guide for future proposers on how to improve their governance practices, deliver more transparent proposals and thus increase chances that their proposals receive enough publicity, reach quorum and get passed.
Decentralized governance is a very new industry, there are no standards, common practices, rules or must-haves. But that does not mean there shouldn’t be any. We decided to share our Validator Constitution and encourage all delegators and validators to read it through, provide feedback, critics, suggestions and additions to it. After we collect enough feedback we will share the edited Constitution 2.0 with the public so it can be adopted by other validators and potential proposers.
Our goal is to make this governance constitution a common guidance for the cosmos ecosystem. Once all comments, suggestions, edits, critics and whatever else is collected we will make ssure to design it well and share with a wider community.
Conditions that should be met for “Yes” voting:
1.1 Proposal aims to improve network performance, financial settings or enhances the sustainability of a network
Examples: Planned protocol upgrades; deployment of bridges, dapps, liquidity modules, AMM, etc.; corrections to inflation rates, blocks per year etc.
1.2 Proposal contains contacts and responsibilities of all core people involved in the proposal
John Roe - CTO (LinkedIn/Github links)
Janie Doe - Lead Frontend Developer (LinkedIn/Github links)
Richard Poe - Lead Backend Developer (Linkedin/Github links)
1.3 Proposal contains a detailed description of outcomes and results
Example: In case of a successful proposal outcome if so, our team will receive 10,000,000 XCT, and will start implementing the proposed developments. ETA of proposed deliverables is August, 2021. All deliverables will be open-source and publicly available.
1.4 Proposal contains a detailed use of proceeds (for Community Spend Proposals)
Example: https:// citadeldao.notion.site/5dcf537f5d16432eb94e74291abdf2b0?v=2d1542edb3014440bc31d49a8f37c3be (remove a space after https:// )
1.5 All proposed deliverables will be open-source
1.6 Additionally, we encourage proposers to:
1.6.1 Open off-chain discussions on forums and/or social media chats (Telegram, Discord) before going on-chain
Raise awareness around the proposal in all possible social media
1.6.2 Notify validators and community members of an ongoing off-chain/on-chain proposal
1.6.3 Deliver software and other developments that can be adopted and used by other community members.
1.7 Community spend proposals with a total ask above 1,000,000 USD should be audited.
1.8 If funding is required to sponsor regular network teams (DAOs, committees, ministries or similar) such as marketing team, bizdev, support teams, then the team should keep accurate financial records of all spendings and keep funds on a multisig account.
Conditions that should be met for “No” voting:
2.1 One or more conditions for “Yes” voting were not met
2.2 Proposals with uncertain key performance indicators Example: proposals without clear milestones, targets, value propositions or deliverables
2.3 Proposal contains controversial or harmful changes in network parameters
Examples: Adding or increasing trade/swap/tx fees to unreasonable values; unreasonable token burns, changes of proposal deposit amount; votes against validators or community members
2.4 Proposer has non-grata status
2.5 Proposer failed to fulfill obligations under one of the previous of their proposals (including other networks)
2.6 Additionally we discourage proposers to:
2.6.1 Demand unreasonably high funding
2.6.2 Request community funds for overlapping developments (unless there’s a community demand or space for improvement)
2.6.3 Collude or persuade other stakeholders to vote for their proposal
2.6.4 Put forward proposals without a qualified team or relevant experience in the field
Conditions that should be met for “Abstain" voting:
3.1 Proposal is politically motivated and doesn’t concern and/or anyhow affect network stability
3.2 Proposal content is indefinite and/or proposer is negotiating terms and conditions
Conditions that should be met for “No with veto” voting:
4.1 Proposal may cause a network vulnerability
Examples: If it is possible to automatically change the inflation rate through voting, proposer suggests abnormal rate to violate the networks’ operation
4.2 Proposal contains changes in the operation of the network di against any particular validator or a group of validators
Example: Proposal contains network changes provoking cartelization (in different forms)
4.3 Inappropriate/unreasonable funds spend or “Obvious looting"
Example: Wages or tech deliverables listed in use of proceeds are vell above the market prices
4.4 Spam proposals
Example: blank proposals, those without a certain demand or message, offensive content, advertisements