@sophia I think there are no great solutions to this problem, but a simple auction is probably the best approach. Have the “baker” of the pool for the next k cycles be put up for auction , whoever pays most gets to be the baker for next k cycles, etc. It’s simple to implement, it means the pool won’t lose out.
The downside is that the pool becomes, in some sense, automatically bribe-able, it will give its delegation to the baker that pays the most, without exercising any judgement. I don’t think it’s possible to do much better at the moment, and I don’t think it’s bound to be a problem unless the pool grows very large, which would be a good problem to have anyway. If it starts to, that bridge can be crossed…
-
It might help if the protocol allowed delegation to not carry voting rights, that’s an easy change that could make it into Proto7.
-
The tez could be kept in separate contracts, so that multiple bakers can be used. When a withdrawal is made, it would be drawn from the pool with the highest balance. Anyone could later submit a “request to re-balance” by specifying t pools with a different amount of tez. Why t instead of just looking at all the pools? Because of the gas limit, letting the “request-to-rebalance” limit itself to a subset of the pools allow for the equalisation of many pools over several blocks if there are too many for this to happen in one transaction.
