You are viewing a single comment's thread from:
RE: Operation: We are The Open Mic
Its a rare situation when I have to say someone who I'm friendly with... I really hope you are wrong... There would be a work around if this is the case, to power down constantly, but it would kind be a pain in the rear.
Yeah I really hope I'm wrong too, but it looks like we might have to wait for HF20 for that to happen.
A better workaround is to do it the old-fashioned way and just have the users send some of the SBDs from their payout.
There is a psychological barrier there that would be hard for many to jump over. Its the old...
"Freedom is awesome, but I caught the bird" conundrum.
Most, not all obviously, not you... Would look at their SBD's in their wallet and say... but... i only have X amount.... and suffer from paralysis by analysis.
unfortunately @tcpolymath is correct. Beneficiary rewards are paid out in SP only and this definitely reduces the overall payout on a post (assuming SBD is over $1 at time of post payout). I experimented around with beneficiary rewards when doing collaborative music posts with other musicians but in the end it was better to just split the liquid SBD. Which is probably the best solution here - I understand what you are saying about decision paralysis when it comes to actually sending SBD, but I am pretty sure anyone who would set a beneficiary for Open Mic in the first place would also send some SBD. Same difference really, except for one reduces the value of the post :(
hrmmm... I see, thank you carl for showing up and answering our doubts, as always you rock...
Another question, if you dont mind... Is this built into the code?
Or could this be changed through a different front end?
First, in the case of just a 10% (+5% to SteemPlus) beneficiary, the total difference in post payout isn't going to be that huge so maybe this is just making a mountain out of a molehill. There isn't anything wrong with what you have suggested.
The beneficiary bit is coded in, and that distribution happens before the rewards ever reach the post author. E.g. if you set a 50% beneficiary on a post that paid out $12, $3 goes to curators (assuming 25%) and of the remaining $9, 50% would go to the beneficiary in the form of SP... so $4.50 USD worth of SP at current prices. That would leave $4.50 value for the author, which would be split in half per normal, $2.25 USD value of SP and 2.25 SBD. That reduced amount of SP and SBD is all the author would see in their wallet when it came time to claim rewards.
But there isn't any reason a front end couldn't distribute rewards to multiple people at the stage of claiming rewards. So for instance if it were an Open Mic front end, when you claim rewards it could give an option of something like this: Claim 100% of your rewards for yourself; Tip 10% to Open Mic and claim 90%; Tip 25% to Open Mic and claim 75%; etc. This would basically just be a transfer function done behind the scenes - best way would probably be to prompt for active key permission if one of the "tip" options is chosen (vs. storing active key permission which is problematic).
Cheers
The main issue is reduced value right cuz openmic can still grow its vote this way and pay through votes 🤷♀️
Yeah it actually literally reduces the total payout value of the post. Adding up the USD value of the beneficiary reward and the USD value the author reward, the total payout value is less than if the author took all reward. It basically increases the % of the total payout that is paid at US dollar value of Steem, and decreases the portion which is paid out in a number of SBDs equal to that part of the payout value (so as long as SBD is > $1, beneficiary rewards reduce the total payout value of the post). So if an author is willing to send SBD, it makes more sense to do it that way.
But do they need snd to pay ppl or steem power to upvote? Its such a mess to power up these days 😂