Skip to main content

Governance overview

Governance exists for the community of token holders to decide on key issues involving the blockchain and its development. This is achieved by proposing items of business to be voted on by the token holders.

There are three forms of governance proposals on Gitopia:

  • Text-based Signaling Proposals

    Proposal to agree to a certain strategy, plan, commitment, future upgrade or other statement. Text proposals are exclusively a signalling mechanism and focal point for future coordination - they do not directly cause any changes.

  • Chain Parameters Change

    Parameter changes or software upgrade proposals are technical changes to how the network runs, ideally, that will not halt or disrupt the network in a significant way in terms of downtime.

  • Token Allocation/Budjet Allocation

    The outcome of this type of proposal will be the transfer of funds from the community pool to the address and for the amount nominated in the proposal.

Governance Procedure

In the current Gitopia governance implementation anyone can submit a proposal to the system. A minimum deposit is required for a proposal to enter the voting period during which LORE holders will be able to vote on whether the proposal is accepted or not.

Phase 1: The Deposit Period

For a proposal to be considered for voting, a minimum deposit of 10 LORE needs to be deposited within 2 days from when the proposal was submitted. Any LORE holder can contribute to this deposit to support proposals, meaning that the party submitting the proposal doesn’t necessarily need to provide the deposit itself. The deposit is required as spam protection. This period lasts at most 2 days, but if the minimum amount of 10 LORE is reached sooner the proposal will pass to voting immediately.

If the proposal is accepted or never reaches the minimum for a voting period the deposit is returned; if the proposal fails, the deposits are claimed by the treasury. It is important to remember that any contributed LOREs are at risk of being burned. Deposits are burned only when proposals are vetoed i.e. 33.4% of voting power backing the 'NoWithVeto' option.

Phase 2: The Voting Period

When the minimum deposit for a particular proposal is reached the 2 hour long voting period begins. During this period, LORE holders are able to cast their vote on that proposal.

There are 4 voting options (“Yes”, “No”, “No with Veto”, “Abstain”). Voters may change their vote at any time before the voting period ends.

What do the voting options mean?

  • Abstain: indicates that the voter is impartial to the outcome of the proposal.
  • Yes: indicates approval of the proposal in its current form.
  • No: indicates disapproval of the proposal in its current form.
  • NoWithVeto: indicates stronger opposition to the proposal than simply voting 'No'. If the number of 'NoWithVeto' votes is greater than a third of total votes excluding 'Abstain' votes, the proposal is rejected and the deposits are burned.

Phase 3: Tallying Results

If a proposal is accepted depends on the result of the voting by LORE holders. The following requirements need to be satisfied for a proposal to be considered accepted:

  • Quorum: More than 40% of the total staked tokens at the end of the voting period need to have participated in the vote.
  • Threshold: More than 50% of the tokens that participated in the vote (after excluding “Abstain” votes) need to have voted in favor of the proposal (“Yes”).
  • Veto: Less than 33.4% of the tokens that participated in the vote (after excluding “Abstain” votes) need to have vetoed the decision (“No with Veto”).

If one of these requirements is not met at the end of the voting period, e.g. because the quorum was not met, the proposal is denied. As a result, the deposit associated with the denied proposal will not be refunded. These funds will be sent to the community pool.

Phase 4: Implementing the Proposal

Once a governance proposal passes, the changes described are put into effect by the proposal handler. Generic proposals such as a Text Proposal must be reviewed by Gitopia developers and the community for decisions on how to manually implement.

Once a parameter change or software upgrade proposal is voted on and passes all conditions it will need to be integrated into a new version of the Cosmos network software by validators while the previous working version continues to run. This is signalling that a switch will occur. Once more than 2⁄3 of the validators download this new version and signal they are ready to make the switch the rest of the network is expected to do the same.