Jormungandr: Stake pool overdelegation

[onyxstakepool]

Is your feature request related to a problem/context ? Please describe if applicable.
Assume k is the number of desired stake pools.
The concept of overdelegation, i.e. a pool with a stake of more than 1/k total stake, is difficult to manage for the normal user, the delegator, and the stake pool operator.
Polularity of a stake pool leads easily to overdelegation outside of the control of the initial delegators. It is also hard to manage from a pool operator point of view. Open a new stake pool, try to move people to the new stake pool?

Describe the solution you'd like
New proposal: Allow the stake pool owner to lock/unlock the pool for delegation.
[Old proposal: Delegation to a stake pool should be rejected if its stake (current stake + delegation) is more than 1/k total stake.]

Additional context
The modification introduces a "first come first serve principle" for delegation to a pool.
This is much easier to handle for the delegator and the pool operator.

[mmahut]

I would vote againts this approach and I think it is not in Ouroboros papers intentionally. There are situations when the oversaturation is temporarily okay, such as right now, where most of the pools are not running or performing very poorly.

[onyxstakepool]

Describe the solution you'd like
Another possibility to give more control to the pool operator: Allow the stake pool owner to lock/unlock the pool for delegation.

This would only be a minimal addition to the protocol and is backwards compatible with the current system and still gives the same effect as the initial proposal.

I have updated the proposal in the initial post.

[stanfieldr]

Keeping delegation open forces delegators to stay active and participate in the system rather than setting and forgetting, just my 2 cents

[Linicks]

The current system doesn't seem to offer good checks and balances at the moment. I see the need to allow over delegated pools, but I also see large pool operators creating a compounding "ADA Race" where they come out of the gate with huge amounts of ADA, get the highest amount of rewards, spawn another pool, and repeat. Naturally, they're going to be the largest block producers because they are given the most opportunities. It seems to me that it makes sense to warn but not block someone that wants to stake a saturated pool. However, stakers should also be given a more balanced performance metric. The current performance metrics seem to give block production too much weight at the moment. Yes, it's important, but in reality once the node software can function reliably without all the restarts, forking, etc, most nodes will produce their blocks. The performance and voting metrics should accommodate for saturated pools by reducing their performance ratings in wallets, and in slot time selections. If having a balanced, high performance, and a relatively equitable distributed network is our goal, we've got to address more than just the technology. I realize all of this is being worked out and is probably already in a paper somewhere. At least the ITNv1 is doing its job and teaching all of us a lot about the current implementation, and what parts of the protocol that need to be implemented next. Another 2 cents....

[lednersinn]

If not for overdelegation, locking pool delegation would still be a good addition for pools that for some reason decide to gracefully shut down, give delegators time to switch while not letting others to join the pool in the mean time.

[Proxiweb]

I think overdelegation should be addressed by informing users thru the wallet UI in the pool selection view.