Ergo Emissions Soft-Fork and Proof-Of-Voting Tokens

From the Team |  January 8, 2021 



Lately, there has been lots of talk in regards to a new soft-fork on the Ergo blockchain, with the goal being to extends Ergo’s emissions curve and possibly ensure the future of the protocol. Such a decision will have a large impact on miners, who currently support the protocol and receive rewards according to the emissions curve. 

There has been much discussion by people for and against the soft-fork, and many good arguments have been provided by both sides. As a mining pool on the Ergo blockchain, stands in a unique position of power in that we can control the voting decisions of all of the miners currently mining to our pool. 


Moreover, as closes in on creating the first smart-contract based mining pool on Ergo, we will be able to have increased functionality that other pools cannot offer. In terms of the soft-fork, wishes to be completely neutral in its decision on the vote. Instead, we wish to provide our miners a way to vote for our decision on the soft-fork. 

We feel that this would be most fair to the miners, who are the ones truly supporting the network and our pool. This paper will describe’s proposal for a novel “Proof-Of-Voting” mechanism. This mechanism will ensure that miners mining to’s SmartPool will have a fair say in our vote for the emissions soft-fork. It is our goal to give our pool’s miners a right to contribute their votes in a manner that is as trustless as possible. 



To begin, we believe that there must be three key features in our “Proof-Of-Voting”(PoV) mechanism that ensures the security of the vote and its ability to be verified by third parties. The features are to be the following: 

  1. The pool operators ( must be incentivized to follow the miner’s votes. 
  2. The miners must be able to vote easily, and each miner’s voting power must be proportional to their hashrate. 
  3. There must be a way to uniquely prove that the pool is voting according to the miner’s decisions. 

These three features are necessary in order to keep the vote as trustless as possible. For example, if there was no incentive for the pool operators to follow the vote, then there is no reason that they would. Because voting is achieved by changing settings on the node, the pool operators hold all the power in being able to change the vote according to their preferences. Therefore, the only way to ensure that the pool operators vote according to the miners is to incentivize them.

Likewise, miners must be able to vote easily and their votes must be proportional to their hashrates. This is important because we wish to give miners the exact same voting power that they would have if they had instead decided to solo-mine. We also wish to make voting as easy as possible, so that less technically knowledgeable miners can still contribute to the vote. 

Finally, there must be a way to prove that the blocks submitted by the mining pool follow the majority vote decided by the pool’s miners. This PoV mechanism must be as trustless as possible, so as to ensure that any third party can verify whether or not the pool operators are following the miner’s votes. This is also necessary so that the pool operators are properly incentivized to follow the majority vote. 


The PoV Smart Contract and Tokens

We shall now describe the collection of smart contracts, tokens, and off-chain code required to build a proper Proof-Of-Voting mechanism that holds the three key features mentioned earlier. 


The Pool Operator Incentive

To begin, we must first ensure that the pool operators are incentivized. With’s SmartPool, this is extremely easy to do. As part of our current SmartPool solution, there is a set of values called the “Pool Fees” that represent some percentage of the pool’s total mining rewards. 

In order to show a commitment to fairness and provide an incentive for us, will be sending its normal pool fees to a new smart contract. We can simply call this contract the “fee contract” and it will hold our incentive to vote according to our miner’s decisions. 

The fee contract will take the usual pool fees (currently set at 1%) from before, and during the voting process, and will instead lock them. The fee contract will be made so that, a singular token is required to unlock and therefore spend each box protected by the fee contract. We will call this token our PoV token, and holding it provides proof that at least one of the blocks submitted by our pool followed the majority vote decided by our miners. In order to ensure that no re-usage of tokens occurs, the fee contract will check to ensure that each PoV token is burned upon unlocking of a fee contract box. 


The Miner’s Voting Tokens

The next step for our PoV mechanism is to ensure that miners can vote easily and proportionally to their hashrate. Due to the nature of’s SmartPool, this too can be done quite simply. 

An important part of our SmartPool system is called the “Command Box” which is a box under any script that provides details for how the distribution transaction is to be carried out and the number of shares that each miner gets. 

For this instance, will be creating a custom command box that will hold a set number of “Vote Tokens”. Each command box that will be used to distribute our normal mining rewards will now also distribute these new Vote Tokens. 

The contract that protects the command box will ensure that vote tokens are distributed according to the share numbers for each miner provided by the “Share Consensus” portion of the SmartPool. This is essentially the same thing that is already done by the Holding Contract portion of the SmartPool, so the code required to make such a command box is essentially already made. The only thing to change will be that vote tokens will be distributed rather than ERG. This gives miners a way to vote proportionally to their hash power. 


 In order to ensure that voting is easy and verifiable, 2 separate smart contracts, which we shall now call the “recording box contract” and the “ballot box contract” will be made. 

The recording box contract will be made so that one specific box will record each voting transaction. This box, called the recording box, will hold a special NFT called the recordingNFT. 

This NFT will be used to identify the recording box. When a miner wishes to vote, they will first send their vote tokens to a new ballot box protected by the ballot box contract. Each ballot box will store the public key of the miner that sent the votes to that box, along with a simple byte indicating a vote for or against the soft fork(“yes” or “no”). 

If a miner wishes to change their vote, they may spend their ballot box through the Dashboards Website UI, and send their tokens back to their own wallet. If a miner wishes to confirm their vote, they may spend their ballot box in addition to the current recording box which holds the recordingNFT. 

The recording box will hold the number of yes and no votes in its registers. Every time a miner spends the recording box, a new recording box must be in the transaction’s outputs, and this new recording box will have either its “yes” register(indicating votes for the soft fork) or its “no” register(indicating votes against the soft fork) updated. 

The register to be updated is of course decided by whatever option the miner indicated in their ballot box. The outputted recording box must also have the recordingNFT inside of it again, so that other miners may later find the correct recording box and use it to submit their own votes. After every confirmed vote, the voting tokens are burned so that they may not be used again. Our goal is to make a simple UI for this process so that miners can easily submit votes without having to directly deal with the smart contracts and their implementation. 



The Proof of Voting Mechanism

Finally, with a recording box that holds the majority vote, along with an incentive for the pool operators, we must be able to prove that the pool operators followed the majority vote so that they may receive their incentive for voting properly through the node. 

We shall create one last contract, called the PoV contract. Each box under the PoV contract will hold exactly 1 locked PoV token. The PoV contract will ensure that if a box protected by it is spent in a transaction, the block that the transaction is included in will have 2 key properties: 

  1. The block miner’s public key is the public key of the pool operator. In this case, we will be checking to make sure that whatever block this transaction is included with has the public key of our node’s wallet that we use to mine blocks with. 
  2. The “miner votes” section of the block will either have voting bytes if the current recording box has a majority of “yes” votes, or will be empty if the current recording box has a majority of “no” votes.  

Upon spending a PoV box, a new outputted box with exactly 1 PoV token will be created under the pool operators wallet. In order to ensure that this transaction is not propagated throughout the network(so as to save space in other node’s mempools) we will use the “candidateWithTxs” API request from the node to include these spending transactions in every block we mine. 

Once the pool operators obtain their singular PoV token, they may use it to unlock a box under the fee contract so as to get their incentive. In order to do this correctly, there must be a list of pre-generated PoV boxes, each one having exactly 1 PoV token inside of it.  


With this, we at believe we have successfully created a set of smart contracts, tokens, and off chain code that follow the 3 key features listed earlier in this paper. is committed to ensuring its miners have a fair say in the upcoming soft-fork vote, and we hope that this novel idea will help ensure that it can be done in a manner that stays as trustless and fair as possible.