Should stakePoolTargetNum (k) be raised from 500 to 1000? (SPO poll)
16 DReps voted · 10 with a rationale
Open a row to read the rationale.
Voting concentration
1 of 16 DReps cast half of the voted power.
Largest voter 67.8%, top 5 combined 95.7% of 657.7M ₳ voted.
- Abstain445.8M ₳Rationale
The proposal invites DReps to vote, but states that "DRep votes are not included when determining whether this Info Action has established an SPO mandate." As this is an SPO poll and DRep votes do not affect the outcome, I abstain.
提案文は DRep の投票も歓迎していますが、「DRep votes are not included when determining whether this Info Action has established an SPO mandate（DRep の票は SPO の支持判定に含めない）」と明記しています。SPO 向けの意思確認であり、DRep 票は結果に影響しないため、ABSTAIN とします。
- No69.8M ₳Rationale
I am voting ❌NO on this raising k to 1000, here are some of my reasons in random order:
- total misconception of where redelegated ada will flow. it will NOT flow to small/tiny pools. if even, stake will flow to midrange pools near the new saturation point of ~35M. not to pools below 10M imo.
- not sustainable with current ada price, typical pool values generate low rewards for spos. keep it sustainable for the current pools, don't make it unsustainable for all pools.
- extremely big risk to force delegators to redelegate during this bear market. rewards on cardano are generally low nowadays. i predict that many stakers will leave the cardano ecosystem as a whole, because there are options with a much higher roi out there.
- the pools that will suffer from such a change are community pools that have done nothing wrong in the past 6 years, they worked hard to gain stake and delegators over time. such a k change to 1000 would drive them into saturation. which hurt the delegators of such community pools a big time.
- changing k to 1000 is like stealing staking from large community pools, enterprise pools simply split. it does not hurt them.
- enterprise pools with full delegation control will simply double there pools. larger community pools will suffer.
- i wanna see CIP50 play out first. we got it to be implemented, now we should not frontrun its activation and pledge depending saturation level playout with a k change.
- we have a good decentralization, we dont need more pools
- some are suggesting to split pools, which only drives up hardware and costs. better if an SPO can run one pool instead of two pools with half the amount for stake each.
- No65.2M ₳No rationale
- No36.9M ₳No rationale
- Abstain12M ₳Rationale
本Info Actionは、stakePoolTargetNum（k）を500から1000へ引き上げることについて、SPOの支持を確認することを目的とした投票です。そのため、SPOの意思を尊重し、DRepとしてはAbstainとします。\n\nI vote Abstain. This Info Action is intended to assess SPO support for raising stakePoolTargetNum (k) from 500 to 1000. Therefore, I respect the decision of SPOs and abstain as a DRep.
- No5.7M ₳Rationale
We hold this to be detrimental under current market conditions.
- Yes5.5M ₳No rationale
- Yes5.2M ₳No rationale
- Yes4.9M ₳Rationale
YES — high confidence.
Not because k=1000 is already proven to be the correct parameter, but because getting a clean, current, stake-weighted SPO mandate on that specific question is valuable information and a sensible prerequisite to the actual parameter vote.
This is one of the clearer YES votes: low treasury risk, no expenditure, no parameter change enacted, and materially better information for the subsequent decision.
- Yes2.4M ₳No rationale
- Yes1.8M ₳Rationale
BKIND votes Yes, as SPO and as DRep. Concentration is measured rising, the change is reward-neutral against a lovelace-validated formula, redelegation is proven cheap, and the active network holds six times the capacity needed. I vote to keep power dispersed.
Action: info action f6fd3678f12edc...cb4c#0, Should stakePoolTargetNum (k) be raised from 500 to 1000? (SPO poll).
What is being decided. This is an Info Action: it changes no parameter and has no on-chain effect. It asks whether sufficient SPO support exists to proceed with a later Parameter Change action raising stakePoolTargetNum from 500 to 1000. The document declares its own standard for reading the result, and how that standard should be interpreted is disputed in the community. That dispute does not touch this vote: an explicit Yes, cast with the pool's full stake, counts identically under every reading on the table.
I verified the document I am voting on. The blake2b-256 digest of the bytes retrieved from https://gateway.pinata.cloud/ipfs/bafkreia3u74dgyvg5v3u7wxwip44wwqzyhynqqm4wzyhkkwevaiynlihnm equals the anchor hash recorded on chain, ab85aad06200d7d7ec79181b68d0651083ffdd9b9bcd15c54212d4d681a9b680.
I take part in Cardano governance in two roles, as operator of the BKIND stake pool and as DRep. My registered DRep rationale commits me to two things: keeping power on this network dispersed, and holding every proposal to evidence rather than narrative (drep17x37hhwte...l2slp4, smitblockchainops.nl/governance/drep.jsonld). This vote applies both, and my position is unchanged since I registered: the Cardano ledger should be carried by a broad network of independently owned pools.
The evidence below is reproducible from cardano-db-sync and verified against my own independently built indexer.
Concentration is rising. The top-50 pools' share of active stake grew from 14.1% at epoch 400 to 18.2% at epoch 653, monotonically. 158 pools now control half of all delegated stake, down from roughly 198 at epoch 300. While k sits still, concentration has only one direction: up.
The pool register overstates the real network. 2,896 pools are registered (epoch 655), but only 1,339 produced a block in 2026. 1,495 registered pools produced nothing this year and none of their registered relay addresses answers as a Cardano node: I probed all 2,449 registered relay endpoints, with node-to-node handshakes on everything that accepted TCP; a handful of addresses still respond, but with a refused connection, a web server, or silence. Together these pools hold 0.21% of active stake. Claims about the size of the pool network should therefore be based on the 1,339 pools that actually produce, not on the register.
BKIND votes Yes. stakePoolTargetNum sets the number of pools the reward scheme steers the network toward, and it is the one lever with a measured track record of moving stake. It cannot by itself guarantee independent ownership, but a higher pool count is the precondition for a broader owner base, and while k sits still, concentration has only one direction: up. The measurements say the network needs this step. I vote to keep power dispersed, and this Yes is that vote (govActionId f6fd3678f12edc...cb4c#0).
- Yes1.1M ₳No rationale
- No984.8K ₳Rationale
- Only adjusting K without addressing the other parameters like pledge influence, minPoolCost and minPoolMargin first is pointless.
- This will hurt some well-established OG pools who earned the trust of the community through all those years. Punishing them with a 100% certainty for an uncertain, potentially small, and untested benefit for the smaller pools does not make sense to me.
(I'm not affiliated with an OG pool nor do I run one myself)
- Abstain205.6K ₳Rationale
ABSTAIN — I see merit in exploring an increase of stakePoolTargetNum from 500 to 1000, particularly if it can improve stake distribution and create greater opportunity for independent SPOs. However, I am not yet convinced that doubling k will necessarily translate into greater operator decentralization rather than simply a larger number of pools.
Before supporting a future parameter change, I would like to see clearer analysis of its likely effects on operator concentration, delegation behavior, pool economics, and smaller SPOs.
I therefore abstain on this poll while remaining open to supporting the change if the evidence demonstrates a meaningful decentralization benefit.
- Yes90.5K ₳Rationale
At this point, just bring the parameter change proposal on-chain and see how the tribe decides.
- Yes56.1K ₳Rationale
This info action got hijacked by the author Chris from Str8 pool, altered to fit his personal intent, purposely omitting crucial information of the original draft, which was designed to inform the community as best as possible - neutrally. In doing so, Chris abuses the openness Cardano engages in.
A PDF version of this rationale is also made available.
The Parameter Committee meticulously drafted a plan to ask ALL of the voting community (SPOs and DReps) about raising k, in the most informative way possible. They prepared the arguments for, and the arguments against raising k and these series of arguments were to be linked in a neutrally formulated overview document, all so that voters could have a balanced view of both sides, with the intent of everyone being able to make an informed, educated decision.
Since stakePoolTargetNum is not part of the parameter group that would constitute SPOs to vote on a Parameter Change directly, the TSC, PC, members of other committees, and many more community members collectively agreed to go above and beyond what the protocol and the Constitution require and went out of their way to give SPOs a voice on this.
The Parameter Change should be preceded with an info action that asked SPOs whether the Governance Action that would change the parameter, should be submitted subsequently, following an approval to the info action.
This is a question concerning the authors alone - "Should they submit something else, or not". Further, since this is asked in an info action, which has the CIP-1694 defined purpose of not being able to be ratified or enacted, since they do not have any effect on the protocol (https://cips.cardano.org/cip/CIP-1694#enactment), there exists no adequate or correct approval threshold.
Knowing that a large part of SPOs voting power is locked in custodian's and infrastructure providers' client's wallets, where they evidently from previous Governance Action's lack of participation, do not engage in Cardano Governance actively, the Parameter Committee decided to use a threshold which would produce a definitive view of the active SPOs' opinion, while not needing to wonder why SPOs did not vote (implicitly no or explicitly not knowing that they need to vote?).This part is, among other things, apparently something that the Author Chris did not agree with, and he took it upon himself to submit an altered version of the draft, changing the intended approval threshold for the un-enectable info action, and omitting documents designed to inform the community.
Apart from the fact that taking other people's work, altering it, and submitting in a manner that suits their own narrative and intent, is extremely disrespectful and damaging to the community as a whole, which has to now question which documents to share publicly, very much not in the spirit that has bloomed within the ecosystem since years, and apart from questioning whether this action is Chris directly and deliberately trying to bypass the notion of informing the community, the debate on k may realistically continue with this action just as well. It is just sad to see a chance to get neutral empiric evidence on the wishes of everyone be clouded by a single opinion, causing a storm of confusion and mistrust.
I hope the SPOs consider the many informative documents that are available to them, which were created by the Parameter Committee, and vote with the best educated decision they can make - in plenty numbers.
Even though I am not being asked, I voice my opinion and vote YES to submit the parameter change governance action that asks DReps to raise stakePoolTargetNum to 1000.
Thank you everyone for reading, you are all appreciated and great.
Fuck you Chris.