Image: Fancycrave, CC0, modified
Steem as it is now is criticized for its low rewards for curators, making it financially unattractive to curate content manually. SP delegations to bots or dapps typically bring higher rewards without any work involved. Steem Hardfork 20 (HF20) is announced for a while now. Several details about it were revealed with @steemitblog's "Hardfork 20 (“Velocity”) development update" in December 2017 and there is first code in the GitHub project. One aspect of HF20 are changes to the Steem curation system. Among other things, HF20 is aiming to improve the situation for curators with the following changes:
- Reducing the reverse auction time from 30 to 15 minutes
- Leave unclaimed curation rewards from votes within the reverse auction time in the reward pool instead of giving them to the author.
- Only partly related: Removing the dust vote threshold and downshifting each vote value by around 1.2 SP.
- Curation 101
- How to calculate the author and curator reward share?
- Current HF19 author/curator share
- What if the same votes were done with HF20?
- Moving voting times towards a more realistic scenario
- How much of the rewards remain unclaimed and go back into the pool?
Scope of the analysis and tools
In this post I'm looking into how the content rewards are distributed between authors and curators in the current HF19 and how they may look if the HF20 changes are active. The analysis is based on close to 4 weeks of top-level posts that fulfill the following criteria:
- only top-level posts, no comments
- the posts are payed out with a non-zero author reward
- no posts that declined the payout (this was not necessarily needed, but having the author and curator rewards stored with the post simplified the verification of my calculations)
- only posts with curation rewards enabled (to have meaningful author/curator share rations)
- no posts with beneficiaries set (beneficiaries shift the ratio between author and curator rewards, because parts of the author rewards are payed out to the beneficiaries)
- no posts with changed votes (changing a vote overwrites the initial rshare/weight table, making it hard to reconstruct the author/curator share retrospectively)
- Filter out posts where the correct author/curator share for HF19 could not be reconstructed
The data from April 1st to April 26th 2018 contains 326421 posts that match those criteria. The data was fetched from the SteemSQL database maintained by @arcange. The data was queried and processed with
python and plotted with
matplotlib. The queries and all data processing scripts are on my Github.
Heavily simplified, the Steem curation system could be summarized as: You get rewarded if you are among the first that vote for a soon-to-be-popular contribution. Your share of the curation rewards depends on the value of the post before your vote in relation to the value of your vote and the sum of all votes to come after you. The number of votes before and after is irrelevant. Since being the first to vote on a post is a thing a human voter can never win against a bot, there is the "reverse auction time": The curation share you get for votes within the first 30 minutes is discounted. If you vote at the same time a post is created, 100% of your vote value will go to the authors, nothing to the curators. If you vote at 30 minutes or later, 75% of your vote value will go the author and 25% is distributed between all curators. For more details on the curation system and sample calculations, please see my previous post Effective Curation - Analysis of Curation Rewards in Theory.
How to calculate the author and curator reward share?
The value of each vote is internally calculated with
rshares, a unit depending on the voter's SP, VP and vote percentage. This
rshares value is assigned a
weight as a relation of its value with respect to all previous vote rshares and the voting time if within the reverse auction time. See
vote_evaluator::do_apply() for details about the calculations. The payout of the curators is done based on their vote weight in relation to the sum of all maximum vote weights (excl. the reverse auction deduction). See
database::cashout_comment_helper() for details. With the list of votes and rshares on each post, these calculations can (mostly) be repeated, both with the HF19 as well as with the HF20 curation rules.
In this work, I repeat the calculations for the vote weight, the total_weight and the reverse auction system to determine the payout share of the content rewards between authors and curators. The
total_payout_value and the
curator_payout_value serve as a reference to confirm that my calculations for the current HF19 state are correct. In the same way, I can apply the HF20 changes to the algorithms and get results as if HF20 was active. One thing that is not available retrospectively is the reward fund and the amount of active rshares at payout time. However, the STEEM value of the author share is stored with the post in the
author_rewards field as multiples of 0.001 STEEM. This makes it possible to reconstruct the total number of tokens distributed between author and curators, and allows me to "virtually" distribute the same amount of tokens based on the HF20 rules.
All query, processing and calculation scripts are on GitHub. I'm iterating over all votes of each post, repeating the actual and maximum weight calculations in order to get the author and curator share of the tokens. By modifying the calculation parameters the changed situation with HF20 can be simulated.
Changes from HF19 to HF20
The changes from HF19 to HF20 that I'm considering here are from the Steem 0.20.0 github project. Some of them are merged already, others are still in progress. There is no guarantee that HF20 will go live with exactly these variants.
Reduce reverse auction time: The reverse auction system was initially introduced to give humans a chance for curation rewards against bots who can vote much quicker. With more "short-form content", the 30 minutes are considered to be too long and the window is planned to be reduced to 15 minutes -> Github issue #1878
Lost curation rewards from the reverse auction should go back to rewards pool: In the current HF19 system, a self-vote at the time a post is created gives the author 100% of the vote value as author rewards plus a share of the curation rewards from all following votes within the reverse auction time. This is considered an unfair advantage for the author against other curators. For that reasons, the rewards that cannot be claimed by curators due to the reverse auction system should now go back into the reward pool instead of going to the author -> Github issue #1877.
Remove vote dust threshold: In the current HF19 system you need at least around 1.2 SP to vote. If your vote is worth less you cannot vote. You'll see an error message and your vote will not make it to the blockchain. With HF20 this system is planned to be changed in a way that everybody can vote as long as the account has enough bandwidth. This is motivated with user experience improvements. However, all votes are shifted down by around 1.2 SP in value. A vote the was "worth" 1.2 SP in the current system will be worth nothing now, but go to the blockchain anyway. Tiny votes below the value of a 1.2SP value will have zero value. This is intended to make it less attractive to cast lots of low value votes -> Github issue #1764.
Current HF19 author/curator reward ratios
With the current system of giving unclaimed curation rewards from votes within the reverse auction time to the author, the ration between author and curator rewards is shifted away from the target 75%/25% author/curator share towards higher percentages for the author.
Example: An author upvotes his own post at creation time to $10. Other voters add another $10 after the reverse auction time. The first $10 will fully go the author due to the reverse auction system. From the second $10, $7.5 go to the author and $2.5 to all curators. By summing those up, this makes $17.5 for the author and $2.5 for the curators. This corresponds to 87.5% for the author, 12.5% for the curators.
This graphs shows the curator shares of all posts that matched the selection criteria above. The histogram on the left contains one entry per post with the ratio of the curator share w.r.t. to the total payout. The mean curator share on this data set is 14.6%, the median share is 17.6%. The pie chart on the right sums up all tokens payed to authors and curators, giving a share between authors and curators by value. The curator share for this data set makes up 18.4% of the total payed out content rewards.
What if the same votes were done with HF20?
Now let's repeat the same calculations with the reduced reverse auction time, the unclaimed curation rewards going back to the pool and with the dust vote shift applied:
We can see that the exact same voting behavior with HF20 would give a mean curator share of 16.6% and a median share of 20.6% by number. Summing up the rewards now makes 20.9% for the curators. That's 2.5% more than with HF19!
However, assuming the exact same voting behavior with HF20 can be very misleading. The following graph shows how often and with how much value votes to these posts were done within the first hour after the post was created:
The histogram on the left shows the number of votes in relation to the post age. The histogram on the right shows the same by value (rshares). In both cases we see clear peaks at "common" post age times. The first and strongest peak at 0 minutes are votes that are cast immediately when the post is created, typically by the author or an associated account. The second strongest peak is at 30 minutes, exactly at the end of the current HF19 reverse auction time. Both histograms show another peak at 15 minutes and a general increase in the number and value of votes between 20 and 25 minutes. The by-value histogram on the right has another peak at around 28 minutes. These voting signatures before or at 30 minutes are likely auto-votes. With a reduction of the reverse auction time from 30 to 15 minutes, those are very likely to change as well. Everybody who has an autovote set to 30 minutes now will certainly change this to 15 minutes with HF20, and earlier votes accordingly.
Moving voting times towards a more realistic scenario
For a more realistic HF20 scenario, I'm dividing now all vote times by 2. A vote that was at 30 mins before (at the end of the HF19 reverse auction time) is now at 15 mins (at the end of the HF20 reverse auction time). A vote that was at 20 mins with HF19 before is now calculated as if it were done at 10 minutes with HF20. I think this is a reasonable assumption, because hardly anybody will leave autovotes later than 15 minutes with HF20.
Now the picture looks different:
The mean curator share is now down to 15.5% and the median value to 19.1%. Looking at the distribution by value gives 19.7% of the post rewards to the curators. That's only slightly more than the current HF19 distribution.
How much of the rewards remain unclaimed and go back into the pool?
Unclaimed curation rewards in HF19 go to the author. This means that the full "post value" is payed out. With HF20, parts of the curation rewards remain unclaimed and are not payed out. The following pie chart shows the share of unclaimed rewards for the current HF19 and the HF20 case with the voting times divided by 2:
The HF19 chart on the left shows that all tokens are payed out. The share between author and curator for the HF19 case is the same as shown above. With HF20, parts of the curation share is unclaimed. Summing those up make around 6.6% of all tokens. You can see that this is exactly the share that goes to the authors in HF19. This basically means that in the HF20 scenario around 93.4% of the pending payout as shown in condenser or busy is actually payed out. The remaining part remains in the reward pool, increasing the overall payout and vote value for everybody in the same way.
The following table summarizes the numbers presented above:
|Scenario||Mean curator share per post||Median curator share per post||total curator share by value|
|Current system (HF19)||14.6%||17.6%||18.4%|
|HF20 with the same votes||16.6%||20.6%||20.9%|
|HF20 with reduced voting times||15.5%||19.1%||19.7%|
With the current HF19 system, curators get between 14-18% of the post rewards depending on which metric is used. Calculating the curator share with the same posts and votes as if HF20 were active increases the curator share by around 2-3%. However, with the changes in the reverse auction time the voting behavior will change as well. A reasonable assumption is that all votes within the reverse auction time will be done a factor 2 earlier. This increases the curator share to only slightly more than 1% compared to the current state. So even though around 6% of the post rewards might remain unclaimed in HF20, the share of the curators from the total payout increases only slightly. Does it change anything for curation bots? To my understanding not a single thing. Curation bots will then wait 10-15 minutes before a vote instead of 20-30 minutes and probably even have more of an edge against humans, because nobody is online 24/7 to wait for the perfect post.
This analysis assumes that the amount of self-votes at post creation time remains the same as now. That's pretty lucrative for authors now. With HF20, authors would "sacrifice" 25% of their vote value with an insta-self-vote. A later self-vote would also give 75% to the author, but makes the author eligible for curation rewards as well. Analyzing the most profitable (self-)vote time with HF20 would easily be a post on its own and depends on all other voters as well. There might be behavioral changes involved with HF20 that increase the curator share. If however the author becomes it's own best curator, this obviously is not a gain to the current system.
...won't change much for curators. Happy vote & delegation selling.
Proof of Work
N.B.: I'm still hoping that I somehow messed up the calculations and the situation with HF20 will actually become much better for curators compared to now. If you find any issues, please let me know in the comments!