In line with the decentralized approach Helium set out with as a project, we have a decentralized governance system in place. Every month, an amount equal to 7.2% of coin emission is made available for proposals put forward and voted upon by the network. Below is a detailed description of how exactly everything works.

Introduction

Decentralized governance was first introduced by DASH founder Evan Duffield as a means to address the problem of funding in a decentralized environment.

While many legacy projects survive on funding provided by early adopters on top of the pyramid, a 'new' blockchain project will always struggle with gathering funds for development. Popular solutions are a pre mine or a pre sale. Both, however, will help a project through its early phases but offer no long term perspective.

The solution proposed by Evan Duffield was to introduce a monthly network subsidy (or superblock). This subsidy is added on top of the regular coin emission (mining/staking and Masternode rewards) and is distributed by means of so called proposals.

Anyone can put forward a proposal and ask for funding. The Masternode network votes on these proposals and decides who gets funded and who doesn't.

With a system like this in place, the network is no longer (entirely) dependent on "the Team" or "the Dev" or any other central authority to sustain itself. It can fund its own maintenance and development and in that way, is one step closer to becoming completely autonomous and decentralized.

The reality, as always, is a bit unruly. The system is not perfect by default. As well as strengths it has many weaknesses and it takes a lot of time and effort to implement it in a meaningful way.

Helium has chosen to implement the governance system in a very early phase of the project but to limit its role for the moment. While the governance system is technically capable of fully governing the network. We chose to stick with the monthly budget for the time being and give the community full control of how that is spent.

Project funding, for now, is provided by the Helium Treasury, which acts independently from the governance system. Read a bit more about that in the Treasury overview.

Below you'll find a step by step, detailed, explanation of all the elements of the Helium governance system.

the Budget

As mentioned before, Helium allocates a subsidy of 7.2% of total monthly coin emission towards the governance system. This seemingly arbitrary percentage was the result of a community vote during the pre-launch phase of Helium.

This 7.2% amounts to a total of 15552 HLM coins every 43200 blocks for Helium's current reward phase. Contrary to popular belief, these 15552 coins are added on top of the regular emission (staking and masternode rewards).

At the end of each budget cycle of 43200 blocks, the coins are be minted in a series of coinbase transactions. The blocks in which these transactions take place are commonly referred to as 'superblocks'. For every winning proposal (more about that below), the network will generate such a superblock and send the freshly minted coins to the proposal's associated address.

The budget is finalized and submitted at the end of every budget cycle. More about that under 'Finalizing the budget'. You can find the next superblock (start of the next cycle) from the debug console with the command mnbudget nextblock. For more console command please consult the Helium command reference.

Proposals

Anyone on the network can submit a so called budget proposal to the network so that it may be voted upon by the Masternodes. [The guide is here.](https://dash.readme.io/project/helium/v1.0/docs/how-to-create-a-budget-proposal)

Submitting a budget proposal is done through an OP_RETURN transaction. This is a special kind of transaction with an unspendable output that can be used to store arbitrary data on the blockchain. In Helium's case this data is the name of the proposal, the value, a URL pointing to a detailed description etc.

Submitting a proposal thus means that a 50 HLM transaction is broadcasted to the network, which stores the information of the proposal on the blockchain. The 50 HLM is burned (this is an anti spam measure) and the network will now be able to see the submitted proposal so that it can be voted upon. After being submitted, the proposal cannot be changed or deleted.

A proposal can be a single payment or a series of payments in consecutive budget cycles. Every installment in a series of payments needs to pass the vote again.

Proposals submitted to the network in this fashion can be retrieved through the wallet with the mnbudget show command in the console. As from version 0.16.0, the Helium wallet also displays them in the GUI under the 'Proposals' tab.

For a proposal to be eligible for voting, the associated transaction needs to be confirmed by the network at least 24 hours prior to the beginning of the next budget cycle.

Voting

Every Masternode on the network can vote on submitted proposals by the principle of one node, one vote. A Masternode can either vote yes, no or abstain. A Masternode can cast one vote per proposal, and can change this vote at any time by resubmitting the vote.

With the release of Helium 0.16.0 voting can now be done through the GUI of the controller wallet (the wallet that holds the collateral for the Masternode). The guide on how to vote on proposals is here.

For a budget proposal to pass and be included in the budget (more about that below), it needs to meet the following conditions:

It must be at least 24 hours old.
Its total of yes minus no votes must be greater than 10% of Masternodes currently online.

If the total value of proposals meeting the above requirements is larger than the total budget, proposals will be paid out one by one, starting with the proposal with the highest net number of yes votes, until the budget runs out.

To illustrate: in the below example only proposal one and three will be paid out.

Proposal one, 10000HLM, 500 yes votes - 100 no votes: net 400
Proposal two, 5000HLM, 450 yes votes - 150 no votes: net 300
Proposal three, 5000HLM , 400 yes votes - 50 no votes: net 350

Votes can be cast until the very end of the budget cycle. However, due to how the budget finalization works, only votes cast at least 2880 blocks prior to the next superblock are guaranteed to be counted. More about that below.

Finalizing the Budget

As hinted upon earlier, the real fun starts during the budget finalization period that starts 2880 blocks prior to the next superblock.

In short, someone on the network needs to submit a budget in order for the superblocks to be paid out. This is a (originally undocumented) feature that was allegedly implemented by Evan Duffield as a means to veto the budget in the event someone found a way to game the system. While regarded as a nuisance by some, it does make things more exciting!

At any point during the last 2880 blocks of the budget cycle, any node on the network may submit a 'final budget'. This final budget is another OP_RETURN transaction with a value of 5HLM that contains the nodes' view on all submitted proposals and their vote count. After 7 confirmations all Masternodes in the network will automatically start voting 'yes' on the final budget, provided it is in line with their own view . If nobody submits a final budget, the superblocks will not be paid out.

To submit a final budget you need a wallet with only a single input of at least 6 HLM(for reasons known only to mr. Duffield it won't work otherwise). You'll need to add the line budgetvotemode=suggest to the wallet's conf file and restart it. The 5HLM transaction is made automatically. If, during the 7 confirmations, additional votes are cast the wallet will resubmit the budget in a new 5HLM transaction. So make sure to have more than the minimum of 5HLM+fee.

Since anyone can submit a final budget and put it up for vote it is normal to have multiple final budgets in circulation. The budget with the most Masternode votes prior to the superblock will be the one used for the budget payout. `

This can be of consequence when there are multiple proposals competing for a spot in the budget. Consider the below scenario using the above example of 2 proposals of which only one will be paid out.

2500 blocks before the end of the cycle node A submits a final budget which receives 1900 Masternode votes. In this final budget, proposal three will be included and proposal two will not. During the next 1000 blocks another 50 Masternodes come online, and as voting is still possible proposal two receives an additional 100 yes votes, pushing it ahead of proposal three. Node B now submits a competing final budget that includes these new votes and receives 1950 Masternode votes. Node B's final budget will be the one used for the superblocks.

the Code

Prior to, and as a part of, the process of bringing our governance system online we consulted a developer of an established project with a functioning governance system. This resulted in a document, intended for internal use, that contains even more details as well as information on how the governance system works on a code level. Since this may be of use to future generations it was made available here:

https://www.scribd.com/document/396806749/Governance