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.
Let me start with this passage from our last update about emergent complexity:
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.
During periods of rising inactivity, pending upvote balance accrual rates can comfortably be above the equilibrium level that would keep VP from capping out. But if these pending upvote balances linger until accounts return from inactivity, then what happens when they return?
There is a certainty that during some intervals, the upvote delivery will exceed the equilibrium 'deliverable value' and push the VP down. During these periods, should we continue to let members accrue pending balances at the same rate? This would result in a steadily rising 'liability' of pending member balances.
In fact, this is exactly what occurred. When we first built our new reporting layers, the liability was valued above $50k. True, HIVE was higher then, but when your daily deliverable upvote value is under $100, that's a big problem. We were unknowingly running pending upvote balance accruals at an unsustainable rate for a shockingly long period of time.
What can we do about an undeliverable pending upvote liability?
We opted for a three stage course of action.
Item 1 was a fantastic success. It immediately cut about 40% off of our pending balance liability.
It was a mistake to release 2 and 3 at the same time. We should have released 3 first, waited for an initial equilibrium to emerge, and then release 2 after.
Given the way the high liability emerged, what happened next should have been expected, but we did not properly communicate our expectations and prepare members for the impact.
Since VP management was released at high VP levels, the pending balance accrual rates initially rose instead of falling. Then as lovegun usage send pending balances from semi-active accounts to active accounts, the VP plummeted. As soon as VP dropped below 50%, the pending upvote balance accrual rates began to fall again.
By the time VP stabilized in the mid-teens, pending balance accrual rates had dropped below 20% of the level they were initially set to when we launched Hive SBI on Hive years ago. They fell in half again by the time VP came back above 50% and allowed them to start climbing. It took most of Q3 to reach this result.
As soon as VP climbed above 60%, certain Hive SBI whales began using the lovegun again, to blast out giant chunks of pending balance into the rest of the community. That's great for the recipients (most of whom did not even know they were recipients) but it wasn't great for our VP levels, and we were soon below 20% again.
It was at this point that we learned about the upcoming HF's changes to mana consumption. In light of mana consumption changes, and our sordid history of VP management under the new system, it was clear we needed something better. We were already seeing many long-term active supporters choose to opt out because of the drastic decline in upvote values they were seeing.
We updated our VP Management system at the time of HF 28. We recommend reading that entire section if you want a detailed understanding of how it works.
Even with clear detail on how it would work, we failed to address the implications. Whenever voting accounts are below 90% they are in a 'paused' status. If you post when no accounts are available, your posts will queue and then queued posts will pick off voting accounts as they become available.
If your scheduled vote is greater than the value deliverable by the voter that pops up as available, you get its max vote, and that's it. Luck of the draw, in effect, as to how much upvote you get if you have an above average pending balance. Not ideal.
This state will continue until the daily pending upvote balance accrual drops low enough that voting accounts are able to deliver most of the outstanding pending balance. Realistically, we only need to worry about the outstanding balances for 'Daily Active' members, and some percent of 'Monthly Active' and 'Yearly Active' users.
Distribution matters, of course, but at a high level, here is what we're currently looking at:
This chart is available in our new reporting dashboards, and any members that are interested can monitor our VP and pending balance progress.
The current pending upvote balance accrual rates are roughly 15% of the historical levels that led to this liability buildup. It took 7.5 years to build a liability that would take 500 days to repay, so we can infer that our accrual rates over that time period were about 20% too high. Now they are 80% too low.
In effect 20% of VP is being spent on normal upvote operations, and 80% is being spent on bringing down the pending upvote balance liability. If that's the case, then it would take 69 days to deliver the pending upvote balance shown, just for the Daily Active accounts!
In actuality, the bulk of it (78.7%) is held by the top 10 daily active accounts. Once most accounts below this line are below 'maximum deliverable upvote' VP should start to recharge and get us back toward the top end of the range where pending balance accruals will begin their slow march back to historical levels. That could happen in as little as 2-3 weeks.
Much of the liability shown here will be converted into HSBIDAO tokens when we release pending upvote balance conversions. We were planning to wait until we touch the top of the target VP range before release. We will not wait it out if we expect at least 2-3 weeks more at the bottom of our target VP range.
Incidentally, the situation is even more drastic on the sister chain, where over-accrual to keep VP below 90% has reached extreme levels. While we continue to support cross-chain conversion of member voting units, we will no longer support cross-chain transfer of pending upvote balances.
You can request a cross-chain transfer by sending 0.003 STEEM to 
Transfer Refund Request in your transaction memo. These are processed manually at significant delay, since all incoming units on Hive need to be properly funded. Any pending upvote balance on Steem will be zeroed at the time that your voting units are converted across.
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.
