Governance by Community
Token holders can democratically upvote on key strategic decisions to better perform and compete in a fast-developing ecosystem, including the development and maintenance of the Zetrix blockchain and its potential increase in network value, such as:
a) Altering the consensus mechanism b) Disbursement of incentives via airdrop c) Base parameters for staking and mining d) Choice of interchain atomic swaps e) Support or integration with other chains f) Recommendation of new dApp assets g) Admission of strategic alliance partners h) Underwriting of certain major risk(s) i) Adjustment to token burning cycles
Such governance is enabled by one upvote to one ZETRIX Token held, or by creating and distributing governance tokens separately to ZETRIX holders which is typical of Decentralised Finance (DeFi) protocols. ZETRIX Token holders, including permissioned participants and validators, have the power to propose and vote on major new changes or upgrades to the Zetrix network’s protocol. And in light of the history of contentious hard forks on Bitcoin and Ethereum to resolve disputes, Zetrix will strive towards a forkless model.
The proposed process is as follows:
Any participant or proposer with sufficient ZETRIX can initiate the creation of a new proposal for a key strategic decision above and submit for voting, but must first gather support from the community and have the ZETRIX delegated to their proposal.
The support should not be concentrated but is broadly representative of the community, including node operators which validate transactions, developers who build the blockchain, and end users of the solution provided.
All proposals must be written as smart contract code and shared with the community before being voted on. Thus when a network change is proposed, there is no ambiguity about what will happen if the change is implemented.
All discussions are conducted through an official Zetrix governance forum. This process also gives the community transparency and chance to evaluate input from various participants, vet through, and review the feasibility and impact of the proposed code changes.
Under this process, the governance is iterative. The code is continually written or rewritten by the proposer as communication and feedback takes place, and the process repeats until the proposed code is accepted or rejected in full.
Once a proposal moves along for voting, participants can vote by themselves based on their token holdings or delegate their voting rights to other participants within the community.
The limitations of fully autonomous governance need to be balanced out as they are inherently slow and cannot respond to risks promptly. Also the level of contribution or participation may be lacking, which is being redressed by proper Distribution of Interests (below).
Therefore, most projects use an administrative key as a fail-safe switch, as part of its core security and recovery modules. If anything goes wrong — such as a bug or hack — an admin key can be used to shut the network down thereby protecting the protocol from further exploits or disruptions. A multi-signature backdoor wallet may also be required to bypass the need for a proposal in case of emergencies. Such a system is needed while the ecosystem is still evolving, and with real values at stake, speed could be extremely necessary to tackle urgent threats.
While the governance models out there are currently imperfect and not completely autonomous, they are nevertheless useful for the coordination of token holders to align or represent the interests of the community, with continuous improvement and iterative upgrades in mind.
Last updated
