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...

![Hardfork14](http://i.imgsafe.org/6cf4848b6f.jpg)


---

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.

![Initial checks](http://i.imgsafe.org/7b37a71baa.png)


## 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:

![regenerated](http://i.imgsafe.org/7b6b22827a.gif)

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:

![old power loss](http://i.imgsafe.org/7c62949b16.gif)

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:

![Voting power loss](http://i.imgsafe.org/7c3b181296.png)


### New algorithm

Used power (power loss) formula:

![new power loss](http://i.imgsafe.org/7c6d3e10f3.gif)


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%

![Voting power loss](http://i.imgsafe.org/7c3b6b4874.png)
 
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.*