What is Hive SBI?
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.
HF 28
HF28 was a big success! Congratulations to all Hive developers, as well as to the teams supporting various tools. In particular, we heavily use Nectar (and now Nectar Engine) and they were extremely supportive in ensuring their tools would be ready for a clean hard fork. Thanks @thecrazygm !!!
VP Management
The changes to how VP functions on chain are interesting. Instead of your votes scaling by VP as you drawdown your voting power, you continue to vote at full strength, until your VP fails you completely. For many users, that means never. For us, it means we had to recalibrate the way we calculated votes and make sure we're still delivering the right amounts.
In the process, we evaluated our overall VP management over the last six months since we introduced dynamic accrual rates, and... we were not happy. Our VP ranged from mid-90's when we first released dynamic accrual, down into the teens, back up into the sixties, then down to the low 20s... in short, it was a mess. Our initial analysis of the VP changes indicated that the new system would make this crazy bobbing motion even worse.
So what did we come up with? Something even more dynamic, but in a way that should make it much more stable. Smaller changes to accrual rates and much more consistent upvote values again.
The Range: 90% - 98%
We are setting a VP floor for each of our voting accounts at 90%.
We are setting a soft ceiling at 98.1%
Within this range, voting account VP will bob up and down and we will have 'normal' operations with our standard 2.4 hour enrollment cycles and pending vote balance accrual rounds.
On the high end:
If any of our voting accounts pops above the soft ceiling, it will trigger an early cycle. We will process transfers and all members will accrue their pending balances. At any given time, we see several hundred member posts in queue, awaiting votes but with insufficient pending balances to support our minimum vote. Running an accrual round will immediately trigger a series of votes on these posts.
Running an 'early' cycle indicates our accrual rate was a little low for 2.4 hours, so we also tick it higher, reducing the likelihood that the next cycle will also run early.
Finally, since 98.1% is cutting it a bit close to 100% and technology is not perfect, we have a 'backup' voter running on a separate server. It will kick in at 99% and vote burn posts to preserve curation income and prevent VP waste.
On the low end:
If a voting account drops below 90%, it will be 'paused' until it recovers. Since our normal voting operations always pick the highest VP account to deliver a vote, the others will all be close to the floor, and we will be in 2.4 hour cycles. If any account is paused when the cycle runs, it indicates that our pending votes accrual rate is too high, and it will tick down. Eventually, ticking down the accrual rate will get us back into a stable equilibrium where we live within the target range for an extended period.
Why so complicated?
Most of the complexity in Hive SBI emerges from trying to treat every member unit fairly. You do NOT have to post daily, and failure to do so does not result in any loss of pending vote value. Since human behavior is far from consistent, this simple rule results in emergent complexity. As the program grows, normal power laws have made managing the complexity increasingly complicated. We're talking an 8 point relevant range. With all votes delivered as though VP were full, that's only 4 max upvotes. That means our voting behavior can be completely dominated by a small handful of users changing their post frequency.
The total pending vote balance that has accumulated on accounts currently posting daily is $2256 but our maximum deliverable vote value is only $50 per day at current HIVE prices (and if HIVE goes up, the pending balances go up, since they are stored in rshares). And then there are Monthly Actives, who post sometimes but not often, and Yearly means they are probably still around, just haven't posted or commented within the last month...
The fully inactive are only such a small slice because we had paused accrual at one year of accrual and one year of inactivity.
Pending Balance Conversions
But we have a solution! We are working on setting a maximum pending balance for all users. The cap will be at 10 max votes for every user with more than 10 voting units, and 1 max vote per unit for every user with fewer than 10 voting units. In practice, that's a cap that will impact only our power users, and on the low end it's actually incredibly high; years of accrual in fact, and it replaces the old cap of one year of accrual for inactive accounts.
We set it at a level that still enables power users to voluntarily blast out chunks of their pending vote balance directly to other users without immediately putting them over limit.
And what happens to pending balances above the cap? They will be automatically converted into the new HSBIDAO token. This is in final testing and should be released within the next week. We estimate about 40% of the total outstanding pending vote balances will convert into the new HSBIDAO token at that time.
HSBI token failure
Which brings us to the HSBI failure and reissue as HSBIDAO. We were releasing the pending balance conversion, and failed to properly test the results (@josephsavage takes full responsibility for this). As a result, we issued ~150k HSBI tokens on the first pending balance conversion round. The largest issue was for ~82k units, but they were supposed to get only 116. That's a pretty absurd mistake.
We immediately halted the buywall support on the old token and began an analysis of what when wrong. As soon as we knew for certain that it was caused by the new features, we rolled them back and began to analyze the token issuance logging and snapshots to determine who should have how much. We found that some of the reporting we needed was inadequate, and we prioritized making sure all reporting layers we need are in place before we reissued the new token.
Since then snapshots we had were inadequate, we evaluated trading activity around the final token blast to identify which accounts had sold their excess gains and who bought them. The reissue granted new tokens to the buyers instead of the sellers. During this time, a few accounts transferred their tokens to alts before selling. We missed a few of these, and ~400 HSBIDAO tokens we issued incorrectly. That's a pretty small dilution effect, considering the entire scale of the project at this point. If we hired advisors or consultants to oversee everything, it would have cost a lot more!
It is safe to trade HSBIDAO, and we are maintaining a buywall target of 5000 tokens. If you need more, please let us know.
We have also drawn out a step-by-step safety checklist for pending balance conversion release, with checkpoints to make sure this does not happen again.
Quick note on auto-transfer function minimums
The minimum values for our automated features are 0.005. If you use lovegun, that's an 0.005 HIVE transfer to shift $5 of pending upvote value to your target. They must already be enrolled in Hive SBI. If you want to move voting units, that's an 0.005 HBD transaction to shift 5 units (for less than 5 voting units, you still need to send 0.005 HBD). The recipient needs to already be enrolled in Hive SBI.
Hive SBI Enrollment
To curate accounts using Hive SBI, enrollment is pretty straightforward:
Just send 1 HIVE to @steembasicincome. Include the name of a Hiver to sponsor in the transaction memo (preceded by @). You and the person you sponsor will each receive 1 voting unit in the program for each 1 HIVE. You can sponsor any active Hiver (except for yourself); it does not have to be a current member.
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 @steembasicincome, with !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 @sbi-tokens and it will issue HSBIDAO tokens to you in return. If you send more HBD than is needed, the excess will be refunded to you by @sbi-tokens.
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.
These metrics only show your internal Hive SBI voting units. They do not include any HSBIDAO curation tokens that you may hold on Hive Engine.