Hardfork20 Curation Analysis

The Velocity hardfork included some significant changes to the Steem blockchain curation mechanics. In this analysis I take a look at the initial impact of these changes and what they mean for curation rewards.

---

---

Introduction

The Velocity hardfork included some significant changes to the Steem blockchain curation mechanics.

Under HF19 a reverse auction window operated for the first thirty minutes of any post. During this period an early voting penalty reduced the rewards awarded to the curator. The penalty started at 100% of the curation reward at time zero and scaled linearly down to zero over the thirty minute window. The amount of the penalty was awarded to the author of the post, increasing their overall rewards.

The aim of this system was to prevent automated bots from gaming the curation rewards by immediately upvoting popular authors, whilst also allowing curators sufficient time to find, read and make a decision on whether to upvote a post.

Whilst the broad mechanics of this system have been retained under HF20, two important changes have been introduced:

• The reverse auction window has been reduced from 30 minutes to 15 minutes in duration:

This adjustment reflects the changing nature of content on the blockchain and responds to the view that curators no longer need 30 minutes to make their upvoting decisions for the majority of Steem posts.

• The early voting penalty is now returned to the reward pool rather than being awarded to the author.

This change was made to level the playing field between the author and other curators. Awarding the early voting penalty to the author allowed them to upvote their own content immediately after posting and retain the rewards for doing so; a luxury not afforded to any other curator. It was hoped that this redistribution would adjust the balance of rewards between authors and curators.

So how have these two changes impacted curation in practice? I take a look at some early results from HF20 below.

---

Results and Conclusions

1 . Vote Timing

To begin, let’s look at the impact of the changes on the timing of votes. I have analysed the voting patterns from all posts created on September 1 (excluding comments) to illustrate a typical day under HF19. I compare this to October 1 as a representative day from HF20.

The HF19 chart preceeds the HF20 chart (and does so in all the comparisons that follow). I am focusing exclusively on the first hour of all posts, as this is where all the action is, but I add relevant statistics from outside this period as necessary. Each green bar is the value of votes added to all posts from each minute of voting, with all figures expressed in STU.

At first glance there are some obvious and expected changes:

• On the HF20 chart the 15 minute reverse auction period has almost emptied out of votes.

The voting in the first minute is significantly reduced and the level of voting that follows throughout the first 15 minutes is also considerably lower than under HF19. For posts created on September 1, 23% of the total vote value obtained over the seven day voting period was added within the reverse auction period (the first 30 minutes). On October 1 the comparative reverse auction period figure, albeit measured over only 15 minutes, was just 6%.

Curation rewards are higher for earlier upvoters. A lower level of votes in the reverse auction window should result in lower curation penalties and potential for higher curation rewards at the end of the window. Both are good news for curation rewards.

• The main spike in voting has moved from 30 minutes to 15 minutes in line with the change in the reverse auction window.

A large proportion of voting on Steem is automatic. I expect that much of the vote spike remaining at 30 minutes will move to 15 minutes as auto-curators update their trails.

2 . Self voting

The change in voting in the first minute, as illustrated above, suggests a substantial reduction in immediate author self-voting. Let’s have a look at the charts.

The HF20 chart shows a significant reduction in self-voting in the first minute (the silver bar) but a growth of self-voting around the 15 minute mark. These changes balance out. In fact the overall amount of self-voting was almost entirely unchanged, at 3.6% of the overall vote values cast.

However authors no longer have an ingrained advantage and, if choosing to self-vote, are now competing with other curators around the fifteen minute mark.

I would argue that this effect is as expected under the design change and represents more good news for the balance of rewards between authors and curators.

3 . Bid bots

Another significant change can be seen in the timing of bid bot paid voting services.

Under HF19 it was beneficial for authors to purchase upvotes early in the life of their posts. This tactic resulted in early voting penalties that would be passed their way rather than flowing to the owners of the bid bots. We can see in the HF19 graph a significant volume of purchased votes (the blue bars) arriving within the first 30 minutes.

This benefit no longer exists under HF20. Authors do not benefit from any share of the curation rewards within the first 15 minutes since the penalties are now passed to the reward pool. A high early post payout value may even be a deterrent to some curators.

So who benefits from this change? Again, it should be good news for curators:

• Lower upvotes in the reverse auction period should mean higher curation rewards.
• The possibility of bid bot front-running, an idea which had somewhat fallen by the wayside due to the large volume of early paid votes, could also make a comeback.

The HF20 curation changes are also likely to be good news for bid bot owners. Their own curation rewards should increase now that they are no longer losing early voting penalties to authors.

However the bid bot market is fairly competitive and due to its auction-based nature it is somewhat self-regulating in terms of profitability. It will be interesting to see how the market adapts. We could see lower levels of bids from vote purchasers, increased promotional offers from bot owners or higher payments to delegators.

4 . Curation rewards!

Having considered all of the above, let’s have a look at the actual curation rewards for our two representative days.

The above charts include an indicator of curation rewards. This has been calculated using the following formula:

"Curation rewards obtained from votes made in this minute (STU) / Value of upvotes made in this minute (STU)"

Simply put, the indicator represents curation rewards expressed as a parentage of vote values, so 100% would be a reward equal to the face value of your upvote.

The most interesting aspect of the chart comparison is the clear difference in the patterns of curation rewards. Under HF19 the average curation rewards for each minute are suppressed by early voting and never really rise above the long-term 25% level. Under HF20 there is a hump of curation around the 10-15 minute mark indicating the potential for high rewards.

Whilst the overall level of the curation reward indicator is also higher in the second chart I would note that this is mainly due to the increase in the reward pool since the start of October. The curation reward payouts on 8 October are from a significantly higher reward pool than the vote values on 1 October. Rebasing the votes and ratios using the rshares / STU exchange rate on 8 October produces the following chart:

Whilst the long term ratio of rewards to vote values has returned towards 25%, as would be expected, the good news is that the initial hump and its promise of high curation rewards remains.

5 . Curation sweet spot

So in which minute is the HF20 curation sweet spot?

The HF20 chart above in section 4 suggests somewhere between 9 - 14 minutes, somewhat earlier than I had expected. However it’s worth noting that the volumes of upvotes at durations 9 - 13 minutes are low and the higher ratios may only be supportable for smaller votes.

As an alternative approach to deriving the vote-timing sweet spot I analysed the upvotes of the 100 top curators for October 1 (ranking excludes rewards from edge-cases and imposes a minimum overall upvote value for the day of 1STU). Here are the combined results:

Lots of ratios above 100% for some nice rewards! What can we learn?

• The curation ratios do not provide a clear view as to any particular sweet spot. It could be argued that each post must be judged on its own merits. Whilst 15 minutes would always be a theoretical latest-point-of-upvote there will always be posts that have been overlooked and can produce good rewards even at later durations. This analysis has also been conducted early in HF20 and it’s possible that some clearer trends will emerge after a few weeks.

The top curators were mainly upvoting around the 14-15 minute mark, as would be expected. Again this timing may evolve in the coming weeks as upvoting strategies mature.

Conclusion

Curation rewards are an important lever in the Steem blockchain mechanism for finding and rewarding the best content. Under HF19 it was clear that this mechanism did not function as required.

Whilst I do not believe that HF20 introduces a complete solution to this complex problem, the changes certainly appear a step in the right direction. The potential for higher curation rewards provides greater incentive for manual voting, and increased human interaction should lead to improved content discovery.

However it is unlikely that we will see a fundamental reshaping of the Steem economics from these changes, nor an end to the bid bot era. For such a restructure, a little patience is required until the arrival of SMTs.

---

Repository:

This analysis relates to the HF20 Velocity changes for the Steem blockchain. The repository is here:
https://github.com/steemit/steem

---

Tools and scripts:

I used the block.ops analysis system to produce this study. Block.ops is an open-source analysis tool designed for heavy-duty analyses of the Steem blockchain data. It is currently under construction and this is the first complete analysis from its depths.

You can find the repository for block.ops here:
https://github.com/miniature-tiger/block.ops

(Note that the code for some of the functions required to produce this analysis is still to be tidied and committed to GitHub. This will take place in the next few days.)

---