Published via Ecency

For the last couple of weeks, I've been discussing the Hive5 proposal published by @agorise, currently in its third iteration (v. 1 3.1).

Last week, I discussed upvotes and downvotes, covering Section 2A of the proposal. The previous week, I covered the introduction and Section 1. This week, I'm on Section 2B. The first point Aggie makes is

How much $HIVE you earn (or lose) with Votes, should not be based on HP anymore. (Hive) Power delegation must be individual, time-limited, AND CONSTRAINED. Otherwise, without fail, Oligarchies with combined, endless Power are formed.

As a writer, of course, I'd reword this, but regardless of the wording, regardless of how the sentiment is expressed, I doubt very seriously this proposal is going to get much support. It will undoubtedly not get any whale support on Hive. There are a few reasons for this:

First, why would anyone whose very livelihood is based on the Hive Power they've accumulated over the last six years vote to give up the giant sweets bag they feel they've earned? Answer: They wouldn't.
Second, even if the proposal was fully supported by the remainder of the community, it would still be an uphill battle to get developers to change the code to make the changes proposed. Doing so would be disruptive in a major way. In fact, it would be disruptive in the same way it would be disruptive to change the U.S. economy from its current capitalist structure to a socialist structure. It would be a huge undertaking that would require buy-in from many different quarters of the economy, most of which would be resistant.
Third, as it stands now, the specifics offered to accomplish the above are murky at best. At worst, they're just bad ideas. More on that in a bit.

Before I go on, listen to the discussion between @unklebonehead, @kencode, and me on Section 2B, titled How MUCH income is affected from post/comment Votes?

How MUCH income is affected from post/comment Votes?

I want to cover these points one by one with some specific thoughts on each one.

Paragraph 2 of Section 2B reads:

The amount of $HIVE that is given to (or taken away from) a post can be weighted by:
the average price of $HIVE in USD over the prior 24 hours of the post (rather than based on a timezone). We'll refer to that timeframe as "today". If usd price is unavailable from api’s or site scraping, then the last 3 days usd price gets averaged, and
the remaining daily budget available for UV’s for "today", and
divided by the number of active users on the chain in the last 24 hours.
In other words, the value of everyone’s UV or DV "today" (because of $HIVE usd price fluctuations) will be equal, but also worth less and less as "today's" allotment is depleted (yin/yang balance).

In other words, the proposal seeks to change the way stake-weighted voting operates. First, it's unclear to me whether these four points are offered as four different options or whether they are proposed as four measures working in tandem. Either way, I believe it's foolhardy to expect a change from the current HP-based weighting system to any other system to operate as a net positive. That's not to say there aren't issues with the HP-based system, but if there were to be changes to it, the wisest course of action moving forward would be incremental changes rather than big, bold sweeping changes.

Let's take the price of Hive. First point above. If Hive ditched the current HP-based voting mechanism and replaced it with a voting mechanism based on the price of Hive, what effect would that have on the Hive economy? Let's explore:

No. 1, any voting system based on the price of a non-stable cryptocurrency (which is every cryptocurrency that isn't a stablecoin, and could be even some stablecoins), is going to introduce the natural volatility of cryptocurrencies to the voting culture. Imagine if voting in the U.S. was based on the value of the U.S. dollar at any given time. In every cycle, whenever people cast their votes for one candidate or another, the value of the dollar would rise or fall based on the accumulation of those votes. Is that really a system we want to institute on Hive? It would be disastrous for the tokenomics.
Another thing to consider is the source of information. What source, or sources, would we use for determining the value of Hive at any given time? Prudence would suggest that using just one source would be detrimental. Therefore, multiple sources would make more sense. But which sources? I doubt we could even reach a consensus.
Since we're dealing with an average price of Hive over a 24-hour period where the 24-hour period is defined by each post's publication record, every post would have its own timeclock for payouts, as it currently does. However, since the payout would be based on the value of Hive during that 24-hour period, posters would spend an inordinate amount of time trying to guess the best day and time and to post to maximize their rewards. During a downcycle, you might have a large cross-section of creators and curators refraining from posting new content for fear that their earnings would drop. A negative downward-spiraling loop in Hive value combined with less content posting could send the economy into Purgatory at best and Hades at worst.

These are just the negative consequences I can come up with off the top of my head. Needless to say, I think that would be worse than the current HP-based voting mechanism we currently have.

Another point I want to make about that is the current HP-based voting mechanism rewards contributors for their time and the value they've already contributed to the blockchain. Someone who has consistently posted to the blockchain for six solid years has a high HP because of their output and the value they've added to the economy. I don't want to take that away. If Aggie's Hive-value voting system was implemented, I would not do away with the HP-based system completely but simply use it to adjust the current system. Even then, there could be negative consequences.

Paragraph 2 deserves a little background. The "remaining daily budget" is a reference to the Hive rewards pool. Every day, new rewards are generated on the blockchain and distributed to users based on their upvotes and the weight of those upvotes relative to other users on the chain. As more users receive payouts for their upvotes, the rewards pool diminishes until all the rewards for that day are paid out.

Under Aggie's proposal, "today" is based on when a post or comment is published. If a post is published at 9:30 a.m. EST on Wednesday, October 25, 2023, then that moment is the beginning of the 24-hour "today" period. But the rewards pool count is not based on that "today" period count because that period is different for every post and every comment. In terms of coding this, as it's written presents a logic problem for coders.

The proposal then suggests dividing the "remaining daily budget" value by the number of active users in the last 24-hour period. In the podcast, Ken Code clarifies that by saying the definition of "active user" is anyone who has contributed to the blockchain in any way within the last 90 days. That makes this a pretty liberal idea and probably isn't a bad one. If we take all four of the points under this Section of the proposal as a part of the same package, this piece of it increases the value of the proposal, but I still don't think it's enough.

It seems the entire point of the proposal is to punish whales for being whales, and that's a bad idea. I don't want to punish whales for being whales, but I also don't want to punish plankton for being plankton as the current system seems to do. I believe that new Hive users should prove themselves of value to the blockchain before receiving value from the blockchain, but those who are currently on the blockchain should give them a fair opportunity to do so. A proposal that strikes that balance would be a decent proposal.

Point 4 is an appropriate conclusion, noting that all votes (up or down) would be equal because they would be based on Hive value rather than HP while also noting that each vote (up or down) would be worth less as the 24-hour period progresses for each piece of content on the platform. There are two issues with this:

It's not entirely clear that basing a vote's weight on Hive value would make everyone's vote equal. It could destabilize voting altogether. While whales would not necessarily have greater influence on the blockchain simply because they are whales, basing influence on the value of Hive would change the game dynamics to reward those who can successfully manipulate the value of Hive by "injecting" new value into the system before voting and removing that new value when it's more beneficial to their interests.
Decreasing the value of votes over a 24-hour period would penalize people based on geography. The value of an upvote would reward users within the same geographical reason over those on the opposite side of the globe. They may seem fair to some, but I think it's impractical. Why shouldn't Chinese voters who appreciate an American Hive creator's posts be allowed to earn as much as their Canadian counterparts?

Downvotes and Hidden Posts

The next two points on the proposal involve downvotes and hidden posts. I don't have as strong a reaction to these points as I do the previous points, but let's discuss them.

Paragraph 3 of Section 2B reads:

DV's (when possible) will return that proper, equated amount right BACK INTO the daily budget for use by other UV’ers taking place in that day's timeframe. Why? Imagine Hive blockchain only has 50 posts and $50 available to distribute today. If 1 post gets a billion UV's, then those UV's must be worth less and less as each one comes in so that other users actually earn something. No one post can earn more than that posts percentage of the total posts that have been placed in the last day. DV's reversing/returning funds also helps to increase a new user's income.

I'm not sure what "No one post can earn more than that posts percentage of the total posts that have been placed in the last day." means. What I'm pretty sure about is that returning the value of a downvote back into the rewards pool is not necessarily a bad idea. I'm not sure it's the best idea, but I don't oppose it. I've already discussed the lessening value of upvotes over time, so I won't address that again.

Paragraph 4 reads:

Getting Hidden/Muted: If this guy gets 10 UV’s and 16 DV’s (51% more DV than UV), his individual post or comment will be flagged on-chain as "unliked" and muted by default until enough UV’s are received to reveal his post again. This is not time limited. Actual rewards payouts will remain at 6.5 days.

I don't have anything against this idea. It's actually pretty good. I think the reasoning behind this is to take away the ability of one whale to sweep in and take away the built-up value of cumulative votes on posts that one certain individual thinks is overcompensated. I totally get it. A new user shows up, posts an introductory post, and the community upvotes it to $100. One whale comes in on the sixth day and downvotes it to $2.00. That new user now thinks a huge injustice has occurred, not fully understanding the dynamics of voting on the Hive blockchain. They have just had the wind sucked out of their sail and leave Hive because they think it's unfair and benefits only those with huge amounts of Hive Power saved up.

While there are arguments in favor of HP-weighted downvotes, I do believe some controls are in order to prevent the above scenario from happening over and over again as it has been done for the last seven years (since Steemit launched in 2016). But is this the solution?

I personally think it's overly simplistic. However, I can appreciate the 51% more downvotes means a post is flagged as "unlike."

What if, instead, we had a progressive downvote tax? For plankton and minnows, a downvote is a downvote, worth 100 percent of your full vote weight. Once a user becomes a dolphin, their downvote is worth just 80 percent of their vote weight. A shark's downvote could be worth just 65 percent of their full vote weight and a whale's could be worth just 50 percent of the full vote weight.

I'm sure that isn't going to go well with some people either, but this system wouldn't punish whales for being whales as it wouldn't touch the value of their upvotes while it would also not penalize small fish for being small fish as whales could still downvote posts they believe are overcompensated but with less influence and therefore a lesser possibility of driving away new users. The blockchain already has a mechanism in place that diminishes the value of upvotes and downvotes over time based on the weight of those votes and the frequency. Too many restrictions and constraints would impose severe punishments on those who have earned the right to greater rewards and would do nothing to incentivize the smaller fish.

That's my two cents. Feel free to discuss.

Learn more about Web3 social media platforms like Hive in my book Web3 Social: How Creators Are Changing the World Wide Web (And You Can Too!).

This post was first published by Author Allen Taylor at Paragraph. Image is a screenshot.