Citadel.one Validator Constitution
Being one of the largest validators in the Cosmos ecosystem, we take a responsible approach to governance and always rely on our Validator Constitution, compiled in accordance with the mission and beliefs of Citadel.one’s founders.
In this article, we have spelled out all conditions that should be met for “Yes”, “No”, “Abstain” or “No with veto” votes cast.
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.
Example:
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)
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 fulfill all the conditions specified in paragraphs 1.1- 1.7, additionally, the proposal should be divided into clear milestones and the team should hire an audit company to keep track of the spendings.
1.8 If funding is required to sponsor regular network teams (DAOs, committees, ministries, etc.) such as marketing team, bizdev, support, etc. 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
Examples: 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, persuade or bribe 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
3.3 Inappropriate/unreasonable funds spend
Example: Wages or tech deliverables listed in use of proceeds are vell above the market prices
Conditions that should be met for “No with veto” voting:
4.1 Proposal may cause a network vulnerability
Example: proposer suggests abnormal inflation rate to violate the networks’ operation
4.2 Proposal contains changes in the operation of the network
Example: Proposal contains network changes provoking cartelization (in different forms)
4.3 Spam proposals
Example: blank proposals, those without a certain demand or message, containing irrelevant and/or offensive content or advertising 3rd party projects.