Limit minimum bid for multiple key holders

I’ve been digging through the forum posts reviewing all the different suggestions for how to encourage more decentralization of validators. I have an idea that keeps returning to my mind that I haven’t seen addressed anywhere. I’m new to the scene here, tho, so if this has been discussed please let me know where that conversation is so that I can dig in and see what people have already said.

I don’t know how technically complicated it would be, but so far in my research I haven’t come up with any major downsides to this idea. I’m anxious to hear what critiques others may have on the proposal.

Could we dynamically limit the minimum bid to be no less than -15% of the median stake for all validators with multiple keys? I feel like this addresses several issues without adding unnecessary oversight or management:

  1. It alleviates larger validators taking up excessive amounts of keys without going down the retroactive key/delegator cap road (which doesn’t seem to be getting any traction on the posts I’ve seen about it). It doesn’t prevent larger validators from getting multiple keys, but it helps a little bit by keeping them in the median stake range. Small steps forward.

  2. It frees up the lower bounds from the intense competition that it has become. Established validators have no reason to be farming the lower bounds; all it does is prevent new validators from having a chance to get a foothold.

  3. It doesn’t prevent any size validator from being able to stay in the sweet spot for max return on rewards.

  4. It allows larger validators who are willing to contribute more to the community to intentionally drop keys without the risk of other large validators swooping in to pick them up before smaller validators get a chance. It doesn’t completely remove the risk of larger validators sniping these keys, but again, it helps alleviate the problem to a significant degree.

The only downside to this is the complication of the moving target. Median stake is constantly fluctuating, and bids could get pushed below the limit unintentionally. How do we handle that situation? A 1-epoch grace period to adjust your bid? Auto-adjustment? From a technical standpoint, I can see that this isn’t a simple solution to implement. But I keep finding myself wishing there was a way to free up the lower bounds to be the “validator incubator” that I feel it was intended to be, while keeping established validators up in the median stake range where they were always meant to be. This won’t free up a ton of keys, but I think it would free up maybe 5-10 keys, which would be a huge step forward for a lot of smaller validators. Maybe instead of a dynamic limit, it’s a set limit that is agreed upon via governance, and can be changed as the bidding environment changes. Ideas? Thoughts? Concerns? Share with me.


This seems like a great idea to me. I’m curious to see what other people think.
For the moving target issue what do you think about basing the minimum bid off of the median stake of the previous epoch? I think that would reduce complexity a lot and make things easier for everyone to understand.


That definitely makes sense, and I could see it working very well. I am not a validator myself, but from talking to a lot of them, one of my concerns is adding additional complexity to an already intimidating bidding process. So I’m curious, for the validators, how they feel about additional rules around bids that they have to be constantly managing every single epoch.


Looks like is a nice improviment for the process. As was noted, it won’t prevent the big enough to reach the maximum rewards, while leave some space for the small enough to grow up as well. Can´t manage to see a flaw at that proposal. Let´s see what the community thinks about it.


And maybe the 15% is absolutely the wrong number, I don’t know why I threw that out. Maybe it’s 30%. Even at 30%, it would still free up a number of keys and open up the bottom end a little. I’ve only done some real quick maths looking at the election analytics.


Hey Trigs! Your proposal is interesting, but I think it’ll get lost here. I suggest posting this as a reply to HIP-16, where the topic at hand is being discussed.