Thinking like a multi-pool operator

Everyone knows there is a vote underway on mainnet for stake pool operators to register their preference about how paramaters K and minPoolCost should change. So I thought it might be useful to view the vote options through the eyes of a multi-pool operator.

Option 1: Keep k at 500 and minPoolCost at 340

Some multi-pool operators may vote this. No change, same pay, no effect on decentralisation.

Option 2: Keep k at 500 and halve minPoolCost to 170

This is the only bad option for a multi-pool operator. They have no excuse to split their pools further and they can only farm the same number of minFee chunks with the value of these being halved. This means they will take less rewards from delegators. This is good for delegators, but very bad for multi-pool operators. I would be amazed if any multi-pool operator votes this option.

Option 3: Increase k to 1000 and keep minPoolCost at 340

This is the best option for a multi-pool operator. They have an excuse to split their pools further because K will increase. They will tell the community that the protocol has forced them to split and that they are only doing so to protect the interests of their delegators. Splitting will enable them to farm more 340 Ada minFee amounts. Each pool they run will still get the same 340 Ada min fee, plus their percentage, but now each pool will do less work (produce less blocks). Effectively the operator will earn a higher percentage of rewards from their delegators. Win Win Win. Smart multi-pool operators should vote this option and simultaneously publish FUD about how lowering minFee is bad for small pool operators.

Furthermore, the number of multi-pool operators will increase. This is because there are a number of single pool operators that are close to saturation and many of these will choose to split their pools and become multi-pool operators. They can also farm more minFee chunks by joining the multi-pool operator gang. Solidarity in numbers.

Option 4: Increase k to 1000 and halve minPoolCost to 170

This is almost the same as no change for a multi-pool operator. With k increasing they have an excuse to split their pools. They just need to spin up twice as many virtual machines running as block producers and create the necessary keys. These VMs are easy to manage and they can all communicate via their existing couple of relays to the rest of the Cardano network. No extra cost really.

So they will have twice as many block producers with each earning half the minFee + percentage. Their income will be unchanged. Delegators are no worse off. But there is a little bit of extra work for the operator to initially spin up the extra block producer virtual machines, so this would not be the preferred option for a multi-pool operator. But, it is not really any different to “no change”. Probably some could vote this way if they worry that their delegators might work out the game theory.

Options 5 and 6.

Both these options probably don’t achieve much. Some small pool operators may vote 6: “none of the provided options” but this doesn’t say much about their reasons. Probably not much point in a multi-pool operator voting this option.


There is really only 1 bad option for multi-pool operators and that option may also be seen as bad by some single pool operators. That is option 2: “keep k at 500 and halve minPoolCost to 170”.

I am starting to think that with the way this vote has been structured, option 2 may be the only option that might actually increase decentralisation. No doubt, it is really hard to structure polls to produce good outcomes. Probably there needed to be more community discussion about the game theory.

Having more multi-pool operators doesn’t improve decentralisation. The huge minPoolCost is a barrier for small pools to compete. It should be reduced to 30 like the IOHK Quant @Colin_Edwards explained in this post


Excellent steelman! It’s a shame instead of the race to farm minFee, it should be a race to grow pledge to grow your pool size, and thus increase the network’s sybil attack resiliency.

The MPO minFee farming (1000/340 option) will only grow compounding rent rewards and establish an SPO Oligarchy Class. No new pool will ever be able to compete with them in 5-10 years. The economic incentive to run a pool will disappear.


Well, I decided to vote option: “keep k at 500, halve minPoolCost to 170” for the reasons in my previous post.

But I did add some metadata to my transaction stating that I would have preferred to vote a minPoolCost of zero with some brief reasons.


Seems like the best option to me… I don’t find the arguments for minPoolCost to be holding much water… I’d definitely vote for lowering it gradually towards 0 and see how the network reacts and possibly changing it out for a minPoolMargin instead… I’d leave k at current value just to avoid the logistical hurdles of increasing it…

not that I’m an SPO :stuck_out_tongue_winking_eye:


I think it is worthwhile trying to put yourself in the shoes of a multi-pool operator and think what they would most like to achieve. I think these things are high on their list:

  • Normalise multi-pool operation through community acceptance and blunt the community’s ability to apply social pressure. (<.sarcasm>Thank you CardanoFoundation!</.sarcasm>)
  • Split pools further in order to farm minCost amounts.
  • Drive the narrative that all stake pools require bullet proof server setups with high end gear and super redundancy so the cost is out of reach of your average small competitor. (This ensures only large multi-pool operators can afford the setup.)
  • Resist any reduction in regulatory competition barriers (eg. reducing minPoolCost).
  • Create false narratives about small pools going out of business if minPoolCost is reduced.
  • Drive narratives about what pool operators should be doing aside from faithfully running the cardano protocol, such as building tools or making podcasts. Multi-pool operators can more easily do such extras by building a bigger team supported by their pool mogul operation. But, is this the problem that staking was designed to solve?