New to Busy?

How will the HF20 dust vote changes affect the vote values?


10 months agoBusy6 min read



A release date for HF20 was finally announced for Sept. 25 2018. HF20 brings a couple of very exciting changes. One aspect that has led to some confusion among Steem users is the change to the vote dust threshold.

Current situation (HF19):
If a vote would result in less than 50M rshares (approx. equivalent with voting with 1.2 SP), the voter sees an error message and the vote is not recorded in the blockchain.

New implementation (HF20):
Any vote will make it to the blockchain, there will be no error message for very small votes. However, the rshares value of each vote will be reduced by 50M rshares, or set to 0 if it had less than 50M rshares initially.

This has two implications:

  • an upvote or downvote can have a value of 0 and does not contribute to the payout of an author
  • the rshares value of all votes is reduced by 50M rshares

Scope of the analysis and tools

There was already some confusion about users being afraid of losing their vote value. This contribution simulates the HF20 rules on one week of current voting data to show the differences between the two implementations.
All data is queried from SteemSQL and contains all votes that were cast between Aug. 1st and Aug. 7th 2018, one week of data. Data collection and processing is done with python and matplotlib. All scripts to query the data and create the following plots are on my GitHub.

Relative loss of vote value in rshares in HF20

The absolute rshares value of each vote is reduced by 50M rshares, which is equivalent to around 1.2 SP. This table and graph show a few examples:

SPrelative value loss in rshares
1.2 SP100.00 %
5 SP24.00 %
10 SP12.00 %
15 SP8.00 %
100 SP1.20 %
1000 SP0.12 %
10000 SP0.012 %
100000 SP0.0012 %


If a vote was worth 1.2 SP before, it will be worthless with HF20. A 15 SP vote will lose around 8% of its value in rshares. A 100 SP vote will give up 1.2%, a 1000 SP vote loses 0.12%. The more SP an account uses to vote, the less affected is its vote value.

However, since all votes are reduced by a fixed offset the total sum of all rshares (which partly define the $ value of a vote) is reduced as well.

How much does the downshift increase the $ value of all votes?

All vote rshares are reduced by up to 50M rshares. As a result, the sum of all rshares will be less than before with the same votes, reducing the recent claims and therefore increasing the $/STU value per vote. The following graph shows the daily sum of all vote rshares for the given week with the measured HF19 values and the calculated HF20 values.


You can see the HF20 line slightly below the HF19 line, but only with a very small difference. Summing up all rshares from that week for both HF19 and HF20 gives a difference of 0.1%. The sum of all HF20 rshares is 99.9% of the sum of all HF19 rshares. The value of each vote therefore increases by 0.1% (assuming otherwise static conditions).

Applying HF20 to to one week of HF19 votes

This graph shows the distribution of vote rshares for that given week of votes with the current HF19 system:
You can see that there are no votes below the vote dust threshold because those are denied by the blockchain. The median vote value is 567M rshares, equivalent to a 100% upvote with 14 SP. The mean value is at 49.8 bn rshares (~123 SP).

Applying the HF20 shift moves the entries in the histogram:

We can see that there are now votes with rshare values below the threshold due to the shift. In real HF20 data we will also see a number of votes with 0 rshares, which are not possible right now. The median vote value is reduced to 517 M rshares (~12.8 SP), the mean value was reduced by 50M rshares.

For both distributions, there's a strong peak of votes with around 14 SP, which suggests that a large portion of the voting accounts (by number) have around that amount of SP.

How much does the downshift reduce the value of individual votes?

The static downshift clearly affects smaller votes more than larger votes. The following graph shows the relative loss of vote value in rshares due to the downshift:


Around 20% of all votes in that week would give up less than 1% of their vote value. Around 50% of all votes would give up less than 9% of their vote value. Around 30% of all votes would give up 15% or more of their vote value.


  • All votes will be reduced by up to around 1.2 SP. The more SP is used to vote, the less the vote value is affected.
  • The steemit-funded accounts around 15SP will give up around 8% of their vote value.
  • If the voting behavior stayed the same as now, the value of each vote would be increased by around 0.1% due to a lower total sum of active rshares in the chain. This would compensate the value loss for accounts with around 1000 SP or more, all others would still lose slightly.
  • around 20% of all votes will see a value reduction of less than 1%, 30% will give up 15% or more.

This work assumes that the voting behavior (by vote number and value) will stay the same with HF20 as it is now. This is not necessarily the case. Large portions of the votes are done with around 14 effective SP. If the voting accounts don't have more SP, they have no choice but to live with a 8% reduction in rshare value. However, if the voting accounts have more SP, they will certainly change their voting behavior to fewer but higher value votes. This will immediately shift the distribution in the loss of the individual votes towards more accounts with less losses.

Edit: Live example:

  • The first voter on this post was a 1k SP account, specialized on making decent curation rewards, with around 200M rshares from a 0.75% vote. It is unlikely that this bot will keep that voting behavior in HF20, since this would gives up a quarter of the vote value.
  • The second voter was a 15 SP account that voted with 100%. This account has no choice but to accept a ~8% reduction in vote value in HF20.

GitHub Account


Sort byBest