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.
Congratulations @steembasicincome! You received a personal badge!
Wait until the end of Power Up Day to find out the size of your Power-Bee.
May the Hive Power be with you!
You can view your badges on your board and compare yourself to others in the Ranking
Check out our last posts:
Congratulations @steembasicincome! You received a personal badge!
Participate in the next Power Up Day and try to power-up more HIVE to get a bigger Power-Bee.
May the Hive Power be with you!
You can view your badges on your board and compare yourself to others in the Ranking
Check out our last posts:
I read this...And then re-read it.
I'm still more confused than ever lol
But alas, it's been over half a decade with you guys, and you haven't failed. So Im here, still 'Hiving'.
Thanks for the confidence. I'm sorry it's still confusing.
We spelled out how it would work, but we didn't detail the implications, and that's where it's getting hung up. Basically, 'smaller votes than normal' should be temporary.
Right now the accounts are in the recharge below 90% ... so they tick along, gradually increasing in VP. Meanwhile, people post, and a queue of posts awaiting votes accumulates. When an account gets above 90, it takes on a few posts from the queue, until the votes delivered are equivalent to a full vote from that account, and then it goes back into recharge.
For posts that are in queue, it's luck of the draw which account will pop above 90% to deliverable the vote (and thus, what the maximum vote size is).
Meanwhile, pending balance accruals are curtailed until all of the accounts get out of this recharge pause, so it's not a permanents state of affairs. It seems complicated from the outside, but the rules are simple and this will help us to more accurately estimate where the sustainable level of pending vote balance accruals should be.
Eventually we will reach a semi-stable equilibrium where accounts are mostly between 90 and 98, always available to immediately vote when posts are made (for members with pending balance above the minimum at least) and max deliverable vote will be more consistently higher than it was before.
But this is not our first attempt to solve for a sustainable equilibrium that cuts down on the gradual buildup of pending vote balances, even for active accounts. We can't promise there won't be further changes down the line if it doesn't work out this time.
Hello there. I did not receive my all my hsbi upvotes on my last post. Wassup? Thanks.
There is an upvote on your latest post from our @sbi9 voting account. The explanations for why it was only one vote and not all the voters are in this post on which you commented.
Here is a summary of how the new system impacted your particular votes:
When our voting accounts are below 90% they go into a paused state. Posts queue up, and pick off the voting accounts as they recharge back above 90%. Only one voting account was eligible when your post reached the front of the queue, and you got a maximum upvote from that voter. In these circumstances it's very close to random which account will deliver your vote (and thus how large its 100% upvote will be).
There are excessive pending upvote balances from our previous VP management regime, and voting accounts have been living on the bottom end of the new VP range for longer than we expected.
We will eventually enter a new equilibrium where pending balance accruals much more accurately align with upvote delivery. Once we do, our voting accounts will spend most of their time within the target VP instead of at the bottom. Most members will then receive their full expected upvotes each post instead of leaving so much in their pending upvote balance.
In the meantime, any value not actually delivered yet remains in your pending upvote balance until it can be delivered.
There are 3 options available to you:
If you grow impatient with choice 1 (and we have no idea how long it will take to stabilize the balance between value delivery and pending balance accruals) and opt for choice 2 or choice 3 at any point:
You convert your voting units into HSBIDAO tokens by sending 0.001 HBD per voting unit (with a minimum transaction value of 0.005 HBD) to @steembasicincome with
sbi-tokensin the transaction memo. Your voting units would be surrendered and you would receive HSBIDAO tokens instead.Surrendering your voting units does not immediately impact your pending upvote balance, and you would continue receiving upvotes until it fully decreases to below the level required to support our minimum upvote value of $0.021, or until we release Pending Upvote Balance Conversion. At that time, any remaining pending upvote balances for members with 0 voting units will be converted into HSBIDAO tokens.
Thank for your explanation. I read the post and understood that there would be delay. Unfortunately, I have only a foggy notion of what all this means even after reading your careful and thorough comment.
Is there a possibilty of the random sbi account being able to deliver more than your expected upvote? Or do you have any plans to consolidate all the accounts so that their are fewer insufficient accounts?
We just published a new post that provides some of the foundation required to understand the implications of our recent VP Management design changes. It hopefully answers your first question (your account can have up to 1/3 of its pending balance delivered on any post).
To answer your second question, there is no need to consolidate the voting accounts. While it would help with the randomness, that's a temporary problem. Consolidation would result in more permanent problems down the road, if HIVE prices ever recover.
We will go deeper into the implications of VP management in our next updates, and share our attempt to guess when things will normalize.
Ok I'll hang in there to see what happens. It sure was a disappointment to see my post earn so little though, I gotta say. At my level of rewards per post, that was a heavy hit, like a hefty 100% downvote from someone actually.
The difference between a smaller upvote and a 100% downvote is pretty profound.
In the case of a smaller Hive SBI upvote, the 'missing' amount remains in your pending balance, and you will receive it on future posts. In the case of a 100% downvote, the lost value is gone forever.
You might notice the Hive SBI accounts are subject to the same voting rules, and the 'self-vote' on the latest update came in at $0.15 instead of a more typical $4. We see you, we feel you, and we're working on it.