Hive Stake Based Income (Hive SBI) is an account-based curation program. You sponsor accounts for regular ongoing curation, and then you receive back curation rewards as upvotes on your own content. This empowers both accounts to earn a sustainable crowdfunded basic income.
The overall design of Hive SBI is pretty simple. Based on total HP, the accounts can support a certain amount of upvote value per day. While the HP available to upvote gradually increases over time, the real value available to distribute via upvotes is directly correlated to HIVE price. For the sake of argument, let's call it $40 per day, which is approximately correct at the time of publication.
This $40 per day needs to be fairly distributed across all Hive SBI members, so it gets allotted pro rata based on voting unit levels. At present, there are roughly 1 million voting units.
Simplified, that's $40 / 1000000 = 0.00004 per day in pending upvote balance accrual.
All done! Pretty simple, right?
Those 1M units are distributed across ~17k member accounts, with 4406 accounts having provided all of the HIVE enrollment value subsequently powered up into HP. That's a lot of accounts, and many of them would only get that 0.00004 per day. The Hive rewards mechanism cuts off all payouts below $0.02. To prevent spamming out dust votes, we designed the program so that members accrue a pending upvote balance, which accumulates until members have enough for an $0.021 vote. This cuts down upvote frequency dramatically, but it adds to the complexity of the program.
Accruing a pending balance also means that all members get the same value per unit per time interval, regardless of posting frequency! That means that instead of having to post every day, members can take their time to create something of quality, and still get their full benefit. Hive SBI encourages members to slow down and do their best work, so that it will attract other voters as well, instead of a misplaced incentive to post every day, regardless of quality.
In the case of delay between delivering a vote and removing its actual value from a member's pending balance, it was possible for a member to post again and overdraw their pending balance. We introduced a delivery ratio to eliminate these edge cases. Only 1/3 of member pending balance can be delivered by a single vote. It was originally at 1/5, but we found 1/3 to be more than adequate to manage the risk and results in tighter delay between voting unit increases and vote values received.
Voila! Emergent complexity! It's now too complicated for most people to follow. Thus the simplified rubric: voting units means upvotes. Or in the eyes of our detractors, payment means upvotes. We believe this is a vast oversimplification that ignores the actual design of our program, but we do understand the perspective.
Only 35% of accounts receiving upvotes from Hive SBI have ever paid anything. Of course the unit distribution is much more concentrated among paid members. After all, for every 2 units created at least 1 is a paid member (and if the second goes to somebody who has ever sent even 1 HIVE to 'try things out' then both are marked as belonging to a paid member. Most paid members actually have a mix of 'sponsored' units and 'enrolled' units.
We're pretty impressed that the average units held by free members is almost 14. Our paid members are doing a great job of distributing out value to others!
From there, another problem emerges. If we just distribute every unit a vote value of 0.00004 every day, it's completely fair, but it underutilizes the voting power of the accounts. Most of the time, our voting accounts would sit at 100% and waste their curation power, because of delays in member posting frequency and the growing level of inactive accounts. To manage this problem, we increase the pending balance accrual rate. In essence, all active members receive slightly higher upvote values due to the existence of inactive accounts.
This gives rise to a whole host of other issues, since the return of inactive or semi-active members cannot be predicted or accurately modeled, only managed around. We will write more about this issue in a subsequent post, as it deserves a more detailed treatment.
Our terms include several specific abuse categories, along with a more generic "anything that we think is abusive". To facilitate this, we skip all posts from various tags, communities, and dapps, along with maintaining a 'skiplist' designation in our database that turns off all votes for accounts that earn the designation.
If you see a pattern of Hive SBI votes on abusive content or accounts, please let us know in our Discord. We have a channel for that! In the future, this will be managed using votes from HSBIDAO tokenholders.
This post provides an overview of the initial complexity of Hive SBI's design mechanics. We try for the simplest possible design to manage all of the intended results, and then iterate as we go. Because human behavior is complex, managing around the various cases while treating all members as fairly as possible results in emergent complexity.
These challenges evolve over time, and our current development roadmap is oriented around better solutions, more member flexibility and control, and better positioning for a sustainable future.
To curate accounts using Hive SBI, enrollment is pretty straightforward:
Just send 1 HIVE to 
This is an open-access program. You do not already have to be a Hive SBI member to enroll. You just have to sponsor another Hive account.
The official currency for enrollment is HIVE. HBD transactions are only accepted for auto-transfer functions, not for member enrollment. Enrollments are processed automatically every 144 minutes.
To tokenize your Hive SBI voting units, send 0.001 HBD per voting unit to sbi-tokens in the transaction memo. There is a minimum transaction size of 0.005 HBD, and anything smaller will be ignored. This will transfer your voting units to 
If you have questions, please ask in the comments section or join us in our discord channel.
You can check your member level at https://www.hivesbi.com/ or view our new reporting dashboards. The new dashboards also include your HSBIDAO token holdings.
