From xx network wiki
Revision as of 17:01, 15 October 2021 by Anne (talk | contribs) (Protected "Governance" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
Jump to navigation Jump to search
This is a team contributed page
What follows is a high-level description of the currently proposed governance implementation within the xx network. It is likely to change before the MainNet launch.

The xx network uses stake-based governance based upon the standard governance within the Substrate Ecosystem.

The primary goal of governance is to allow the network to evolve over time at the direction of the network's stakeholders. Fundamentally, governance strives to balance the will of the token holders with the needs of a user-driven blockchain.

In general, there are three structures within the platform for decision making:

  1. The Token Holders
  2. The Council
  3. The Technical Committee

The general flow of the network is that the Token Holders elect the Council, and the Council elects the Technical Committee. Thus, the Token Holders are the root of all authority within the xx network.

Token Holders use their coins to nominate nodes, pass referenda, and elect the Council.

 Boxed values  are configurable and subject to change before release or by governance.


Referenda are changes to the network. Each referendum is a proposal to alter anything from network parameters, code, or state all the way to triggering a hard fork of the network.

In general, there are three types of referenda:

  1. Public Referenda: Referenda submitted and propagated by token holders
  2. Council Referenda: Referenda submitted by the Council
  3. Scheduled Referenda: Referenda triggered as part of a previously passed referenda

Outside of fast-tracked referenda (see the section below), only one referendum is active for voting at any given time. These referenda occur in a fixed time window that will be, on network launch,  14 days . All referenda are binary, giving voters a choice between either “yay” or “nay.”

All referenda have an enactment delay, a period of time after the referendum is accepted but before it is enacted. Outside of fast-tracked referenda, the enactment period is  14 days .

The network alternates between putting up a public referendum and a council referendum for a vote every 14 days.

Proposal Mechanism

Public Referenda

Any coin holder can propose a public referendum. To do so, the proposer deposits a minimum number of tokens of  100  xx. Then, any other coin holder may second the proposal by depositing their coins on the proposal.

The proposal with the highest deposit will be voted on during the next public referenda period (every other 14-day period).

The public proposal queue has a maximum size of  100  proposals.

Council Referenda

Every other referendum period is dedicated to proposals put forward by the Council. Council members vote internally on a motion and when it is approved, it becomes a referendum. Depending on the support found within the Council when passing the motion, the Council proposed referendum has different voting requirements.

When a simple majority (>50%) approves a council referendum, it must receive a simple majority of all coin votes to be accepted (>50%).
When a supermajority (>60.0%) approves a council referendum, it can be proposed with the standard positive turnout biasing within the Substrate Ecosystem, where as the turnout increases, the passing threshold for the referendum decreases from a supermajority (66% + 1).
When all members of the Council support a council referendum, it can be proposed using the standard negative turnout biasing within the Substrate Ecosystem. Negative turnout biasing is a voting system where the rejecting threshold for the referendum decreases as the turnout increases. The threshold for rejecting the referendum starts at a supermajority (66% + 1).

Any member of the Council can veto a council referendum. This veto power can only be exercised once per proposal. If the proposal is resubmitted, it cannot be re-vetoed by the same Council member.

The Technical Committee can veto a council referendum with a unanimous vote. This has a  1-week  cool-down period.

Fast-Track Referenda

The Technical Committee has the power to fast-track Council referenda that were passed with either supermajority or unanimity. In the fast-track process, the Technical Committee selects the enactment period.

If the Technical Committee has a two-thirds supermajority, the referendum enters a fast-track voting period with a minimum of  3 hours . If unanimity is achieved, the proposal is immediately tabled and the enactment period begins.

Proposal Cancellation

The Technical Council can cancel any public proposal with a unanimous vote before it becomes an active referendum. Doing so slashes the total deposit associated with the proposal. The Technical Committee can only cancel a proposal once.

Referendum Cancellation

A supermajority (23rd) of the Council can cancel any active referendum. This is designed to be used as a last resort if a malicious referendum is ever brought up to voting.


The Council is an on-chain representative body designed to represent passive stakeholders within the xx network. At launch, the Council will have  13 members .

All Council members are selected via the Phragmén election process standard within the Substrate Ecosystem. All coin holders can vote on Council members in each period. These terms will last  7 days . The election selects the 13 Council members and the  7 runners-up , which keep their votes in the election.

The Council has the power to propose referenda (see Council Referenda), control the treasury, cancel Active Referenda, and elect the Technical Committee. Individual members have limited veto power over proposals presented to the Council, but an individual member cannot veto the same proposal more than once.


The treasury consists of funds collected through transaction fees, slashing, staking, and inefficiency (i.e., the network missing the ideal staking ratio). Any token holder may make proposals to the Council to access funds by staking a minimum of  5%  of the request, or 100 coins, whichever is higher. The stake is slashed if the proposal is rejected and returned if it is accepted.

To accept a proposal, at least 35th of the Council must support it. The threshold to reject a proposal is a simple majority.

If there are unspent funds at the end of a treasury period ( 24 days ), a portion will be burned. At network launch, this burn rate will be set at  1% .

Along with the proposal system, any token holder can suggest a tip. Any Council member can back the tip by recommending an amount the recipient of the tip can receive. Once more than half the Council backs a tip, it enters a closing phase where Council members can still submit their backing, but the tip has already passed. Once closed, the amount awarded is equal to the median suggested tip amount.

When tips are started by the public, they must be accompanied by a deposit, and the suggester receives  20%  of the total tip award.

Electing the Technical Committee

Half the Council (or public referenda) can add or remove members from the technical committee. Any referendum can do so as well.

Technical Committee

The technical committee, as described above, is elected by the Council by majority vote. The technical committee’s primary responsibilities are to manage a series of on-chain values to ensure the proper functioning of the xx network, veto power of council proposals (as described in the council referendum section), and the ability to fast-track and expedite council proposals (as described above).

On-Chain Values

Most of the on-chain values can be changed with a unanimous vote of the Technical Committee. The network can also change these values via referendum.

The Technical Committee will have, with democracy’s permission, the ability to change the on-chain version of the cMix software and its services. This ability will be granted via a council proposal in 6-month periods that auto-expire and must be renewed.