STEEM internals #6: Hardfork #14 and the Voting Change. Everything You Wanted To Know About STEEM Voting Power.

I continue to dive into STEEM internals. Today is a day of STEEM hard fork #14 and I will try to present the technical background of one of the main changes that will happen today - the Voting Power regeneration.

My post will be as usual very technical and I will try to provide a summary on what has changed so that the non-technical people should be able to understand it.

In order to be able to understand the change I compared the full source code of the changes that went into hard fork #14. This post specifically targets the voting method before and after the change. Believe it or not but this one single function that processes a vote contains 343 lines including comments. This is a lot. It took me quite some time to understand it and describe it. And by the way, as a side note on hard fork #14 in general: a huge effort went into savings account and escrow payments implementation. I really like it as it also includes tests for the escrow, really good job.

Hard fork #14 will happen today, on 13th September 15:00 GMT.

---

I somehow wanted the readers to mentally prepare for the technical details and I figured out that the distraction could be the way to rewire the brain. Let's imagine a selfie with the hard fork #14...

---

I hope you are ready, let's start with constants definitions.

STEEM source code contains a few definitions that are later used for vote impact and the voting power calculations. The important ones for this post are:

• STEEMIT_100_PERCENT : 100 %
• STEEMIT_VOTE_REGENERATION_SECONDS (5 * 60 * 60 * 24) : This is 5 days of seconds 5 days * 60 seconds a minute * 60 minutes * 24 hours. 432000 seconds in total.

Additionally there is a global vote_regeneration_per_day property. Until today it was set to 40, after the hard fork it becomes 5.

Vote submission entry checks

Before a vote can be made, vote submission entry checks that a few conditions are met:

• Is the account currently challenged (Hardfork #10), e.g. it is during a recovery process.
• Is the user/account allowed to vote. Apparently some accounts may have can_vote flag set to false and they cannot vote.
• Are votes allowed on the comment.
• Time of the last vote. You can vote every three seconds or less frequently.
• Do you have enough voting power to vote.

Each vote takes a bit of voting power from you

When you start the voting power of your account is set to 100% (STEEMIT_100_PERCENT). BUT with every vote you loose a bit of the power and it start to regenerate with every second after last vote.

The variables are defined in STEEM source code as:

int64_t regenerated_power = (STEEMIT_100_PERCENT * elapsed_seconds) / STEEMIT_VOTE_REGENERATION_SECONDS;
int64_t current_power     = std::min( int64_t(voter.voting_power + regenerated_power), 
                                      int64_t(STEEMIT_100_PERCENT) );

where:

elapsed_seconds contains number of seconds passed since the last vote submitted from given account.

voter.voting_power contains current voting power of the account during last vote.

regenerated_power says how much power was already regenerated.

The current power cannot exceed 100% of the account total voting power, therefore the maximum is set to 100%.

Therefore if you ever wondered how much power do you regenerate, see the equation below:

Theoretically if your voting power goes to 0, it will take 5 days of not voting to fully recharge it to 100%. I will provide a few values at the end of the post.

Power loss before and after the hardfork #14

Two things have changed with hard fork #14. The vote regeneration per day constant changed from 40 to 5 and the used voting power formula is slightly different.

Please see the source code, full analysis is below.

int64_t max_vote_denom = dgpo.vote_regeneration_per_day * STEEMIT_VOTE_REGENERATION_SECONDS / (60*60*24);
FC_ASSERT( max_vote_denom > 0 );
   if( !db().has_hardfork( STEEMIT_HARDFORK_0_14__259 ) )
   {
      FC_ASSERT( max_vote_denom == 200 );   // TODO: Remove this assert
      used_power = (used_power / max_vote_denom)+1;
   }
   else
   {
      used_power = (used_power + max_vote_denom - 1) / max_vote_denom;
   }

Old algorithm:

Used power (power loss) formula:

let's say your current power is 100 percent, you loose 1,5%

let's say your current power is 90 percent, you loose 1,45%

let's say your current power is 80 percent, you loose 1,4%

This is a linear equation and it is easier to understand when you look at the chart:

New algorithm

Used power (power loss) formula:

let's say your current power is 100 percent, you loose 4,96%

let's say your current power is 90 percent, you loose 4,56%

let's say your current power is 80 percent, you loose 4,16%

let's say your current power is 50 percent, you loose 2,96%

I think comparing the two charts you will get a full understanding about the difference.

Additionally I would like to provide a few values that describe how much does the voting power is regenerated per minute, per hour and per day:

• per minute 0,0138889 %
• per hour 0,08333333 %
• per day 20 %

Therefore, full recharge from 0 to 100% takes 5 days.

I hope that you enjoyed my post.

DISCLAIMER: THE INFORMATION IS DELIVERED FREE OF CHARGE AND 'AS IS' WITHOUT WARRANTY OF ANY KIND. I HOPE IT IS ACCURATE AND FREE OF ERRORS AND YOU FIND IT USEFUL.