This is the second post in a series about the Steem reward system. Please read my disclaimer.
Previous posts: 1
Each upvote is assigned a number of R-shares by the system based on the account's Steem Power and remaning voting power. Exactly how the R-shares are computed will be discussed in a future post in this series. The purpose of this post is to describe how V-shares are obtained from R-shares. Later in this post, we will discuss a different curve.
The "how" is quite simple; V-shares are equal to R-shares squared. So if Bob's post has twice as many R-shares as Alice's post, Bob gets 4x Alice's V-shares reward; if Bob's post has ten times as many R-shares as Alice's post, Bob's post gets one hundred times Alice's V-shares reward.
O(R^2) behavior biases the system toward "winner-take-all", concentrating the payouts in the form of fewer, larger rewards for the big winners. This is a deliberate design decision to aid in attracting and retaining users: Humans are notoriously bad at thinking about probabilities, and users will instead judge the system based on the sizes of the largest rewards. The
O(R^2) part of the system is designed to attract risk-seeking users  .
 Users with a small balance ("minnows") can be considered to be risk-seeking. "You can earn approximately X% per year on your $5 worth of STEEM" is much less attractive than "if your post gets a ton of upvotes, you might be looking at a $100-$10,000 payday," even if the EV of both propositions are the same. The minnow user class is very important, as the vast majority of users in a virally growing Steem network will be minnows.
 A profile of the user ecosystem and a discussion of risk-averse users will occur in a later post in this series.
What is the V-shares curve?
We can define V-shares to be a function of R-shares, call it v-bar; the current implementation of v-bar is simply:
This function has several desirable properties:
- (P1) v-bar is
O(R^2)in the long run (to strike just the right amount of balance between "winner-take-all" and "everybody has a chance")
- (P2) v-bar goes through the origin (no R-shares gives you no rewards)
- (P3) v-bar is an increasing function (more R-shares gives you more rewards)
- (P4) v-bar has an increasing slope (more R-shares gives you more rewards faster)
- (P5) v-bar is a low-degree polynomial function (for efficiency of implementation)
- (P6) v-bar has a leading term with a coefficient of 1
Unfortunately, it has one undesirable property: The function is flat (in calculus terms, it has a zero derivative) at
R = 0. Our undesirable property can be stated as:
- (P7) v-bar has zero slope at the origin (the first R-shares get almost no V-shares)
That is, our list of desirable properties should expand to include:
- (P7') v-bar has positive slope at the origin (there is a minimum exchange rate of R-shares to V-shares)
Redefining the V-shares curve
Fortunately, it is fairly simple to redefine v-bar by keeping the same curve, but shifting the point we consider the origin up and to the right until we get to a place with a positive slope. We can write a new definition of v-bar based on shifting
s units (this reduces to the old definition when
s = 0):
This v-bar retains desirable properties P1-P6, but adds the additional desirable property P7' when
s > 0. Of course V-shares are no longer equal to R-shares squared if we have
s > 0, which explains why I'm calling them V-shares in this series of posts, instead of
rshares2 name implies the
s = 0 curve, which will no longer be used if my hardfork is adopted.
The TLDR version of this post:
- V-shares are equal to R-shares squared (a parabolic curve starting at the vertex where the curve is flat)
- The curve's increasing slope means more V-shares per R-share for posts with more total R-shares
- I propose a hardfork modification to the parabolic curve: Start to the right, so you still get increasing slope effect, but avoid the flat part
This post's main purpose has been to describe the current behavior and the proposed hardfork modification. There is a much more powerful theoretical justification for the proposed hardfork modification, but that justification will wait until a later post.