General
3DPass uses a sophisticated self governance mechanism that allows it to evolve gracefully overtime 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.
3DPass decentralised governance system is comprised of three main components:
- Council - An approval-voted, elected executive "government" to manage parameters, admin and spending proposals.
- Technical Committee - A technocratic committee to manage the forkless online upgrade timelines.
- Referenda - A general voting system for everything else which rewarded long-term stakeholders with increased influence.
In order to do that, the network brings 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.
The basement of the governance mechanism was inherited from Substrate, Polkadot and Kusama. Follow their original documentation as a reference.
Democracy
3DPass has implemented Democracy pallet using Referenda trait as a voting system.
To make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (token holders) or the council, it finally will have to go through a referendum to let all holders, weighted by stake, make the decision.
Referenda
Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific proposal associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: set_code, which can switch out the entire code of the runtime, achieving what would otherwise require a "hard fork").
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:
- Publicly submitted proposals;
- Proposals submitted by the council, either through a majority or unanimously;
- Proposals submitted as part of the enactment of a prior referendum;
- Emergency proposals submitted by the Technical Committee and approved by the Council.
All referenda have an enactment delay associated with them. This is the period between the referendum ending and, assuming the proposal was approved, the changes being enacted.
Referenda is considered baked if it is closed and tallied. Again, assuming the proposal was approved, it would be scheduled for enactment. Referenda is considered unbaked if it is pending an outcome, i.e. being voted on.
For the first two ways that a referendum is launched, this is a fixed time of 28 days. For the third type, it can be set as desired. Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time.
Proposing a Referendum
Public ReferendaAnyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called endorsing. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle.
Note that this may be different from the absolute number of endorsements; for instance, three accounts bonding 20 P3D each would "outweigh" ten accounts bonding a single P3D each.
The bonded tokens will be released once the proposal is tabled (that is, brought to a vote).
There can be a maximum of 100 public proposals in the proposal queue.
Council ReferendaUnanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see Adaptive Quorum Biasing).
Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins).
There can only be one active referendum at any given time, except when there is also an emergency referendum in progress.
Voting TimetableEvery 28 days, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues.
The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum that has no proposals (is empty), and proposals are waiting in the other queue, the top proposal in the other queue will become a referendum.
Multiple referenda cannot be voted upon in the same period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once.
Voting on a referendumIn order to vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling.
It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at Voluntary Locking.
Example:
Peter: Votes No with 10 P3D for a 128 week lock period => 10 x 6 = 60 Votes
Logan: Votes Yes with 20 P3D for a 4 week lock period => 20 x 1 = 20 Votes
Kevin: Votes Yes with 15 P3D for a 8 week lock period => 15 x 2 = 30 Votes
Even though combined both Logan and Kevin vote with more P3D than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less.
TallyingDepending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use the following table for reference.
| Entity | Metric |
|---|---|
| Public | Positive Turnout Bias (Super-Majority Approve) |
| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) |
| Council (Majority agreement) | Simple Majority |
We are going to need, as well, both the following information and one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the Super-Majority Approve formula will be applied. There is no strict quorum, but the super-majority required increases with lower turnout.
approve - the number of aye votes
against - the number of nay votes
turnout - the total number of voting tokens (does not include conviction)
electorate - the total number of tokens issued in the network
Super-Majority Approve
A 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.
Super-Majority Against
A 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.
Simple-Majority
Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal.
Example:
- John: 500 P3D
- Peter: 100 P3D
- Lilly: 150 P3D
- JJ: 150 P3D
- Ken: 600 P3D
John: Votes Yes for a 4 week lock period => 500 x 1 = 500 Votes
Peter: Votes Yes for a 4 week lock period => 100 x 1 = 100 Votes
JJ: Votes No for a 16 week lock period => 150 x 3 = 450 Votes
- approve = 600
- against = 450
- turnout = 750
- electorate = 1500
Thus:
Since the above example is a public referendum, 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 transferrable so they will not be locked into the decision. Moreover, winning proposals are autonomously enacted only after some enactment period.
Voluntary Locking
3DPass utilizes an idea called Voluntary Locking that 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:
votes = tokens * conviction_multiplier
The conviction multiplier increases the vote multiplier by one every time the number of lock periods double.
| Lock Periods | Vote Multiplier | Length in Days |
|---|---|---|
| 0 | 0.1 | 0 |
| 1 | 1 | 28 |
| 2 | 2 | 56 |
| 4 | 3 | 112 |
| 8 | 4 | 224 |
| 16 | 5 | 448 |
| 32 | 6 | 896 |
The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5.
While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account.
Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked.
Adaptive Quorum Biasing3DPass leverages a concept, "Adaptive Quorum Biasing" (first introdused by Polkadot), which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it.
Let's use the image above as an example.
If a publicly submitted referendum only has a 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied 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 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 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 have 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.
Council
The Council is an on-chain entity embracing several actors, whereas each one represents an on-chain account. Current 3DPass Counsil consists of 3 initial accounts obtained by co-founders and will be expanded up to 13 members gradually elected within upcoming 2 Years starting from 2023.
Council responsibilities
- Having control over Treasury spendings
- Proposing sensible referenda
- Cancelling dangerous or malicious referenda
- Electing the Technical Committee
- Aproving new recognition algorithms for Proof of Scan
- Dealing with Validators
For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time.
Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing.
Proposal canceling
A proposal could be canceled if the technical committee would unanimously agree to do so, or if Root origin (e.g. sudo) triggered this functionality.
Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute.
If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders en masse to determine the fate of the proposal.
How to become a Council member
All stakeholders are free to signal their approval of any of the registered candidates.
Council elections mechanism operates under Phragmén voting rules introduced by Edvard Phragmén in the 1890s, which is one of the most common methods leveraging in Nominated Proof of Stake (nPoS). Council terms last for one week.
At the end of each term, Phragmén election algorithm runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up which is currently (20 that will remain in the queue with their votes intact. The algorithm is implemented as Phragmén Election Module.
As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole.
Let's have a look at the example below.
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 |
The above example shows that candidate C wins the election in round 1, while candidates A, B, D & E keep remaining on the candidates' list for the next round.
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 |
For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B.
Prime members
The council, being an instantiation of Substrate's Collective pallet, implements what's called a prime member whose vote acts as the default for other members that fail to vote before the timeout.
The prime member is getting chosen in accordance to Borda count
The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime.
Technical Committee
The Technical Committee (TC) is composed of the teams that have successfully implemented or specified 3DPass runtime. Teams are added or removed from the TC via a simple majority vote of the Council.
The purpose of the TC is to safeguard against malicious referenda, implement bug fixes, reverse faulty runtime updates, or add new but battle-tested features. The TC has the power to fast-track proposals by using the Democracy pallet, and is the only origin that is able to trigger the fast-tracking functionality. We can think of the TC as a "unique origin" that cannot generate proposals, but are able to fast track existing proposals.
Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast-tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other.
Treasury
The Treasury is a pot of funds collected through either slashing Validators accounts for missbehaviour or direct donations. 3DPass mainnet treasury accound is d1EjCsWUVnKTG3dysQC2MWDfZKngtiwV2ZLegWRfFMbUR5d6c
The funds held in the Treasury can be spent by making a spending proposal that, if approved by the Council, will enter a waiting period before distribution. This waiting period is known as the spend period, and its duration is subject to governance, with the current default set to 24 days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds.
Treasury payout is an automatic process:
- If the Treasury funds run out with approved proposals left to fund, those proposals are kept in the approved queue, and will receive funding in the following spend period.
- If the Treasury ends a spend period without spending all of its funds, it keeps the rest in the pot for the next payots.
When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit of at least 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted.
Proposals may consist of (but are not limited to):
- Infrastructure deployment and continued operation
- Network security operations (monitoring services, continuous auditing)
- Marketing activities (advertising, paid features, collaborations)
- Integrations
- Maintainance and Software development
The Council governs the Treasury and how the funds are spent is up to their judgment.
Creating a Treasury proposal
The proposer has to deposit a minimum of 100 P3D or 5% of the requested amount with a maximum cap of 500 P3D as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to governance so they may change in the future.
Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are to be slashed and kept in the Treasury pot.
Announcing the Proposal
To minimize storage on chain, proposals don't contain contextual information. Once a user decided to submit a proposal, they would probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms.
Fellowship
The Fellowship is a mostly self-governing expert body with a primary goal of representing humans who embody and contain the technical knowledge base of 3DPass network and protocols. This is accomplished by associating a rank with members to categorize the degree to which the system expects their opinion to be well-informed, of a sound technical basis and in line with the interests of 3DPass.
Unlike the Technical Committee, it is designed to be far broader in membership (i.e. to work well with even tens of thousands of members) and with far lower barrier to entry (both in terms of administrative process flow and expectations of expertise). Becoming a candidate member in the Fellowship is as easy as placing a small deposit.
Ranking System
In order to prevent a small group of participants from gaining effective control over the network, this system will adhere to three main principles:
- The Fellowship must never have hard power over the network: it cannot change the parameters, conduct rescues or move assets. Their only power in governance resides in the ability to reduce the effective timeline on which a referendum takes place.
- The Fellowship weights those with a higher rank more in the aggregate opinion, however the weight should not be so high as to make a small number of higher members’ opinions be insurmountable when compared to a coherent opinion coming from lower-ranked membership.
- The Fellowship should be designed to grow and develop its membership and their aggregate levels of expertise and in doing so ensure that its overall decision-making capacity gets stronger over time.
To support these conditions, the Fellowship will have a constitution which outlines the requirements and expectations for individuals to attain and retain any given rank. Higher ranks are able to vote and promote lower ranks based on this constitution.
Demotion occurs automatically after a given period has elapsed and the member is unable to defend their position to their peers.
Suspension can happen only through general referendum, which ensures that the Fellowship's bias alone does not necessarily result in expulsion.
In order to prevent the Fellowship from becoming a cabal (popularity with Fellowship peers alone should not be enough to gain access to a top rank), gaining access to top tiers of the ranks will require a referendum.
Whitelisting
The Whitelist pallet does one thing: it allows one Origin to escalate the privilege level of another Origin for a certain operation.
It allows for the Fellowship to authorise a new origin (known as Whitelisted-Root) to be executed with Root-level privileges and will only work with certain specified commands that have been authorised by the Fellowship. The Whitelist pallet verifies two things:
- The origin really is the Whitelisted-Root (i.e. that the referendum passed on this track)
- The proposal has indeed been whitelisted by the Fellowship.
If both conditions are true, the operation executes with Root-level privileges.
This system enables the ability to have a new parallel Track (Whitelisted-Root Origin), whose parameters allow for a shorter voting turnaround. Through an open and transparent process, a body of global experts on 3DPass have determined that the action is both safe and time-critical.
Blacklisting
A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) are immediately canceled. Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash.
Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of 3DPass might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid.
Governance token 3DPg
Governance Token (3DPg) is issued as an instrument for the governance to provide its services, such as: extra permissions, grants, obligations, social lifts, etc. For example, 3DPg might have been used as an extra permission for someone to become a Validator without having a block authorship. 3DPg is issued by means of embedded Assets pallet, which is designed to deal with fungible tokens.
- Current supply: 1000000 3DPg
- Decimals: 12
- Min indivisible unit: 0.000000000001 3DPg
