HF20: Change Your Autovotes Now As New Posts Will Be Paid Using HF20 Rules

in #hf206 years ago (edited)

This is important for everyone who has autovoting set up. Any post published from now on will reach reward payout after HF20 and therefore will be paid out as per the new HF20 rules. I wrote a similar post yesterday but now have had confirmation that this is the case.

This applies to those who set autovoting to support their favourite users and to those who have been voting for themselves early, whether through paid votes or self-upvote.

The biggest change is that the curation rewards that used to go to the author will now be added to the reward pool. Doesn't matter now what you think about this idea - it's going to happen!

You can see how much this is on steemd as author_curate_rewards; the number is the percentage of the post's curation rewards that at the moment go to the author. From HF20 onwards, that amount will go to the reward pool. This should put an end to those who upvote themselves early, but genuine followers must also take a look at when they autovote.

With the new 15-minute reverse auction - compared to the current 30 minutes - this means it makes more sense to vote after 15 minutes. Voting earlier will no longer benefit the author, it just means that the vote value to the author has decreased and the voter has wasted part of their vote.

However, there does remain the scenario of a voter wishing to vote early to take advantage of a popular author who may later receive much larger upvotes. If that is your strategy, then you may need to change your autovote to half the current time. For example, if you currently upvote at 20 minutes, you may wish to change this to 10 minutes.

While we obviously need to wait to see the effects on the whole ecosystem, it seems to me wise to change some of the autovoting behaviour now in preparation for HF20.

Please resteem, as I don't see this issue discussed yet.

Thanks


- - - - - -
Please Comment, Resteem and Upvote. Thanks!

@rycharde manages the AAKOM project and the MAP Trail.

Sort:  

pixresteemer_incognito_angel_mini.png
Congratz, your post has been resteemed and, who knows, will maybe appear in the next edition of the #dailyspotlights (Click on my face if you want to know more about me...)
Check the rules of the Daily Spotlights if you want to nominate someone!
Pixresteemer is also listed as promoter on The Steemians Directory

I figured this was the case but when I mentioned it, some think that it will not work in this way (that it won't backdate to open posts). I was just going on what happened for hf19 so I don't know the technicalities.

Hi, I thought this would be an important issue, but have only seen chats in discord. I now suspect we may end up with a mixed calculation at payout. If one looks at the data on steemd, the "weight" column means curation-weight and is calculated at the time of voting and includes factoring in any curation loss due to voting before 30 minutes. I suspect recalculating all of those to take account of the new 15-minute reverse auction will not happen, hence everyone will be paid their curation rewards under HF19 terms. However, the curation amounts that end up going to the author, the author_curate_reward, may well be paid to the reward pool as per HF20 - unless there is specific code to not do so for posts published pre-HF20.

@crokkon might know something about this. At the end of the day, it is one week of calculations only so either way, it might not have a drastic (at least not long lasting) effect on most people. I am working under hf20 rules just in case anyway (unless I forget). :)

.

Thanks mate.

.

OK, thanks a lot, so my feeling that for 7 days we will have a "mixed" payout algo is correct. That is, the curation-weights will remain the same but the author-curate-rewards will go to the pool.

This does mean that those who currently upvote very early on a post should change the timing - unless that remains their strategy, but not if they are doing it to give the author an extra reward. In such cases they need to increase their timing... now.

.

Yes, sure, nobody should be decreasing their autovotes timing now, but those who vote very early should seriously think about increasing their timing now - like @indigoocean mentioned that Busy upvotes immediately on posting.

Actually, not so confusing, but few people seem to have discussed this.

In general, all data that has been written (such as weights and author-curation rewards) stays the same, but the payouts will be processed under the new rules.

That seems to be as brief as I can muster!

.

One other thing I suspect people will forget is that this also applies to comment upvotes. Most don't expect great curation rewards from comments, accepting that a large part will go to the author if, as now, the exchanges are close together in time.

Perhaps not many look so closely at the numbers as I do!

@crokkon - What is the meaning of this phrase? "reverse auction timeframe"

I have 20 people I upvote through steemdunk. I have them all set at 27 minutes. Think I should change them to 16 minutes now, correct?

I self vote and just set myself up for 16 minutes. I previously was manually voting right after I created the post. So I think I am better off to put myself on the autovoter now that I read your answers here.

.

Thank you so much for the answer. With my tiny votes, I'm not sure how much this matters, but I want the author or me to get the curation reward. Why vote and have it go back into the pool? That makes no sense. More mysteries of steemit!

Thank you for making this clear! All of us know about HF20 coming, but few really understand all the implications.

On Busy it defaults to upvote your post when you post it. I guess I’ll have to look into setting up an auto vote for myself to make the curation rewards go to others upvoting me instead of back into the reward pool. All my current auto votes are at 25-30 mins

Posted using Partiko iOS

Hi, your own autovotes are OK, maybe drop them to 16 mins or so. But those platforms such as Busy who autovote really need to look at this and change their algo as it will no longer benefit authors.

If using Busy you can just uncheck the box, self vote.
Then come back after 15 minutes and do the upvote on your own post manually.

Yes, of course, I have the feeling I misread the first comment in this thread; I thought she meant autovotes from the Busy team accounts, as many platforms promote themselves by giving out extra votes.

i hope the chhange will make steemit better ... i love this 15 minute reverse auction change ... but i dont like curation going to reward anyways its gonna happen ...

I like this post, now i will realice the question for me followers https://steemit.com/steem-bounty/@jmhb85/what-do-you-think-of-hardfork20-who-benefits

What should I do with auto votes that I now give at 0 minute?

Hi, the quick answer is to move them to 15 minutes.

The longer answer depends on why you're voting on 0 minutes.

Upvoting after 0 minutes to make sure the author gets a bigger part of all upvotes that follow after my upvote.

I have resteemed. I was aware of the changes, just never gave it much time because I don't autovote early anyway. I looked at some of the accounts I get auto votes from early and most have not been active in ages

Yes, depending on their size, they will have a small drag on curation earnings for all the other curators.

So basically votes on new posts simply burn RSHAREs?
Hope the steemit.com website will get updated to at least keep those posts out of our feeds, or move them down a bit so we don't end up throwing our VS away on the top-of-feed posts.

Not so much burnt as recycled. Having tried to solve the issue of early self-voting, we now have an algo where we all need to be wary in case the author-curation rewards are too high, possibly even by accident.

the author, from now on, will receive a fixed 75% of the upvotes (plus his own curation rewards for self-voting, just as any other voter) but part of the total curation rewards may be drained away into the general pool.

I hope people adjust their behaviour asap.

Thanks for the great explanation @accelerator. Did resteem the post hoping to help others.
Cheers,
Peter