## The problem

I believe most people would agree that it would be fair if curation rewards were roughly proportional to user's steem power. E.g. suppose one user has 1000 SP and another has 1 SP, then in an identical situation the first one should receive a reward which is approximately 1000 times bigger.

But that's not how it works in Steem.  Steem [squares percent increase](https://steem.io/getinvolved/paid-to-curate/) and thus a user with 1000 SP will have roughly 1,000,000 bigger reward than a user with 1 SP in the otherwise identical situation.

Let's  convert it to dollars to get a better understanding.  Suppose Alice has $3500 worth of SP, while Bob has $3.5 (which is around what new steemit users get now).  Whenever Alice gets $10 curation reward, Bob gets $10/1000000 = $0.00001, or 0.001 cents. In other words, Bob gets no reward at all, the number if negligible.

 I believe this is a problem, because users with non-negligible Steem Power get negligible rewards and cannot accumulate power & money even if they do stellar curation job. So normal users (i.e. those who don't have a large amounts of SP) have no financial incentive to curate content.

Another way to formulate the problem: Suppose there is a hundred Bob1...Bob1000 users each having 1 SP. Their combine influence on content curation will be equal to influence of a single Alice user with 1000 SP.  But their **combined** reward will be a tiny fraction of Alice's reward for curation. Influence is the same, but reward isn't, that's not right. (This happens because a square of a sum of positive numbers is bigger than sum of squares of same numbers.)

In the next section I will demonstrate the effect using the precise computations taken directly from Steem code. In the section after that I will explain why this effect is unnecessary and can be easily fixed.

## Details

Calculations related to vote weight are performed in [vote_evaluator::do_apply](https://github.com/steemit/steem/blob/ae6d87cc00b685aadaa027745d25e4b59af7c190/libraries/chain/steem_evaluator.cpp#L533). Let's consider a concrete example.

Suppose we have three users: Alice with 1000k vesting shares, Bob with 1k vesting shares  and Claire with 1000k vesting shares. Suppose that their current voting power is equal (e.g. they are casting their first vote after a 24h wait) and they all vote for a single post. Claire votes first, then Bob and then Alice.

If voting power is 100%, then for 1k vesting shares we have 50 rshares added to the post.

Thus Claire adds 50000 rshares. Her weight is 50000. Post's total weight and total rshares is also 50000.

Then Bob adds 50 rshares. His weight is `50 * (50/50050)^2 = 0.00005`. (This will actually be rounded down to 0, in code as calculations are done on integers,  but for our purposes we can continue calculations with decimal numbers.) Now total weight is 50000.00005 and total rshares is 50050. (Note that Bob's contribution to post's total rshares is **not** negligible, even though his weight is.)

Then Alice adds 50000 rshares. Her weight is `50000 * (50000/100050)^2 = 12487`, and total weight at that point is around 62487.

Code which calculates payout is in [database::pay_curators](https://github.com/steemit/steem/blob/ae6d87cc00b685aadaa027745d25e4b59af7c190/libraries/chain/database.cpp#L1625). The formula is simple `(max_rewards * weight) / c.total_vote_weight`. Thus is max reward is $1000, then Claire will get $800, Bob will get $0.0000008 and Alice will get $200. Thus Bob's reward is 250,000,000 time's smaller than Alice's, even though Bob voted before Alice. (The exact ratio heavily depends on total weight at time of Bob's vote, the ratio can be between 1/1000 and 1/1,000,000,000.)

Note that Bob's contribution to post's rshares^2  (and thus to post's total reward) is 0.1%, but his reward is only 0.00000008% of post's reward.

If you don't trust my computations you can look up the actual weight displayed on steemd.com block explorer.  E.g. [let's go to some random post](http://steemd.com/introduceyourself/@killerstorm/why-im-really-excited-about-steem) on steemd and open vote details. Killerstorm's weight is 18 while xeldal's weight is 2,189,025,913,558. killerstorm has ~10 SP while xeldal has 104197 SP. So killerstorm will get 121,612,550,753 smaller reward even though his SP is only 10419 times smaller. You can check any other post and find the same situation: users who don't get a lot of SP get negligible weight. The only  way for a small-SP user to get a tiny reward is to be the first to vote.

## Design

Now one might ask: is there a deep reason for this effect? I mean, it wasn't  done just to deprive low-SP user from rewards altogether? (If curation reward was proportional to rshares^2 contribution low-SP users would at least get some dollars or pennies.)

The reason is state in [the documentation](https://steem.io/getinvolved/paid-to-curate/): Reward Vote Concentration. It is done to make sure that splitting one's Steem Power into multiple accounts would be unprofitable. Rewards are structured in such a way that user gets biggest reward if he votes using a single account which has all his SP.

But the formula which is used by Steem now is not the only one possible! It is possible to design a formula which will BOTH incentivize concentration and give people a fair reward roughly proportional to their SP.

Most likely devs tried a naive formula `contribution/total contribution` formula first, and when that didn't work well they just squared the percentage, which did the trick. But squaring is not the only thing you can do to a formula.

I'd say that the actual problem with the naive formula above  is that it has no financial sense. If you square it, it doesn't start to make sense either: it works better in one way (disincentivizes splitting) but worse in other way (disincentivizes voting when you don't have a lot of SP). The cure is actually worse than the disease: the vast majority of users (i.e. all people who got free 10 SP upon registering on steemit) have NO incentive to vote.

A simple way to fix it is to use a formula which actually makes a financial sense. When user votes for a post, an exchange happens: user contributes rshares, and gets weight in return. Later he receives a reward proportional to weight. Thus we can model it as a process of buying weight for rshares.

What is a price of weight then? A fair price at which new voter doesn't dilute existing voters is `total shares/total weight`. Thus the amount of weight one gets is `rshares * (total weight/total rshares)` where `total weight` and `total shares` are computed before the vote is cast. However, in this case early voters get no advantage. We want new voter to buy weight at a price _above_ the current price.

Thus we arrive to a formula `weight = rshares * (1/k) * (total_weight/total rshares)` where k is a price increase factor, it should be >= 1. High k will result in quickly diminishing voting rewards, while low k will result in smoother reward distribution. k = 2 will result in a fast reward decay similar to what Steem has now, but without the disproportionate distortion for low-SP voters.

This formula also discourages users from splitting their SP into multiple accounts: each time somebody votes, weight's price increases, thus casting multiple votes is an inferior strategy.

Let's try it with numbers for k = 2:

1. User#1 casts a vote with 1 rshare, he gets 1 weight in return (this is a special case).
2. User#2 casts a vote with 1 rshare, he gets 1 * (1/2) * 1/1 = 0.5 weight in return
3. User#3 casts a vote with 1 rshare, he gets 1 * (1/2) * (1.5/2) = 0.375 weight

Total weight after 3 votes is 1.875 and payout percentages are 53%, 27% and 20%.

Now suppose user#2 and user#3 are actually the same person. In that case by casting a vote with 2 rshares he could get a weight of 1, and his payout would be 50% rather than 47%. Thus splitting votes isn't profitable.