Steem Basic Income
Steem Basic Income is a social experiment to bring a basic income to as many Steemians as possible. Members join by sponsoring others into the program. Steem Basic Income is delivered through providing regular upvotes to member content.
Automation Progress
Big thanks to @holger80 for the amazing work he has been doing to facilitate our automation project. Click here to support his work with your witness vote. While there is still more work to be done, we are far enough along that it's time to start talking about the program changes that will be part of our automation release.
Some aspects of our program were designed as shortcuts to facilitate manual processing; shortcuts that will no longer be necessary with automation. Other features were experimental while we gained a better understanding of where the balance between ROI and sustainability would end up. Now that we have been in operation for almost 8 months, through some very difficult market conditions, we have a pretty good idea of where that balance should be.
What are rShares?
This section is going to get technical, but here is the high level: When you upvote, your upvote value is recorded to the blockchain as 'rshares' (reward shares) which later convert to SBD, STEEM, and SP (VESTS) at post payout.
Now here's a technical bit:
total_vests = vesting_shares + received_vesting_shares - delegated_vesting_shares
final_vest = total_vests * 1e6
power = (voting_power * weight / 10000) / 50
rshares = power * final_vest / 10000
estimate = rshares / recent_claims * reward_balance * sbd_median_price
Source: https://developers.steem.io/tutorials-recipes/estimate_upvote
For the less technically inclined, the actual SP in your account is measured as vests. Total vests represent native SP, together with net delegation. When you upvote, those vests convert into rshares. The 'estimate' formula establishes the vote 'value' that you see in different tools, and on Steemit. It changes between upvoting and payout because recent claims, reward balance, and sbd median price are all continually changing.
We have been maintaining target levels of 2 SP per SBI share for most of the lifetime of our program. That target is actually described in our first complete overview. That level has proven to be sustainable, (although the ROI represented by that factor has declined because of the loss of SBD remium over the life of our program. With SBD premium almost entirely destroyed, we can expect the current ROI's to hold as long as we hold to those target levels.
This table is based on our current account statistics, using the most recent upvotes from each pool. That means we're not accounting for Voting Power being below 100%, so you will see some variance in the final ratio. We've included the Mvests metrics so mathematically inclined followers can check the ratios and calculations. You could even calculate the Voting Power of each upvote using the other figures if you were so inclined!
| Pool Account | Steempower | Mvests | rshares of 1% upvote | 100% upvote rshares per 2 SP |
|---|---|---|---|---|
| @steembasicincome | 59252.83 | 126.986 | 24007654006 | 81M |
| @sbi2 | 20705.4 | 42.931 | 8389268962 | 81M |
| @sbi3 | 14176.5 | 28.72 | 5743932780 | 81M |
| @sbi4 | 8091.25 | 16.391 | 3278354798 | 81M |
I was going to do all 9 accounts, but I think this adequately illustrates the point. The rshares that are available each full upvote from 2 SP are pretty consistent! Try it out in your own account and see. This means that as if we maintain a 2 SP target per share, we can consistently grant each member 81M rshares per SBI... 10 times per day, 7 days per week... 365 days per year... for as long as the 2 SP target per share remains sustainable!
Member rshares Balances
Instead of pro rata voting weights that wildly swing with each manual rebalance cycle, we will be assigning each member 81M rhshares every 144 minutes. Those rshares will accumulate in an internal 'balance' for that member.
Upvoting Rewards
If a member upvotes @steembasicincome daily, they currently receive an equivalent bonus of 100% on their value. That means each daily upvote is being valued at 810M rshares per SBI share. If a member has high SP but few SBI shares, this provides a disincentive to support with upvotes, which makes it more challenging to achieve our sustainability targets.
Similarly, if a member has low SP but high SBI, their upvoting reward is totally disproportionate to the sustainability boost for which they are being rewarded. This is one of the weaknesses in our current design that was based on over-simplification for manual processing.
Upvoting Rewards with rShares Balances
Under the new system, we will evaluate the rshares that were granted by each member's upvote whenever our posts payout. The actual rShares that the member rewarded to our update will be rewarded back to the members balance, with a 1.05x multiplier to provide additional incentive. This actually makes it more rewarding to support @steembasicincome's sustainability goals than to upvote your own posts!
If the rShares the member rewards through their upvote on our update are less than 810M, they will be granted 810M instead. Effectively, a member with only 1 share still gets a full 100% upvoting bonus, but larger members will need to balance between growing their SBI and growing their own SP if they want their upvoting bonus to still approximate 100%.
This change makes it less attractive to strip your account of SP (and the contribution you can make to the Steem community through normal upvoting) in favor of SBI instead. We do not believe that anybody should have most of their Steem assets tied up in SBI, or any other program, even though we have proven to be dependable and plan to continue that dependability.
Comments and upvote history published by any of our accounts will all pay the 1.05x multiplier on rshares received, but only our regular updates will be subject to the 810M minimum rshares reward.
Delegation Rewards
With upvoting rewards 'decoupled' from share counts, we can offer much more generous rewards for member delegation. Instead of receiving 1 bonus share for each 10 SP delegated to @steembasicincome, members will receive 1 bonus share for every 4 SP delegated to @steembasicincome.
Retroactivity
These changes are not immediate. They will go into effect when we finish our development and transition to full automation. But... we know that there have been many cases where members received different amounts than they should; because of imperfections in manual processes, delays in enrollments, delays in pool rebalancing, lost votes from RPC node failures, etc.
To make up for the many issues that members have encountered with their upvote values, we will calculate starting rshares balances for every member. For each member, we will calculate the total value they would have received under the new system (in rshares) and then subtract the actual value they did receive (also in rshares). If there is a positive value remaining, the member will start with a positive rshares balance when we cutover.
Members with negative balances will not be penalized, but will start with an rshares balance of 0. Some members will have performed better under the old system than they do under the new system, because they have invested more heavily in SBI than in SP for their account. We encourage these members to power up their SP, to make their reward for upvoting our updates return to what they are accustomed to.
rShares delivery
Delivering rShares through upvotes will still be somewhat imprecise. We could see that a member should get a 3.23% upvote and schedule that for delivery, but when it actually votes, their rShares received will be different than intended due to rounding errors. Further, if a member posts back-to-back, they typically would not want the first post to receive $0.10 and the second to receive $0.00 (for example).
Instead of trying to deliver a member's full rshares balance each time they post, we will target an upvote that delivers ~20% of their rshares balance. Then we check to see what rshares they actually got and remove the real value rewarded from their balance. A member posting back-to-back with the same balance as the previous example would receive $0.02 on the first post and $0.016 on the second. There will still be some value swing from irregularities in posting frequency, but they will be much less extreme.
Since all members will receive 81M rshares per SBI every 144 minutes, there will be no need to establish explicit pool assignments. We will dynamically identify the best account to upvote the target rShares value each time a member posts. If a member doesn't post frequently and their rShares balance gets too high, it will automatically toggle comments to receive upvotes in addition (or in stead). Posts will always be favored, and comments will typically be upvoted only when members are not posting frequently enough to receive their SBI value through posts.
Cutover Expectations
We expect there to be members that start with rshares balances (particularly members that have regularly upvoted or delegated but have low share count or have had periods of inactivity). We also expect some members to start with rshares balances of 0. (Congratulations if that's you! It means you've been doing quite well for yourself with your SBI value received).
Since each upvote will payout ~20% of the rshares balance, members that start with balances will initially have higher upvotes than they are accustomed to. Members that start without balances will initially have lower upvotes.
Over time, each member will find their own equilibrium, where the rshares they add to their balance between posts are roughly the same as the rshares they receive.
Members with very regular posting frequency will see their equilibrium establish quickly. Their upvote value per post will be much more consistent than it has ever been, since it won't be as sensitive to swings in our SP levels as delegations come and go.
Members with irregular posting frequency may take much longer to see their equilibrium develop, because upvote values will dynamically and automatically respond to changes in posting frequency.
Share Limits
Together these changes remove the need to limit the share count per pool. Instead, there will be a soft limit at 5% of total shares. No account will be allowed to have standard shares in excess of 5% of the total share count. Delegation shares and management shares will not be subject to these limitations.
TLDR
There will be changes to the program when we automate. There is a lot of math involved, but weekly value per share will be more consistent over time. Per post values will respond dynamically to changes in your posting frequency.
If you have a significant amount of value committed to SBI, you should read this full post, not the TLDR.
Questions?
There's a lot to chew on here. I recommend reading it again if you have a meaningful value committed to SBI. AFTER reading it a few times, please feel free to ask any questions you may have. Please don't ask tons of questions without at least trying to understand it.
If you would like to compare to how things are now, please read our FAQ.
You can still review your share counts using our new SBI Member Lookup Tool. New tools will be released after we complete our automation project.