ADD.xyz Governance Draft
Governance Draft Proposal
After several months of drafting a governance proposal. The ADD.xyz team has launched an official consultation phase with our advisors and wider team members before engaging in a community/public based consultation period for proposals, changes and considerations to be made.
ADD.xyz Governance Draft v0.1
Contents
Introduction
Principles of distributed system governance
a. Consensus and minimizing the risk of forks
b. Implications of anonymity
c. On-chain vs. off-chain
Hierarchies of Governance
d. Level 1: Governance
e. Level 2: Core system
Decision-making bodies
f. ADD.xyz Foundation
g. Technical Committee
h. Moderators
i. Token Holders
j. Review Board
Rewards and removal procedures
k. Rewards
l. Removal Procedures
m. Voting Agenda and Moderator guidelines
The voting agenda
n. Token Holder Proposals
o. Guidelines for Moderator
Types of decisions
p. Standard changes
q. Changes to governance
r. Changes to the core system
Review Board approval or veto standard changes
s. Simple changes: parameter changes
t. Simple changes to governance
u. Simple changes to the core system
Review Board approval or veto of simple changes
Emergencies
Summary of Voting
Governance
An open, permissionless platform like ADD.xyz requires a transparent and clear governance process to reach agreement on how to maintain and improve the network. Those who are involved in governance, the topics to be governed, and key aspects of the process are outlined below.
Principles of distributed system governance
Most issues relating to the governance of groups of humans at any level are quite similar. We will focus on three areas relevant to distributed ledgers.
Consensus and minimising the risk of forks
In most democratic countries, decisions are usually made based on a majority vote. Occasionally, the vote will be on some controversial topic, where the losing side will be strongly against the decision taken. But whatever the level of opposition, the losing side generally does not have the option to secede and form a new country with a new government.
On a permissionless ledger, this is different: a strong enough minority can attempt to fork the ledger. The decision-making process is not just about majorities, but about the structure of opinions. For example, if 70% of voters are in favour of some change, while 30% are very strongly against, this may lead to contention. An alternative proposal may have only slightly less support, say 60% in favour, but with the other 40% either neutral or only slightly opposed, making it less controversial.
What this means is that governance in distributed systems must focus on building a wide consensus among all stakeholders. We should speak of “on-chain consensus” via “on-chain voting”.
Implications of anonymity
In a permissionless ledger, with anonymous or pseudonymous accounts, voting rights will naturally depend on the number of native tokens held--one coin one vote (coin voting). This is similar to corporate governance, where the weight of a shareholder’s vote is usually proportional to the holding of ordinary shares.
In most blockchain systems, this is how voting gets done. However there should be some form of mix so that oligopolies don’t form and collude. Coin voting (quantity of tokens held) should be combined with a way to weigh the votes of token holders by their activity. This not only gives more say to the most active members of the ecosystem but also provides some security against attacks: an attacker wishing to disrupt the governance process would not only have to purchase a significant amount of tokens but would also have to generate (and pay for) a sufficient number of transactions over a certain period of time.
Could also weigh votes according to staking age, ie how long one has staked on the platform. The longer staked the more voting power.
On-chain versus off-chain
Actions registered on-chain, such as a voting record, will be the visible and permanent record of governance actions on a distributed ledger system. It is important to note that this will only be the tip of the iceberg. Any meaningful vote will most likely be preceded by off-chain discussions and debates, which should be as open and fair as possible. The methods of achieving this should be part of the governance rules. Also, the process by which motions can be introduced for an on-chain vote must be specified. Proposals can be posted on a wiki and getting vetted by moderators/team to be voted on.
Offline discussion and proposals will take place on a dedicated wiki page for the entire community to use. This can link to other places like reddit and twitter to engage as many as possible. Voting can happen here as well via a link to the webpage that has an associated on-chain link.
Governing Body
(Please note: The ADD.xyz Foundation will be set up over time using a phased approach)
Community members who hold ADD can create and vote on proposals to improve the ADD.xyz network.
This includes members of the Foundation and its Board of Directors, the ADD team, investors, validators, and anyone else in the ecosystem who holds ADD.
To avoid any conflict of interest and maintain independence, community members who hold ADD can not be connected with the Foundation or its affiliates in any manner, and the assets and funds of the Foundation or its affiliates remain under the control of the relevant Board of Directors who shall exercise independent judgement and apply them to achieve the Foundation's objectives.
The right to vote does not entitle ADD holders to vote on the operation and management of the Foundation or its affiliates or their assets, and does not constitute any equity interest in the Foundation or its affiliates.
Hierarchies of Governance
In most democratic systems, there is a hierarchy of acts or documents that define how it functions. A typical example is:
Institutional acts, or organic laws, which describe the system’s governance: its various decision-making bodies and the rules applying to the decision-making;
• Ordinary acts, or laws, which define the general rules of the system other than governance;
• Executive orders, used when urgent action is required;
• Regulations – when necessary, these define more precisely how general rules will be applied in specific situations.
Because this is a logical and time-tested hierarchy, the ADD.xyz governance system will use some of these concepts.
Governance Topics
Technology Aspects
The governance process can also be applied to improve the technical aspects of the ADD network.
This may include implementation of new technical features, changes to the consensus mechanism, software update schedules, and more.
Governance Process
The ADD governance process can be used to enact changes in the governance process. ADD holders can work to improve who is involved in governance, what governance rules are, and how the process will work.
How the Governance Process Works
Below is an overview of how ADD.xyz governance process may work and its key aspects. The process and associated parameters are subject to change.
In the beginning, pre-Foundation, the proposal process will take place on a community wiki, where the community can post PIPs to be voted on. These proposals will be vetted by moderators/team members to see what gets put up for votes. Once PIPs are considered for voting, a vote will occur via wiki links to on-chain voting. If certain thresholds are met within the voting process, PIPs become validated to pass or fail. If a vote passes it gets executed. If not enough votes for a proposal it is denied.
Governance proposals have distinct phases:
Creation: A proposal is created by a user. In the early stages, this will be the Genesis team and community members through a community wiki. Proposals will be posted on a wiki to be voted on by the community as a whole.
Voting: The proposal enters the 'Voting' phase once a proposal is passed and accepted by the moderators/genesis team. The wiki directly links proposals to a voting link (on-chain) to vote yes or no. Votes are made by sending vote transactions to the Governance contract. Voting will be available for the community for up to 2 weeks on any given proposal.
Execution: At the end of Voting phase, once all the votes are counted for and against, if the minimum threshold is met, the proposal is resolved and the status is changed to 'Executed'.
a. If the votes threshold has been reached then the proposal implemented/executed.
b. If the votes threshold has not been reached, then the proposal is not executed.
ADD Improvement Proposals
A ADD Improvement Proposal (PIP) is the document used to provide information to the community about potential improvements and changes to the ADD.xyz network.
The PIP should provide a thorough but concise technical specification of a single proposed improvement and the rationale for why the improvement should be implemented.
PIPs can be written to propose: ● Direct changes to the protocol: these may include technical improvement changes to edits to network parameters, and others. ● Process change requests: these may include changes to the governance process, procedures, and preferred tools that don’t require a change to the ADD.xyz codebase. ● ADD.xyzitional information: these do not propose a new improvement, but may provide guidelines or highlight information to the ADD.xyz community. Any community member can author a PIP, and they are responsible for introducing the PIP to the community, building consensus, documenting consenting and dissenting opinions, and managing the overall process for their PIP.
The ethos of the proposals should be such that they are being put up in good faith and with the betterment of the project in mind. Any proposals which directly attack or at a clear detriment to the project or created with malice will automatically be rejected. This will be determined by the moderators.
PIP Introduction, Iteration, and Voting Process
Once a community member introduces their PIP to the community, members can provide feedback and opinions about the proposal.
After sufficient discussion, the PIP will be finalized and voted on. Voting will take place online for all to see. If the number of 1) total votes and 2) votes in support of the PIP exceed predetermined thresholds (% needed for proposals to pass), the PIP will pass and be implemented. Otherwise, the PIP will be rejected or deferred.
Basic proposal template
1. What - Short description of the problem that will be ADD.xyzressed
2. Why - Why the proposal is needed and why it’s a good idea.
3. How - Steps that should be performed to accomplish your idea
4. Who - Describe the entity that will complete the work and draw down on the proposals budget
5. When - Describe projects milestones, expected completion dates etc.
Voting Rights
In the early days of the ADD.xyz network, each ADD holder will be able to cast one vote (1 coin, 1 vote). This is to avoid the scenario where one or a few parties have too much influence over the direction of the ADD network.
Over time, the number of votes that can be cast by community members may increase. This may be based on the number of ADD held, level of contribution to the network, or other factors.
Introduction
This document presents the overall principles, bodies and rules on which the governance of the ADD.xyz blockchain is based, in application of the general principles set out for the ADD.xyz Network.
The roles, composition and tenure of ADD.xyz’s decision-making bodies: the ADD.xyz Foundation, the Technical Committee, Moderators, the Token Holders and the Review Board.
Phased Approach
ADD.xyz will be taking a phased approach to governance that will ultimately end up with a Foundation. This phased approach is being taken so that ADD.xyz and the executive team can build out the network and products as envisioned in the early days, yet still allow the community to begin to participate in the governance process.
There will be multiple phases to reaching a foundation a full decentralized governance:
Phase 0: Introducing the governance document for the network and allowing the community to comment on it. Feedback will be taken based on this.
Phase 1: Choosing Moderators and creating the channels to allow the community to create ADD Improvement Proposals (PIPs)
Phase 2: Set up voting and a methodology for voting on proposals. Further decentralize the project governance and allow on-chain voting.
Phase 3: Set up the Foundation.
Future changes to this document
The ADD.xyz Team has the right to make changes to this document at any time until 6 months.
Governance
The ADD.xyz governance rules, of which the present document constitutes the first version, define how decisions are taken in the ADD.xyz network, including how changes to the decision-making process are made.
Some of these governance rules will be implemented in the governance functions of the ADD.xyz software itself, while others will serve to rule off-chain interactions and operations.
Core system
The ADD.xyz Core System represents most of the system software, with the exception of governance functions.
Decision-making bodies
In this section, we describe the ADD.xyz decision-making bodies. Their general roles are summarised in the table below.
Decision-making bodies
ADD.xyz Executive Committee
This will be comprised of the core team and advisors and will be the key decision making body until the ADD.xyz.xzy foundation is formed.
The ADD.xyz Executive Committee will publish a first version of the ADD.xyz Network Rules and will have the right to make adjustments to the rules during the first year. Later changes will be made in accordance with the governance rules.
The ADD.xyz Executive Committee will particularly use this voting power during the first year to effect changes in voting parameters so that they correspond better to the actual voting and participation patterns of the ADD.xyz network. The Executive Committee will then gradually refrain from exerting influence.
ADD.xyz Foundation
The ADD.xyz Foundation will have a key role to play in the future.
Once the ADD.xyz Foundation is formed, it will have the right to make changes to ADD.xyz Network Rules, which include governance rules. In the initial governance phases, the executive committee will be the decision makers for the network. Once the ADD.xyz foundation is formed it will be opened up to all token holders.
Technical Committee
Role
The Technical Committee will provide advice on the technical feasibility and costs of change proposals.
The Technical Committee will also be in charge of urgent bug fixes and for responding to emergencies. It will initiate emergency change requests and coordinate the implementation of such changes with core developers.
Composition
The Technical Committee will be composed of 5 persons with deep tech- nical knowledge of the ADD.xyz Network, some of whom are expected to be ADD.xyz core developers. All 5 will be elected by the ADD.xyz executive committee.
Tenure
Technical Committee members will have one-year renewable tenure.
Moderators
Role
Moderators will be in charge of introducing proposals for on-chain voting. Their role will also be to observe and moderate off-chain discussions about system changes and improvements and gauge support for various proposals under discussion. For proposals that have sufficient traction, the Moderators will ask for the Technical Committee’s feed- back as to the feasibility and, if necessary, cost of the proposed changes. Depending on the feedback received, Moderators will decide whether to submit proposals to on-chain voting. Any Moderator, acting alone, will be able to submit such proposals.
Moderators will jointly decide where off-chain discussions will take place. This could, for example, be an existing discussion platform
The moderators will work with the executive committee to:
Set up the community wiki
Create templates for proposals
Information proposer should include
Create/Give Tips for creating a successful proposal (engage the community, Demonstrate clearly how proposal will benefit Fantom, make sure its realistic and not just hype, speak to a broad audience, build consensus)
Design Sample Proposals for different types of proposals
Software feature proposal
Marketing proposal
Constitution change proposal
Create proposal requirements
Note: a proposal is only a first step, to be followed by discussions, modifications etc and then, maybe in some amended form, ADD.xyzed to the Voting Agenda as one of the options of an actual vote
Decide/Curate the types of proposals to be voted on from the community
Create FAQ
Create Glossary
Create/Curate Research
Design Moderator Censorship (when and if necessary)
Why or why not this will be required and for what circumstances
Composition
There will be 5 initial moderators: 2 will be community based and the other 3 will be people familiar with the project. These people will be onboard for 6 months before a vote is had to keep them on or replace. The initial moderators will be selected by the ADD.xyz executive committee.
Tenure
Moderators will have a 1 year tenure.
First 6 months exception the first team of Moderators will be designated by the ADD.xyz Foundation, and their tenure will last for 6 months after mainnet launch.
Token Holders
With the exception of emergency changes, decisions will always be taken by a vote of the entire community of all token holders: Token Holders. Voting procedures will depend on the type of decision being taken, as described below.
Delegation of votes will not be possible. Such delegation could be introduced later.
In the case of emergency changes, the token holders will have the right of veto.
Review Board
Role
The role of the Review Board is to review decisions voted on by the token holders. The Review Board has final veto power, should it find, for example, that a decision cannot realistically be implemented or conflicts within the community of voters..
Composition
The Review board will be composed:
members of the Technical Committee;
members chosen by the ADD.xyz foundation
The first members of the Review Board will be designated by the ADD.xyz Foundation, and their tenure will last for 6 months after mainnet launch.
Rewards and removal procedures
Rewards
Technical Committee members, Moderators and Review Board members will receive a reward for their work, which will be decided by the foundation subject to a performance review. Such rewards will be expressed in ADD
These roles will be paid based on activity. The consequences of inactivity are removal and loss of payment. It is up to the executive committee to decide on these things and appoint new members in the event of removal.
Removal procedures
Members of the Technical Committee, Moderators and Members of the Review Board can be removed by the Foundation for inactivity or for any other reason. Moderators will then organise another vote to replace that individual for the remainder of his or her tenure or find a replacement.
Voting Agenda and Moderator guidelines
The Voting Agenda
Moderators are in charge of introducing issues and proposals for on-chain voting, and they thus set the Voting Agenda. This is an important role: admitting too many issues to voting is likely to result in a lack of focus and thus lead to poor decision-making by the token holders. There will be a provision for the team to make a direct intervention and put in proposals.
Token holder proposals
If the Moderators refuse to consider an issue, a token holder can directly submit a proposal for on-chain voting. There will be a deposit per proposal of ADD funded by any number of accounts. Once this is done, the Moderators will be obliged to ADD.xyz this proposal to the Voting Agenda and treat it like any other issue or proposal. If the proposal is accepted by the Foundation, the deposit will be returned. If the proposal is denied, the deposit will be forfeit unless the Foundation decides otherwise - this might be the case where a proposal, although voted down, is still considered bona fide.
Note that proposals submitted directly by token holders should be the exception rather than the rule.
Guidelines for Moderators
Moderators should recognise the importance of providing a structured process for making changes to the shared resources of the ADD.xyz Network. They shall document their activity and, based on accumulated operational experience, create and then maintain a set of non- binding moderator guidelines, some of which could then be made an integral part of ADD.xyz governance.
Moderators will use their judgement to decide what issues shall be submitted to a vote. They will have to find a balance between refusing some requests by token holders in order to keep the Voting Agenda manageable while at the same time being careful not to deny legitimate requests that have a wide backing from the token holders.https://finematics.com/yield-farming-explained.
Issues should be categorised based on their importance and urgency, both of which will impact how long and involved the discussion process should be before an issue is submitted to a vote. Moderators should strive to make the decision process as fast and efficient as is practical, keeping in mind that an efficient governance system is one of the key competitive advantages of the ADD.xyz Network.
To prepare for on-chain voting, Moderators will closely follow, and contribute to, off-chain discussions. They can organise indicative votes to help assess which choices have the most traction among the community. These votes should be carried out using a simplified voting method, with the goal of reducing the number of choices submitted for final voting.
Types of decisions
There are four types of actions that can modify either the rules of the ADD.xyz Network or its software.
• Standard changes: these are decisions whose implementation requires a change to software and is therefore subject to technical uncertainty and potential costs;
• Simple changes (Parameter changes): these are decisions that can be implemented without changes to ADD.xyz Network software;
• Emergency changes: these require a simpler approach but should not affect governance rules.
The decision and voting procedures for each of these are different.
Standard changes
Standard changes are those that require a modification to ADD.xyz Network software. Moderators will communicate with the Technical Committee and developers to evaluate the technical feasibility and cost of such proposed changes so as to avoid an unrealistic proposal being voted upon.
The decision parameters depend on whether the change relates to governance or to the core system.
Changes to governance
For changes to governance rules, any vote result must meet the following criteria:
• Quorum: must be > 60%
If none of the options under consideration meets these criteria, the vote is invalid, and no changes to the system are made.
Changes to the core system
For core system changes, the parameters are slightly more relaxed than for governance changes:
• Quorum: must be > 60%
Review Board approval or veto of standard changes
After a vote by the token holders to introduce a standard change, the Review Board has two weeks to approve or veto that vote. Decisions of the Review Board require a strict majority (> 50%) and a quorum of 60%. Absent a Review Board decision, the token holders vote is deemed to be final after two weeks.
Simple changes: parameter changes
There will be some parameters that can be changed without modifying ADD.xyz Network software itself. Such changes will not require any in-depth analysis by the Technical Committee, nor will they require a cost estimate. Another type of decision that does not have an impact on ADD.xyz Network software is These can, for example, be used for: (Insert here)
• Rewards for Moderators, Technical Committee Members and Review Board Members after a successful tenure.
All of these simple changes are voted on by the token holders, with the following minimal decision criteria applying:
Simple changes to governance
For simple changes to governance, the same decision criteria apply as to standard changes to governance.
Review Board approval or veto of simple changes
After a vote by the token holders to introduce a simple change, the Review Board has one week to approve or veto that vote. Such Review Board decisions require a majority of 60% and a quorum of 75%. Absent a Review Board decision, the token folder’s vote is deemed to be final after one week.
Emergencies
In case of emergency, or when serious bugs are identified, the ability to respond quickly is critical. There may be no time for a protracted discussion and voting process. In such situations, the Technical Committee can work with core developers and network valida- tors to propose emergency updates. Examples where this may become necessary include:
dealing with critical bugs, retroactively making changes to the state of the blockchain in case of evident fraud and other emergency situations such as DoS attacks.
Proposals for emergency changes can be decided upon by the Technical Committee with a simple majority, subject to a quorum of 50%.
The token holders will be able to veto any emergency decision via a majority vote organised by the Moderators immediately after a positive emergency vote by the Technical Committee. A veto can be obtained with a simple majority of voting power, subject to a quorum of 60% of voting power.
Voting power
The voting power of an account will depend both on tokens held and on that user’s activity, with voting itself constituting one type of activity. Therefore, actively participating in the voting process will increase a user’s share of block rewards for delegated tokens. The exact parameters of how voting power is computed will be determined later.
Last updated