Participate in Phala Network governance using PHA tokens and democratic processes.
Go to the Governance section for more detailed tutorials on voting and Treasury application.The early Khala network will use a governance mechanism consistent with Polkadot and Kusama, enabling it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. Therefore, the following Khala democratic mechanism basically adopts the same process and instructions as the Polkadot wiki. To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda.
set_code
, which can switch out the entire code of the Runtime, achieving updates on-chain).
Referenda are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are “aye”, “nay”, or abstaining entirely.
Referenda can be started in one of several ways:
Entity | Metric |
---|---|
Public | Positive Turnout Bias (Super-Majority Approve) |
Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) |
Council (Majority agreement) | Simple Majority |
Super-Majority Approve
formula will be applied. There is no strict quorum, but the super-majority required increases with lower turnout.
positive turnout bias
, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below.
negative turnout bias
, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below.
Super-Majority Approve
would be used to calculate the result. Super-Majority Approve
requires more aye
votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter’s tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferable so they will not be locked into the decision. Moreover, winning proposals are autonomously enacted only after some enactment period.
Voluntary Locking
which allows token holders to increase their voting power by declaring how long they are willing to lock up their tokens, hence, the number of votes for each token holder will be calculated by the following formula:
Lock Periods | Vote Multiplier |
---|---|
0 | 0.1 |
1 | 1 |
2 | 2 |
4 | 3 |
8 | 4 |
16 | 5 |
32 | 6 |
Adaptive Quorum Biasing mechanism
Positive Turnout Bias
.
In contrast, when it has a 75% turnout, the tally of “aye” votes has to reach 54%, which means that the super-majority required decreases as the turnout increases.
When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using “Negative Turnout Bias”. In this case, it is easier to pass this proposal with a low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries.
Referring to the above image, when a referendum only has a 25% turnout, the tally of “aye” votes has to reach 34% for it to pass.
In short, when the turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of “aye” votes has to be reached, but as turnout increases towards 100%, it becomes a simple majority.
All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout.
Round 1 | |||||
---|---|---|---|---|---|
Token Holders | Candidates | ||||
A | B | C | D | E | |
Peter | X | X | X | X | |
Alice | X | ||||
Bob | X | X | X | ||
Kelvin | X | X | |||
Total | 2 | 1 | 3 | 2 | 2 |
Round 2 | ||||
---|---|---|---|---|
Token Holders | Candidates | |||
A | B | D | E | |
Peter | X | X | ||
Alice | X | X | ||
Bob | X | X | X | X |
Kelvin | X | X | ||
Total | 4 | 4 | 1 | 1 |