Steem Basic Income, rShares, and Automation

in #busy3 years ago

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


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 AccountSteempowerMvestsrshares of 1% upvote100% upvote rshares per 2 SP

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.


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.


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.


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.


that's a nice post to understand the upcoming changes and it sounds good... I really like this project 😊 @peekbit

Sounds good. I think I will lose a little on the bonus side but thats understandable. I dont strip my account of sp but i hold a lot of sbi shares and have a slower sp build.
Still it makes things fairer then I can't complain. Will delegated sp be subject to the bonus reward?

The upvoting bonus will be separate from delegated SP, but the reward on delegated SP will be higher than it was before (even with upvoting bonuses).

@steembasicincome, so basically is it more important to own shares, or to upvote, or is it beneficial to do both? I currently own 375 shares, I was planning on expanding that to around 500. But would that make sense, or would it make more sense to keep upvoting with the STEEMPOWER I have now instead of powering down a bit to invest in more shares?

We do not recommend powering down to invest in shares, especially before you see how your upvotes reward is impacted post-automation.

In our lookup sheet, you can calculate your % bonus by comparing your adjusted shares to your actual shares. If your adjusted are 492 and your actual are 377, then (492 / 377) = 1.305 - 1 = 30.5% upvote bonus. That's a good start!

377 / 492 = 76.6% of your rshares received are from your actual shares, and 24.4% are from your upvote rewards. You can check our upvotes on your most recent post and look up the rshares using steemd. Then compare that 24.4% to your upvote rshares value on our most recent update.

If your upvote rshares value is higher, then your upvote reward will increase after automation. If your upvote rshares value is lower, then your upvote reward will decrease after automation. If your reward will decrease, then you should focus on building your SP before building your SBI more.

Okay thanks @steembasicincome :) However I currently have around 2000 SP and 375 shares so I don't know if that is a good balance, can you give me a recommended balance like for instance,

1 sbi share for every 10 SP or I don't know something like that.

I'm glad that you're solving any sort of sustainability issues.

I guess the question becomes, in the long run, is buying a share for your friend worth more than upvoting your friend and yourself with that same amount of steem 5 times each per day?

Also, does the math make delegating worth the same as keeping that SP and upvoting SBI posts with that amount of SP (rShares, whatever) 10x/day?

Normal behavior and community-building behavior will never be as profitable as pure rent-seeking behavior, which is one of the limitations to Steem (that we see every day with typical whale behavior).

We can't fully solve that, but we can build incentives to make community-building behavior profitable enough to tip the scales for people that want to focus on the long-term but still need to make some immediate return.

It's a bit of a prisoner's dilemma. Without those of us community-building, the landlords would see their principle value crash. But I am wondering about the particulars of the math.

I thought of another question. Can people without shares upvote for the 1.05% return upvote? Also, is it 1.05% before or after curation?

Posted using Partiko Android

The rshares are before curation. We figure that curation will be a wash, since curation is also taken out of our upvotes on you. (Actually, we think we can time our upvotes and come out ahead on curation, but we shall see!)

Steemians will have to be enrolled to receive the return upvote. But since enrollments will be automated, somebody could upvote and then enroll before payout and get the reward for upvoting.

Got it. So a self-upvote on myself would be 1
an upvote on an otherwise unvoted piece on you at 30 minutes would be
and your upvote on me, assuming no other votes and that you did it at 30 minutes would be
which is ultimately
1 vs. .25+.7875 (1.0375)

An excellent deal!

Phew! Thanks for that! Sets it out nicely :)

I read this a few times and still don't understand it. lol but I want to invest more shares anyway.

Everyone should complete sufficient diligence as makes them comfortable. It's okay to rely on others that you have decided you can trust with the diligence.

Thanks for the post outlining all the coming changes. IMO these changes are very much needed to provide some balance to the entire system and provide the ability to reach a sustainable level of owned SP. This ultimately must be the goal.

Think that the rshares system will work out great! Love the weighted upvote benefit system and that upvotes on comments will be rewarded.

Good changes and think you are making a good program even better!

Thank you for your support!

I like a lot of these changes. The delegation for sure is a good move. Thank you guys.

We think so too. The development is taking a while, but it will be worth it once it's done!

Is there a limit on the backlog of upvote-amount on inactive users?

It probably would not be that good if suddenly a few 2-year inactive stat posting again and they are due the voting of a whole week of all accounts ;)

I have the same question. I've sent you (lennstar) an SBI share for raising the issue. I'd like to know if there's a cap on how much can be accumulated.

This is a good question. Originally we were dropping members that were inactive past 180 days. I do have the data in place in our back-end system to monitor for accounts that have been inactive for extended periods. Most likely we will 'tax' inactive users balances each month, so they would reach some equilibrium of their own where the new value received is just enough to cover the tax and their balances don't really grow past that point.

Was going to ask, if there is an maximum for the internal rshares balance.
But that sounds quite fair.
So it will be a "tax" (fee, whatever) above a specific threshold of rshares as a saturation function against 100%. It will function basically as a limit.

Will be interesting to hear at which amount the tax will start, how fast the tax will rise to 100% and what the limit ist. 👍

Once I define this we will make an announcement. It's not a critical function, so it will be in future development, not part of core automation. Most likely it would be 'when months inactive = n, where n is any whole number, then rshares_taxed = rshares * (n / 100)'

So basically at one month inactive, 1% of rshares are lost. At two months, 2% are lost, etc. until 100 months when rshares after the tax would be 0 and the member would be deleted. Eight years seems really like though. I will have to think about this more.

Here's a question that might be relevant someday. Will SBI be inheritable?

Posted using Partiko Android

Overall it sounds like the changes are going to be good. Even if it's slightly disadvantageous to some, it will make the program more sustainable and fair in the long-term.

If SBI is voting for comments, will that be a large enough vote that it would surpass the dust threshold?

I don't have an answer to your specific question, but I recommend everyone start a @dustsweeper account - I have found mine to be very helpful!

I have one, so I would be ok. I was just curious as some people still don't use dustsweeper. I think they were talking about removing the dust threshold in the next update. Not sure if that's actually going to happen though.

That would be nice!

I read their post that came out today and it looks like they might be doing something where the VP doesn't get subtracted or something. I didn't really understand. Regardless, the dust threshold seems to be staying. Sorry.

Basically there are two different dust threshold. One is a minimum payout that an account had to exceed or it would receive 0 instead. The second was a smaller threshold that formerly stopped accounts from upvoting at all because it was too small.

The first case is where @dustsweeper comes in and resolves things, and that's not changing. The second is being converted from a minimum below which you get errors to a 'vote tax'. Instead of receiving an error and not being able to vote, your vote is just 'taxed' by that amount instead. ALL votes will be taxed by the vote tax.

Think of it as a super-regressive tax on the SP-poor. They can upvote as much as they want, but instead of figuratively having no value, it will actually have no value.

Since this is only for when you don't post for a long time, even with one share and low steeem price this should be the case.

Thanks! I post enough that I shouldn't have to worry about it, but I was just curious of the logistics. I like knowing how things work and didn't want SBI to be wasting VP on votes that don't count for anything.

Thanks for your concern. We don't want to waste VP either!

Dust threshold is problematic, because it's based on SBD payout which is constantly changing. We recommend using @dustsweeper, but we are also looking to make sure that we don't leave dust upvotes.

Yes, I use dustsweeper! It's a great tool for getting over that pesky little barrier. I post often enough that I shouldn't have an issue, but didn't want to see your VP going to waste. Might as well use that to self-vote and then grow the account so it can be used to give bigger votes.

At this point, the newly announced 'vote tax' is going to be more of a problem. Our solution to the vote tax should resolve most dust issues, too.

I hadn't heard about the vote tax.

I explained what I meant by that in another comment that I think was also directed to you.

How much SP will we need to have then to get the 100% bonus if we are upvoting your every post?

Since your weekly value is based on the voting power of 2 SP per share, then if you target 2 SP per share, and upvote our updates with a frequency in line with your own posting frequency, then it would be pretty close in most cases.

A little late with my upvote this week (tiny as it may be), but always glad to read these updates.

My favorite thing about @steembasicincome is basically that the underlying philosophy is one of "community building" which offers a nice contrast to the "cash extraction" and "money oriented" strategies so many people seem to be applying here.

Bright Blessings to you!

Steemauto and Steemvoter have both been very spotty in the last couple of weeks (we use those services for upvote delivery.)

We will be moving to our own voting engine soon, which should resolve most of those issues.

Why did not I get a vote from sbi today?

We use third-party services for upvote delivery (steemauto and steemvoter) while we are developing our own voting bot. Sometimes they miss posts because of node connectivity issues. Since they have very limited logging, we are not able to validate the reason any particular vote was missed.

We will be calculating the value every member should have received when we move onto our new system and will catch up any missing value from missed votes at that time.

I see. Thank you.

Posted using Partiko iOS

lost me there Joe does this mean we have to post every 144 minutes to get maximum steem basic income now?
Also with how many shares I have what does my vote need to be to take advantage of the full bonus potential?

From what i can see. They give you a balance ever 144min. This adds up into your own 'pot' or 'pool'.
When you post the whole system will calculate 25% of that pool and upvote you that amount. It will thwm start to rebuild.
If you upvote when it goes auto they will give you 110% of that upvote value in that pool to build it quicker.

Hope this helps

Cool its a very fair system that in time pays

I'll be reading this a couple times. 🤣

Hi @josephsavage, I read it again as recommended but I still feel like asking you..Would you please make a "rshares for dummies" example with a comparison before/after automation for an average SBI holder? I don't fully understand how the SP will be recognised through rshares to my account... plus since my ongoing contest is keeping accumulating and distributing SBI, I'm concerned about the participants and their perception of the bonus linked to such contest reward. Also, I constantly invested in the project through my f3nix redfish account so far (my account has a ratio of 357 SP vs. 145 shares avg..), now I wonder if it is betterwiser for me to invest more into SP from now onward.. sorry for being a but, you've a biblical patience. Thanks :-)

The before and after will be different for every account. After the changeover, I would be happy to review your accounts and strategize with you how best to utilize @steembasicincome to support your programs.

Right now, I'm trying to keep up on all the manual processes while performing testing and validation to finish the automated system.

Thank you again. In a way or another, I do need to digest it (notwithstanding my not so hidden hate for math). I want to be able to hypothetically explain it to a contest participant and to plan for the better since I intend to keep fully supporting the program. Also I want to do it for the contest platform the @bananafish, who's now rewarding the shares. To be continued after the changeover :-)

To listen to the audio version of this article click on the play image.

Brought to you by @tts. If you find it useful please consider upvoting this reply.