EOSIO blockchains utilize Delegated Proof of Stake (DPoS) to determine who the network’s validators will be at any given moment. To understand how the votes cast by the user base are calculated over time, we are going to look at the algorithms that underpin how vote strength is calculated on an EOSIO blockchain.

Why Do Votes Decay?

On the previous project from Dan Larimer (Steem) there were many votes cast in the past, but are no longer relevant. This is abundantly clear when a Steem Witness (their name for a Block Producer) is no longer active, but it is still receiving votes.

According to hivekings.com, at the time of writing of this article, to determine who the top 100 Witnesses are, you have to go through the top 109 Witnesses by votes. This is due to 9 having declared themselves no longer active, or not participating within the latest hard fork, yet still receiving enough votes to be considered a top Witness.

To combat this, Block.one introduced the idea of vote decay when they released Dawn 4.0 at the beginning of May 2018: “In order to maintain maximum voting influence each voter will have to re-assert their vote every week. Voting influence decays with a half-life of 1 year for those who do not keep their votes up to date.”

What is the Math Behind Vote Decay?

When you dig into the code controlling how the vote decay is calculated, you’ll notice that votes don’t actually decay. Rather, it’s that all new votes have a stronger vote strength than old votes, which is a clever and efficient way of obtaining the same effect. Let’s go through the formula together to understand. (For those unaware, the word double in the math below is part of the C++ coding language, and is not meant for doubling of anything)

Math Behind Vote Decay 1
Math Behind Vote Decay 2

It should be noted that for block_timestamp_epoch, the EOSIO software uses seconds since January 1, 2000, and that the standard Unix timestamp counts seconds since 1970. If we translate this formula into pseudo-English, it would look more like this:

Math Behind Vote Decay 3

Then the value of weight is used in:

Math Behind Vote Decay 4

By taking the integer part in the first equation, it is effectively saying that your vote strength can be increased weekly, but not more often. If a user wanted to keep their vote at peak strength, they would want to vote each week at 00:00:01 UTC on Saturday. A user’s vote strength will also be considered full if they perform a delegation or undelegation action (stake or unstake). Any change within their REX balance will also bring a user’s vote strength to full.

Every week, by revoting, a user increases the relative strength of their vote by approximately 1.34%. While this is not a massive amount, spread out over thousands of accounts, this amount can have an effect on which Block Producers make it into the Top 21, as well as the Vote-based payout that each paid Producer receives.

Walking Through a Calculation of Vote Weight

To help understand the math, we’ll walk through a calculation together. We’ll paste in screenshots to help you follow along.

The first step is to grab the information on the account from the blockchain. To do this, we used eosc and entered the command eosc get account [ACCOUNT NAME] --json which returned this at the end of the JSON (the owner and proxy accounts have been removed from this photo):

the owner and proxy accounts have been removed from this photo

This account is showing no Block Producers listed next to producers as this account is using a proxy for its vote. We can see it’s staked amount of 4176500 (which is equivalent to 417.6500 EOS, as the system disregards the decimal, and there are 4 decimal places in an EOSIO blockchain by default). We can also see the target for our calculation next to last_vote_weight.

We then went to eosq to find the time of the last voting action, where this account re-cast its vote for its chosen proxy.

this account re-cast its vote for its chosen proxy 

From there, we can plug that time into a unix time converter making sure to translate the time into the UTC timezone.

timestamp converter

While at the unix time converter, you can grab the time for January 1, 2000, at 00:00:00 UTC as that is what the blockchain uses for the block_timestamp_epoch. This number, for reference is 946684800. You will now have all of the data needed to perform the calculation.

making the calculation part 1
making the calculation part 1
making the calculation part 3

What About if I Proxy My Vote on EOS?

If a user has chosen to proxy their vote, they will still need to recast their proxy vote if they want to maintain the strongest vote strength that they can. This will also help to ensure that a user confirms that the proxy that they have chosen is still active and is still maintaining their voting standards as they claimed they would.

If the account that you have chosen to proxy to does not recast their vote, this will not affect your vote strength. Only their own staked amount will not be increased to the current maximum.

How Does This Affect the Results?

If you’d like to see how vote decay is currently affecting the vote results of Block Producers on many different public EOSIO mainnets, you can go through EOS Authority’s Voting Decay Analysis which tracks the decay of vote strength on the network. You can toggle between networks in the upper righthand dropdown menu. 

How Do I Cast My Vote?

While there are many voting tools available to you, dfuse recommends our multi-functional open source tool eosc. Once you’ve got it set up for your account, you can enter the command eosc vote producers [YOUR ACCOUNT NAME] [LIST OF PRODUCERS] and it’s as simple as that.

Let us know if there are any other technical aspects of EOSIO that you’d like us to showcase. Be sure to join the discussion on Telegram or Twitter, and let us know what you’re building!


This article has been updated from its original version found here