As noted here, the 100% voting power equilibrium point is being reduced from 40 votes per day to 5 votes per day in version 0.14.0. Among the core developers, I was a strong proponent of this change. In this post, I'll explain my reasoning.
The primary reason people are concerned is that, while "5 votes per day" is a technically accurate description of the equilibrium point, it is also highly misleading.
Leaky bucket dynamics 101
One of the fundamental principles of Steem's economic system can be described as "one Steem Power, one vote." The problem is that (obviously) the design of a social media website involves each user making multiple votes over time, unpredictably, as they have free time and find things they like.
The system is clearly unfair if Bob, a user with 10 SP, votes a thousand times and gets the same voice as Alice, a user with 1000 SP who votes ten times. The way we handle this is a leaky bucket system: Each user account is a bucket which holds up to 10,000 units of voting power -- we might imagine this as 10,000 mL of water. The bucket dynamics are as follows:
- Each user's bucket gets a steady inflow of water at a rate of
Runits per second (Ris the same for all users). - When a user's bucket is full at 10,000 units, its inflow spills over and is wasted.
- When the user votes, the volume drops by some percentage
p(pis the same for all users); the user's effective Steem Power for that particular vote is multiplied by the amount of water removed.
These are competing forces on the bucket's water level: Voting and spillover pull the water level down, while the inflow pushes the water level up. If the user votes at a constant rate, the water level will eventually settle at a point where the forces are in balance.
Parameters
The 100% voting power equilibrium point, vote_regeneration_per_day for those following the source code, is the voting rate where the forces are in balance at the 10,000 mL level. The integration window, STEEMIT_VOTE_REGENERATION_SECONDS, is the amount of time it takes for a totally empty bucket to refill to 10,000 mL; it is remaining unchanged at five days. The parameters R and p are completely determined by vote_regeneration_per_day and STEEMIT_VOTE_REGENERATION_SECONDS.
Effectively this change reduces vote_regeneration_per_day from 40 to 5. (Yes, the actual patch is more complicated, because it also changed from hard-coded numbers to a global property constant, and fixed a rounding issue.)
The real problem
And now we can get to the crux of the problem.
- A water level less than 10,000 mL seems bad, because it reduces the power of each vote.
- A water level less than 10,000 mL is not actually bad, because the reduction in the value of each vote is exactly balanced by your increased number of votes.
- A water level less than 10,000 mL is actually good, because the real enemy is spillover; every mL of spillover is wasted influence you didn't use, and staying below 10,000 mL keeps you out of spillover territory.
While it's technically accurate to describe 5 votes per day as the maximum number of maximally effective votes, 5 votes per day is better described as the minimum number of votes for a user to be given a full voice.
Now suddenly it's clear why 5 votes per day is a better threshold: It redistributes the ability to grant curation rewards away from heavy users and bots to more casual users.
A parting question
Suppose Alice and Bob each have 1000 SP. Alice votes 5 times a day and Bob votes 40 times a day. Should Bob get eight times as much influence and eight times as many curation rewards as Alice, or should the system give these two users an equal voice?
If you believe that Alice and Bob should have an equal voice, then you, too, are actually a supporter of this change!
)
