busybeta

# Effective Curation - Analysis of Curation Rewards in Theory

crokkon
68

Image Source: Chs87, modified, CC-by-SA 4.0

The Steem curation system explained in one sentence is pretty simple: You get rewarded if you are among the first that vote for a popular contribution. Sounds pretty straight forward, right? A more detailed look however reveals that the implementation of this idea in Steem is a beast with various strings and catches.

This analysis post is different from almost all of my previous analyses because it doesn't use a single piece of Steem blockchain data. In this contribution I'm analyzing the implementation of the curation system in the Steem blockchain source code in order to draw conclusions on what conditions make a post profitable in terms of curation rewards.

If you don't care how I got the results, you're scared of mathematical equations or you're only interested in curation tips, scroll down to the "Conclusions" section. ;)

### Outline

• I'll start with an introduction to the Steem voting and curation system
• I'll show how curation rewards are distributed to the voters and will analyze different voting scenarios to show properties of the system
• I'll deduct formulas to calculate the minimum number of payout value required after the own vote to receive curation rewards above the value of the own vote. This is done in a first step without prior votes and in a second step with prior votes.

### Tools

All calculations are done with `python` implementing aspects and test cases around the original the C++ Steem curation system in combination with existing methods in `steem-python`.

## Voting/curation basics

### Rshares

While steemit.com and other interfaces like busy/utopian/esteem/... typically show a post value in "\$" (which is neither USD nor SBD), the actual math is done with `rshares`. Each vote assigns a certain number of rshares to a post. The number of rshares a vote contributes to a post is based on the effective account VESTs (own SP + incoming SP delegations - outgoing SP delegations), the voting power and the vote percentage. The relation between the effective VESTs and the rshare value is linear as shown in the following figure, the VESTs to SP conversion is based on the current `steem_per_mvest` ratio:

A 100% upvote from an account with around 250 SP at 100% voting power corresponds to roughly 10 billion (bn) rshares. The calculations in behind are comparably easy to understand in steem-python's `sp_to_rshares()`.

### Distribution of curation rewards across voters

The payout value of a post is shared between the author and the curators. The author gets at least 75% of the rewards, the curators at most 25%. In reality the average curator share is more in the order of 18-20% (See @miniature-tiger's analysis here for more details). The curator share is distributed in a way such that earlier voters are rewarded with a larger share of the curation rewards than later voters.

For that distribution each vote is assigned a "weight". The weight of a vote depends on its own number of rshares in relation to the number of rshares that are already there from previous votes. Steem uses an approximated square root function to calculate the weight of a vote:

``````weight = sqrt(previous_rshares + vote_rshares) - sqrt(previous_rshares)
``````

The share of the curation rewards for each voter is then defined by the fraction of the own vote weight in relation to the sum of all vote weights.

Here's a made up example with 5 voters all voting with the same rshares value. The table shows the corresponding weight values and the percentage of the curation reward shares:

indexvoterrsharesweightreward %
0voter010 bn328924445.846
1voter110 bn119209316.616
2voter210 bn119209316.616
3voter310 bn90505912.615
4voter410 bn5960478.308

You can see that with 5 identical votes, the first voter would roughly get 46% of the total curation rewards while the second and third voters would only get a bit less than 17% of the rewards. Later voters get gradually less. Rewards below the "dust" limit (0.001 SP) are not payed out at all.

### Reverse auction system for early votes

Simply giving most of the rewards to the first voter is a game human voters cannot win against bots. A bot can potentially upvote a post in the same block that it was published. For that reason the reverse auction system was introduced. Votes placed within the first 30 minutes (HF19) after a post was created have their rshares partly going to the author rewards and only the remaining share is used to calculate the voters curation reward share. This additional part of rewards going to the author reduces the curators share to values below 25%. (NB: the reverse auction system is planned to be changed to 15 minutes in HF20 with the cut off parts of the rshares not going to the author but back into the reward pool).

## So what makes the perfect post for curation now?

First of all, I'm ignoring the reverse auction system for now and assume that all votes are done after 30 minutes. This fixes the author/curator reward share to 75%/25%. This is not true for the majority of posts on Steem, but this simplifies the following calculations considerably and I'll come back to a more realistic estimation at the end.

Additionally, I leave out STEEM/SBD/\$ completely and calculate only with rshares. If a voter deserve a fraction of rshares from the total number of rshares that is bigger than the initial vote rshares, then this voter will receive more curation rewards than his vote alone is worth. That method keeps out all currency conversion steps.

Let's assume I'm `voter2` in the following two examples:

Example 1:

indexvoterrsharesweightreward %
0voter010 bn10368250.000
1voter110 bn3814718.396
2voter210 bn3814718.396
3voter310 bn2738913.208

Example 2:

indexvoterrsharesweightreward %
0voter020 bn14182968.396
1voter210 bn3814718.396
2voter310 bn2738913.208

In the first case there are two voters before `voter2` with 10 bn rshares each, in the second case there is only one voter before `voter2` with 20 bn rshares. Did you notice the the fraction of the curation rewards is exactly the same in both cases?

Conlusion 1: It does not matter how many votes are before you, only the total sum of rshares before you matter

You can still get decent curation rewards from a post with 100 votes before you if the sum of those votes are worth only little. You can also get close to no curation rewards if there is only one vote before you but that vote is much stronger than yours.

Same game, now I'm the first voter, `voter0`

Example 3:

indexvoterrsharesweightreward %
0voter010 bn10368245.788
1voter110 bn3814716.846
2voter210 bn3814716.846
3voter310 bn2738912.096
4voter410 bn190748.423

Example 4:

indexvoterrsharesweightreward %
0voter010 bn10368245.788
1voter140 bn12275754.212

In example 3 there are four voters after me with 10 bn rshares each, in the example 4 there is only one voter after me but with 40 bn rshares. Again, the curation rewards for `voter0` are the same in both cases.

Conclusion 2: It does not matter how many votes come after you, only the total sum of rshares after you matters.

You can get close to no curation rewards even if there are hundreds of votes after you that are worth almost nothing. You can also get a jackpot if there is only a single vote after you from a whale.

### What does it take after my vote to make more curation rewards than my vote is worth?

For that we again assume that I'm the first to vote on a post after 30 minutes. My vote weight is simply the square root of my rshares (`my_rshares` below) since there are no votes and therefore no rshares before me. I can calculate with a single vote after me with `trailer_rshares` since all that matters is the total rshares after me, not the number of votes those are distributed to.

``````my_weight = sqrt(my_rshares)
trailer_weigth = sqrt(my_rshares + trailer_rshares) - sqrt(my_rshares)
``````

From the weights of the two votes I can calculate the fraction of curation rewards the first voter will receive:

``````relative_reward = my_weight / (my_weight + trailer_weigth)
= sqrt(my_rshares) / (sqrt(my_rshares) + sqrt(my_rshares + trailer_rshares) - sqrt(my_rshares))
= sqrt(my_rshares) / sqrt(my_rshares + trailer_rshares)
``````

With the curator share making 25% of the total post payout in this case I can calculate the number of "rshares" that my vote would get me back as curation rewards. By putting this into relation to the number of rshares I placed with my vote, I can calculate my relative return. If this value is > 1 I will get an equivalent of SP as curation reward that is worth more that the value of my initial vote.

``````relative_return = total_rshares * 0.25 * relative_reward / my_rshares
= (my_rshares + trailer_rshares) * 0.25 * sqrt(my_rshares) /
sqrt(my_rshares + trailer_rshares) / my_rshares
= 0.25 * (my_rshares + trailer_rshares) / my_rshares *
sqrt(my_rshares) / sqrt(my_rshares + trailer_rshares)
``````

Ok, so this formula is not super handy when you want to estimate if its worth to place your vote or not. But with a slight modification it gets much simpler: How many multiples of my own rshares are needed after my vote until my relative return gets equal to 1 - this number is `n` below:

``````trailer_rshares = n * my_rshares
relative_return = 1/4 * (1+n) * sqrt(my_rshares) / sqrt(my_rshares * (1+n))
``````

I want: relative_return >= 1

``````0.25 * (1+n) * sqrt(my_rshares) / sqrt(my_rshares*(1+n)) >= 1
``````

This is equivalent to:

``````0.25 * sqrt(1+n) >= 1
``````

This formula is independent from `my_rshares` can easily be solved for `n`: n >= 15. If you got lost on the last steps, here's a summary:

Conclusion 3: If there are more than 15 times the value of your vote after you, you'll get more curation rewards than your vote was worth

Again: this is a simplified case assuming we are the first to vote after 30 minutes. With votes before 30 minutes the factor 0.25 (=curator share) at the beginning gets smaller, typical values are in the order of 0.18 to 0.20. Also a scaling factor for votes before 30 min had to be multiplied.

## What if I'm not the first to vote?

Let's assume we're not the first to vote but there are some rshares already assigned to the post from prior votes. I'm still assuming we're voting after 30 minutes to keep it easier. But you can simply assume a lower own rshare value for earlier votes. I don't want to bore you again with mathematics here, but the idea is the same as above, only the formula gets a bit larger. It now has two variables: the fraction/multiples of our vote already there and the multiples of our vote to come after. Then I calculate the multiples of our own vote required after us until the curation reward exceeds our own vote value. All numbers are again shown in multiples of our own vote value. The following graph shows the number of multiples of our own vote that are required (y-axis) to "break even" with curation rewards if a certain multiple of our vote is already assigned to a post (x-axis):

Let's pick a few example points from this graph:
no prior votes, the leftmost points in the graph:
This is the same result as in the previous section: Without prior votes we need 15 times (25% curator share) the value of your own vote.

Prior votes, same value as ours:
With 25% curation rewards there needs to be around 100 times the value of our vote after us in order to break even with curation rewards. With a curator share of 18-20% this number goes up to 150-190 times our own vote value. If your vote is worth 0.10\$ and there is a post at 0.10\$ at 30 minutes and you vote for it, you need others to vote the post up to 15-19\$ in order for you to get more curation rewards than your vote was worth.

Prior votes, valued 10 times higher than ours:
If your vote is worth 0.10\$ and you vote on a post valued at 1.00\$ after 30 minutes, you need it to go up to >65\$ to break even, for more realistic curator shares even >100\$.

You can reduce your own vote value by the reverse auction function. If you vote at 15 minutes, you're basically voting with half your value from curation perspective. You therefore need to double the number on the y-axis.

## Conclusions

• It does not matter how many votes are before you, only the total value of votes before you matters.
• It does not matter how many votes come after you, only the total value of votes after you matters.
• For ideal conditions with you being the first voter after 30 minutes, it needs more than 15 times the value of your vote after you to get curation rewards that are worth more than your vote.
• With prior votes at the value of your own vote and after 30 minutes, you need around 150-200 times the value of your vote to get curation rewards that are worth more than your vote.
• Don't expect (high) curation rewards on posts with prior votes that exceed your vote value unless you really found a gem.

As long as your crystal ball doesn't tell you the final payout of a post, there are still a lot of unknown factors even with all the math in mind. If you have an idea on what the final rewards will be and you're looking for a calculation of the rewards for a specific post, check @yabapmatt's Curation RewardsEstimator. In general it is hard for users with low SP to get rewards for voting on high-payout posts, because you will either be in the situation that the post value is way above your vote value at 30 minutes or you'll donate large fractions of your rshares to the author because of the reverse auction system. As a rule of thumb, look for total payout values in the order of 100-200 times the value of your vote, because in that case you can get a decent share. Effective curation is nothing limited to high-SP accounts. Check for example @abh12345's curation league for examples of users with very low SP outperforming high-SP accounts in relative curation rewards.

Posted on Utopian.io - Rewarding Open Source Contributors