Liquified risk and reward

You might have noticed the other day the announcement from @acidyo for @reward.app, a service that has the ability to alter the curation percentage so that an author can give more rewards to voters. I don't know how many years ago it was, but I have mentioned that a curation reward slider should be introduced for authors to affect rewards and this is somewhat like that. I support experimentation and while there are plenty of ways to abuse it, I still think it is worth the testing. It manages this through beneficiaries that liquify the rewards and then distribute them outward.

You might have also noticed another post from @curangel that says, no posts with liquified rewards will get curated and a message is left on the author to mention that they were curated, but missed the vote on that post because of the liquids. The position here is that they want to encourage people to look long-term, not liquify through a middleman service to sell. I support this too.

This tension between the two positions is good.

You might have even read a post by me the other day talking how every system will get gamed and that I believe that complexity and "no clear path" to optimization is part of the solution to controlling abuse. It doesn't matter what system it is, people are going to find ways to game it and Hive has many systems, which is why abuse can run relatively rampant, but due to the EIP, large scale abuse is less.

@reward.app can be seen as a type of vote-buying service, as it could encourage curators to look for ways to maximize their curation by targeting the accounts that offer the "best" curation percentage. This sounds much like bidbots that would offer the best ROI - but there is a bit of difference in @reward.app that I believe needs to be considered, as it adds in a factor that didn't exist earlier.

Previously, Bidbots would take HBD/HIVE payments and then would vote on a post at a greater percentage of the payment so that the buyer would make some profit after payout. The majority of the profits however were made by the sellers themselves - the "curators" who delegated their stake for a percentage share of the purchases - plus curation returns. At one point, about 40% of stake on the platform was selling votes to about 1% of all the posts. One massive problem was that the profit for the delegators was protected as it was direct from wallet to wallet, meaning that there was zero risk to the business, all risk was on the buyer. The EIP changed the model because of this, as once there were free downvotes and the curation return was 50/50 split, the risk of buying votes was too great as it became very easy to turn that 10% profit into a large loss.

The EIP is of course still in place and this is a big factor to limit abuse as both the author and the "seller" are at risk of some kind, even though no one is actually directly purchasing a vote, it is based on the future value of the post payout. This is an important distinction to make and I will illustrate this with an obvious example.

Let's say there is a low-quality author that gets nothing usually because they offer crap, but then decides to give a 90% curation return and take 10% for themselves. This should attract voters looking to maximize their curation, but it is all on chain, meaning that if they do vote it highly, it is going to get downvoted also - in this case, to zero. This means that the vote they applied is nullified by the downvote and regardless of the added curation percentage, their vote attracts nothing - which is a terrible result for someone looking to maximize their curation.

This means that there is additional game in the system where a curator might want to maximize, but they also have to be wary of the kind of content they vote as if it is downvoted, they lose potential returns. The bidbot operators and delegators didn't have to care at all about the content because the majority of their profits (the purchase price) was never open to downvotes at all. The EIP had the effect it did because authors didn't want to lose.

@reward.app flips this a bit because the authors have less to lose than the curators, as they don't make a purchase, but the curators have stake and can definitely earn curation returns on content. This means that even if authors use the service and offer much larger curation, it doesn't necessarily mean that curators are going to find it attractive to vote on as they have to consider the downvotes. There might be accounts that curate them regardless and take the risk, but these aren't likely to be the larger accounts. Also, if the votes aren't significantly higher than what they would be without using the service, the author will be "losing" potential earnings as well.

What could be introduced in the future is a list of accounts using the service, percentage of curation added and pending payouts, this would allow people an opportunity to negotiate the value of the post with downvotes and return that value to the pool, which means from both author and curator. This could bring in some very interesting information in regard to curation practices and how post value is perceived. On top of this, things like "hidden" curation percentages could be introduced and other factors like randomization and bonus lotteries where for example, I could charge a lottery account to be distributed on a random future post.

Not everyone is going to agree with all of the various changes to the system or how people use the code, whether it be layer two like @reward.app or on the blockchain code itself, but experimentation is needed and the system has to keep evolving and creating and destroying parts of itself in order to grow stronger, more diversified, decentralized and robust. As I said in the post linked above,

On Hive, I believe that to combat negative usage, the system itself should be simple from a user perspective, but there should be increasing complexity and change through a fracturing of the many systems into usecases that are narrow.

What this means is that users will have an increasing amount of decisions to make in the path they take. For example, I tried to curate a post with @curangel and it was rejected because it used @reward.app - they got an automated comment about stating this and saying that future posts won't be affected, only ones that liquify rewards. This is a good thing, as now that author has to make a decision on whether it is more important for them to liquify their rewards and offer a greater curation percentage or, get curated by a project.

Decisions, decisions - and the more decisions that need to be made and the more opportunity cost each has, the less clear the game gets, so people will have to choose a path which will exclude other paths. For the curators that used to delegate to bidbots in a "set and forget" approach, targeting @reward.app high curation posts might cost them more than voting on posts that don't use it, which means they are going to have to pay some attention to what is going on - something they didn't have to do with the bidbots, as they could just get their cut sent to them automatically each day.

A side benefit of this experiment is that it might encourage people to use their downvotes again, as without the bidbots voting on crap, it isn't clear for many people where they should use their 2.5 downvotes a day, so they don't at all. A post that uses @reward.app might attract more votes, but it could also attract more scrutiny from the community, which is a good thing - as if it is really valuable, it might get more votes .... but if it isn't and is already high...

I look long on Hive and want people to power up, but I also want there to be an increasing amount of options and pathways to take, rather than everyone crowding around the obvious. I very much disliked the bidbot era and actively worked for years to undermine it, but a lot of the problem with it was that the incentive to sell votes wasn't exposed to risk. Risk is an important part of the game, especially when it comes to abuse. There are physical, financial, legal and of course, social risks that affect our behaviors.

I don't know how the experiment will evolve, but I think that it is an important discussion to have and the system feedback could prove invaluable for making decisions in other regards also. What I do like is that like @blocktrades mentioned in his post on Hive as a second-layer blockchain,,

Anyone can write their own 2nd layer Hive application that gives meaning to these custom_json transactions, and they can do it without requiring any changes to the “core” Hive software.

the developers themselves are exploring what is possible without changing the code at the blockchain level, but still able to attempt to affect the distribution and usecase spread. Not everyone is going to agree with how this is done, or who it is done by - but it makes for a dynamic environment that continually increases the difficulty to wholesale game the system. This will have many misses, but I hope there will be some decent hits in the mix too.

What are your thoughts on this app, as well as the continued exploration of possibility on the Hive second layer?

Taraz
[ Gen1: Hive ]