{
  "@context": {
    "@language": "en-us",
    "CIP100": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#",
    "hashAlgorithm": "CIP100:hashAlgorithm",
    "body": {
      "@id": "CIP100:body",
      "@context": {
        "references": {
          "@id": "CIP100:references",
          "@container": "@set",
          "@context": {
            "GovernanceMetadata": "CIP100:GovernanceMetadataReference",
            "Other": "CIP100:OtherReference",
            "label": "CIP100:reference-label",
            "uri": "CIP100:reference-uri"
          }
        },
        "comment": "CIP100:comment"
      }
    },
    "authors": {
      "@id": "CIP100:authors",
      "@container": "@set",
      "@context": {
        "name": "http://xmlns.com/foaf/0.1/name",
        "witness": {
          "@id": "CIP100:witness",
          "@context": {
            "witnessAlgorithm": "CIP100:witnessAlgorithm",
            "publicKey": "CIP100:publicKey",
            "signature": "CIP100:signature"
          }
        }
      }
    }
  },
  "hashAlgorithm": "blake2b-256",
  "body": {
    "comment": "# Vote rationale — NO\n\nI strongly oppose raising `stakePoolTargetNum (k)` from 500 to 1000 at this time.\n\nMy reasons, in no particular order:\n\n- I do not see sufficient evidence that doubling `k` will materially improve entity-level decentralization. Lowering the saturation point does not directly help small pools below saturation. Any benefit depends on displaced stake actually redelegating to independent pools that need it. Neil Davies' analysis makes this distinction particularly clearly.\n\n- I do not believe displaced stake will necessarily flow to independent community pools. Large custodians and multi-pool operators can simply redistribute stake among additional pools under their own control. That increases the pool count without necessarily increasing the number of independent entities controlling consensus.\n\n- Delegated stake is sticky. A substantial amount of stake does not move readily even when incentives change. That makes the assumption that billions of ADA will efficiently redistribute to the operators who need it highly uncertain.\n\n- I would personally be pushed toward operating a second pool. I have spent years building trust and organically attracting delegation to my pool. If `k` is doubled, my pool would become oversaturated and I would effectively be forced to establish another pool to avoid losing the result of years of work. Even then, there is no certainty that my delegators would follow me to that second pool. Large custodial or enterprise operators with direct control over delegation do not face the same problem.\n\n- This illustrates one of my fundamental concerns with the proposal: it can incentivize existing successful operators to split into additional pools rather than creating genuinely new independent operators. The previous `k` increase was subsequently associated with substantial multi-pool expansion, and Neil's paper cites later analysis concluding that it did not produce a proportional increase in independent entities.\n\n- Cardano infrastructure is already becoming more demanding. From my participation in the Musashi/Leios testnet, I am seeing increasing hardware and operational requirements ahead. I strongly oppose increasing the overall infrastructure footprint and operator cost without a demonstrated decentralization benefit. Increasing `k` is itself expected to encourage additional pools and nodes to be operated.\n\n- **We have not exhausted the current `k=500` setting.** `k` represents an idealized equilibrium target for saturation-scale pools, yet Cardano is still far from an equilibrium of 500 saturated pools. With roughly 21.4B ADA of active stake, only about 285 pools could currently be fully saturated at the `k=500` saturation point, while the network already has around 1,600 active pools. To me, this strongly suggests that the problem is not a shortage of available pool capacity, but that delegation is not reaching the long tail of existing pools. Doubling `k` risks making that long tail even longer, further fragmenting available delegation and making sustainable operation harder for more pools, without addressing why stake remains concentrated.\n\n- Protocol evolution such as Leios will further increase operational demands, while the network has not demonstrated that its decentralization problem is caused by an insufficiently high `k`.\n\n- The historical evidence does not convince me. The previous increase from `k=150` to `k=500` coincided with major changes in ADA price, rapid delegation growth, and IOG block production winding down as Cardano became increasingly decentralized, making it difficult to isolate the effect of `k` itself.\n\n- I would rather address the underlying decentralization and economic problems directly. Sustainable pool economics (`minMargin` 5-10%), effective pledge mechanisms such as CIP-50 or related approaches, pool alliances, and measures addressing inactive and undelegated stake all target the actual problems more directly.\n\n## A note on this Info Action itself\n\nI submitted this Info Action because I wanted a clear assessment of SPO sentiment using the established CIP-1694 SPO voting semantics.\n\nWhen I created the Info Action, the draft material available to me linked the advocacy paper arguing for `k=1000`, but I did not have access to the corresponding detailed paper arguing against it. To preserve neutrality, I could not reasonably reproduce an advocacy section containing only the pro paper, so I omitted that section and instead tried to present the substantive arguments from both perspectives as neutrally as possible.\n\nI only became aware of Neil Davies' detailed case against raising `k` after submitting this Info Action. Having now read it in full, I greatly appreciate the work and analysis that went into it and agree with many of its arguments. Had both the pro and contra advocacy papers been available to me when I created this poll, I would have included both as paired references.\n\nI therefore want to explicitly thank Neil Davies (PNSol) for his work and encourage SPOs and DReps considering this question to read his analysis:\n\nhttps://docs.google.com/document/d/1qwOc91ENr8Vi7Faw1hnWpJaMWxXnYhoX25Sm8bal0l8\n\nFor these reasons, I vote **NO** on raising `stakePoolTargetNum` from 500 to 1000.\n",
    "references": [
      {
        "@type": "Other",
        "label": "The Case for Not Raising stakePoolTargetNum from 500 to 1000 — Neil Davies (PNSol)",
        "uri": "https://docs.google.com/document/d/1qwOc91ENr8Vi7Faw1hnWpJaMWxXnYhoX25Sm8bal0l8"
      }
    ]
  }
}