⚖️Governance
Decentralization is a goal to strive for within crypto, and for a good reason. It mitigates regulatory concerns, promoting practices hailed by crypto enthusiasts, such as revenue sharing and user-guided evolution. There are certain technical limitations to what can and cannot be in a decentralized fashion through the Win Platform. Parts of the platform’s operations will always be off-chain and thus out of the scope for decentralized governance votes.
An essential part of the economic policies and platform evolution will eventually be decided by the community directly, as it is one of the core values on which the Win Platform is built.
Items outside the governance scope include, but are not limited to game engine implementation, game integration policies, match resolution (match results will be derived off-chain but recorded on-chain).
The community will still be able to decide on many issues such as new games being developed, tournament rewards, the allocation of funds, buyback policies, reward distributions, fee rates, and more.
During phases 2 and 3, voting will be done via Voting power. Voting power is obtained by staking the project's token in the Governance module for a certain duration. More formally:
Where
We can then define $M$ as follows:
Where ($D$) is the duration of the stake in weeks, this gives us the following multiplier curve based on duration.
During Phase 3, suggesting and implementing a proposal will closely follow UniSwap’s governance process, with tweaked parameters and an additional Tender step.
The platforms governance will have three distinct stages:
Early days during this period, the team is in complete control of the project, and no voting is done. This is because there will be bugs and events requiring immediate hotfixes, which cannot be done democratically.
Semi-decentralisation - during this period, the team is still in complete control of the project and can deploy hotfixes same as above, but for the non-urgent decision, it can take community input via a forum or even via off-chain voting like a snapshot - https://snapshot.page/#/.
Complete decentralization - during this stage, the project is fully decentralized, and all decisions are made via a strict procedure, and all voting is done on-chain.
When complete decentralization is realized, the system will adapt to a model very similar to that of Uniswap. The details of how the process will look are as follows:
Phase 1: Temperature Check — Discourse/Snapshot
The purpose of the Temperature Check is to determine if there is sufficient will to make changes to the status quo.
To create a Temperature Check:
Ask a general, non-biased question to the community on the community forum about a potential change (example: “Should the project governance add rewards for action XYZ?”). Forum posts should be labeled: “Temperature Check - [Your Title Here]”. The forum post should include a link to the associated Snapshot poll.
Voters use Snapshot to indicate their interest in bringing it forward to the next stage. Snapshot poll lengths should be set to 3 days.
If the proposal gains 5% of the pool backing, it moves to the next stage - consensus check.
If the Temperature check does not suggest a change from the status quo, the topic will be closed on the governance site. If the Temperature Check does indicate a change, proceed to Stage 2: Consensus Check.
Phase 2: Consensus Check — Discourse/Snapshot
The purpose of the Consensus Check is to establish formal discussion around a potential proposal.
To create a Consensus Check:
Use feedback from the Temperature Check post and create a new Snapshot poll that covers the options which have gained support. This poll can either be binary or multiple-choice but should include the option “Make no change” or its equivalent. Set the poll duration to 5 days.
Create a new topic in the Proposal Discussion category on the community forum titled “Consensus Check — [Your Title Here]”. This will alert the community that this topic has already passed the Temperature Check. Community moderators should immediately remove any topics beginning with Consensus Check that have not passed Temperature Check. Make sure that the discussion thread links to the new Snapshot poll and the Temperature Check thread.
Reach out to your network to build support for the proposal. Discuss the proposal and solicit delegates to vote on it. Be willing to respond to questions on the Consensus Check topic. Share your viewpoint, although try to remain as impartial as possible.
Voting lasts five days. Whichever option has most votes wins and can be included in a Tender for Stage 3. A 67% pool quorum of the voting pool is required for the vote to be considered valid.
If the option “Make no change” wins, the Consensus Check topic should be closed by community moderators.
Phase 3: Governance Proposal — Governance Portal
Phase 3 — Governance Proposal — is the final step of the governance process. The proposal should be based on the winning outcome from the Consensus Check and can consist of one or multiple actions, up to a maximum of 10 actions per proposal.
To create a Governance Proposal:
Write the code for your proposal, which can be voted on through any Governance Portal. A professional auditor should audit all proposed codes. This auditing process could be paid or reimbursed by the community treasury.
Create a topic in the Proposal Discussion category on the community forum titled “Governance Proposal [Proposal Number] — [Your Title Here]” and link to any relevant Snapshot polls/discussion threads as well as the code audit report.
Call the propose() function of the Governance Contract to deploy your proposal.
Once the propose() function has been called, a seven-day voting period is started. Ongoing discussions can take place on the community forum. A two-day timelock will follow if the proposal passes successfully before the proposed code is executed.
During the early stages of the Governance module implementation, the project team will have the power to veto any proposal in the Timelock which could significantly hurt the protocol. At a later stage, the team will renounce this power.
Soft governance:
The described process lays out a structure for those wishing to host a formal vote on a particular issue.
However, governance systems also require a degree of “meta governance” discussions that inform the direction and implementation processes behind the policy, but which don’t qualify as policy themselves.
The community may discuss new ideas and strategies for governance — including changes to the process outlined above — in the “Governance-Meta” category. On-chain voting is not necessary to make updates to off-chain processes.
Governance Glossary:
Governance token: An ERC-20 token that designates the weight of a user’s voting rights. The more Governance tokens a user has in their wallet, the more weight their delegation or vote on a proposal holds.
Delegation: Governance tokens holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s address. Note that delegation does not lock tokens; it merely adds votes to the chosen delegation address.
Governance Proposal: A proposal is a code that is executed by the governance contract through timelock. It can replace the governance contract, transfer tokens. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 5-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.
Quorum: For a vote to pass, at least 67% of all delegated tokens must vote in the affirmative. This quorum aims to ensure that the only measures that pass have adequate voter participation.
Voting: Users can vote for or against single proposals once voting rights are delegated to their address. Votes can be cast while a proposal is in the “Active” state. If the majority of voters vote for a proposal, the proposal may be queued in the Timelock.
Timelock: All governance actions are delayed by the timelock contract for a minimum of 2 days before they can be executed.
Last updated
