Keep in mind that we use your 28 day upvote history, refresh it every day, and you only need 28. So upvoting beyond a certain level won't help you immediately, and could set you up for a sudden drop in 28 days when the spree drops off your record.
No problem, steembasicincome is already set up on https://www.steemdunk.xyz, so posts should be autoupvoted with 100%. Keeping the voting history close to the 28. 👍
So with that running in the "background" and with upvoting comments here and then (I'm pretty sure I will still reply to content.) everything should be fine now.
Also, I'm only upvoting with 14 SP (red fish here), basically I'm getting way more back then I'm generating with those votes. Even with 28+ votes.
A totally another thing, because I'm curious: From a theoretical point of view, the calculation from the bonus shares seems only be based on the number of votes and the upvote weight. One account with, let's say 100 shares, would make a 3,8 Steem per week from steembasicincome over the course of 180 days. (Based on the ROI of 180 days with 100 Steem inital investment) To double his number of shares he would need to upvote 28 times with 100%. His return for those votes would be 3,8 Steem per week over four weeks. So in total roughly 15,555 Steem. He is getting basically 0,555 Steem per vote in return.
Smartsteem is paying 85% of a vote's value. So 5000 SP would generate (with data from now on https://www.steemnow.com/) a 0.67$ worth of upvote and Smartsteem should pay roughly 0,569 Steem per vote.
So the account would generate more income with selling those votes than with upvoting steembasicincome to get bonus shares. (unless he gets more steembasicincome shares, then it would need a higher amount of SP and so on) Ofc he could still upvote steembasicincome because he likes the content or he is generous, but the financial advantage is capped for a whale.
Don't get me wrong, I really like the bonus shares (Obviously 😁). And they are really good for red fish and minnows to get things going for them.
But I would like to understand the design choice behind that system, what was the intention?
It was a design choice based on the limitation of manual processes for calculation of the upvote weights each member receives. We are moving into a fully automated system soon, and it will have a better system for rewarding upvotes that will provide more incentive for members to upvote our material.
From what I have read, the added income from the upvotes also is used to increase the value of future votes, correct? So the added votes may not have an immediate impact, but long term it adds to the trailing income stream.
We use the enrollment fees to lease delegation and maintain target voting power levels so that the return is relatively consistent over time. The added income from upvotes and curation reward decreases our dependence on leased delegation and unlocks the possibility of our SP rising above those target levels. At that point, the basic income we deliver could grow exponentially.
That sounds awesome. 😁 Can't wait for sbi to be that far.
But that keeps me thinking: That only happens when every pool has enough SP, right? I mean the moment steembasicincome gets enough SP together, isn't that pool delegating to sbi2, sbi3, etc.? So that their dependency on delegated leased SP is reduced. Will the amount of SP between each pool equal then? (After the automation of course, could be too much work to maintain equally SP levels between ten pools)
What happens with the price of a share then? Will it be still 1 Steem?
Quite curious about that future planning there. 😅
Price will always be 1 STEEM. There are some future features that we have in mind but are not ready to announce yet. Each pool is managed to a multiple (not even SP between pools, because they have very different share counts, but there is also a slight difference in the target multiples.
When the first pool gets enough SP to decouple from needing leased delegation, part of the SP spills over into the next pool to help it toward decoupling, and so on as each pool decouples it will boost the next.
Keep in mind that we use your 28 day upvote history, refresh it every day, and you only need 28. So upvoting beyond a certain level won't help you immediately, and could set you up for a sudden drop in 28 days when the spree drops off your record.
No problem, steembasicincome is already set up on https://www.steemdunk.xyz, so posts should be autoupvoted with 100%. Keeping the voting history close to the 28. 👍
So with that running in the "background" and with upvoting comments here and then (I'm pretty sure I will still reply to content.) everything should be fine now.
Also, I'm only upvoting with 14 SP (red fish here), basically I'm getting way more back then I'm generating with those votes. Even with 28+ votes.
A totally another thing, because I'm curious: From a theoretical point of view, the calculation from the bonus shares seems only be based on the number of votes and the upvote weight. One account with, let's say 100 shares, would make a 3,8 Steem per week from steembasicincome over the course of 180 days. (Based on the ROI of 180 days with 100 Steem inital investment) To double his number of shares he would need to upvote 28 times with 100%. His return for those votes would be 3,8 Steem per week over four weeks. So in total roughly 15,555 Steem. He is getting basically 0,555 Steem per vote in return.
Smartsteem is paying 85% of a vote's value. So 5000 SP would generate (with data from now on https://www.steemnow.com/) a 0.67$ worth of upvote and Smartsteem should pay roughly 0,569 Steem per vote.
So the account would generate more income with selling those votes than with upvoting steembasicincome to get bonus shares. (unless he gets more steembasicincome shares, then it would need a higher amount of SP and so on) Ofc he could still upvote steembasicincome because he likes the content or he is generous, but the financial advantage is capped for a whale.
Don't get me wrong, I really like the bonus shares (Obviously 😁). And they are really good for red fish and minnows to get things going for them.
But I would like to understand the design choice behind that system, what was the intention?
It was a design choice based on the limitation of manual processes for calculation of the upvote weights each member receives. We are moving into a fully automated system soon, and it will have a better system for rewarding upvotes that will provide more incentive for members to upvote our material.
From what I have read, the added income from the upvotes also is used to increase the value of future votes, correct? So the added votes may not have an immediate impact, but long term it adds to the trailing income stream.
We use the enrollment fees to lease delegation and maintain target voting power levels so that the return is relatively consistent over time. The added income from upvotes and curation reward decreases our dependence on leased delegation and unlocks the possibility of our SP rising above those target levels. At that point, the basic income we deliver could grow exponentially.
That sounds awesome. 😁 Can't wait for sbi to be that far.
But that keeps me thinking: That only happens when every pool has enough SP, right? I mean the moment steembasicincome gets enough SP together, isn't that pool delegating to sbi2, sbi3, etc.? So that their dependency on delegated leased SP is reduced. Will the amount of SP between each pool equal then? (After the automation of course, could be too much work to maintain equally SP levels between ten pools)
What happens with the price of a share then? Will it be still 1 Steem?
Quite curious about that future planning there. 😅
Price will always be 1 STEEM. There are some future features that we have in mind but are not ready to announce yet. Each pool is managed to a multiple (not even SP between pools, because they have very different share counts, but there is also a slight difference in the target multiples.
When the first pool gets enough SP to decouple from needing leased delegation, part of the SP spills over into the next pool to help it toward decoupling, and so on as each pool decouples it will boost the next.
Thanks for the answer, design based on the manual work it needs, thats a good choice. 👍
Can't wait for the automation of it. 😉