Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)
432 SPOs voted · 10 with a rationale · 4 re-voted unchanged
Open a row to read the rationale.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
I am voting Yes on this proposal. The van Rossem hard fork (Protocol Version 11) improves Plutus performance and capability (new primitives across CIP-0109/0132/0133/0138/0153, unified built-ins across V1/V2/V3, and native case-expressions), strengthens ledger consistency and node-level security (VRF key hash uniqueness enforced at the ledger level, and the Constitutional Committee voting restriction promoted to a ledger predicate), all as a backward-compatible intra-era upgrade that leaves transaction shape unchanged and introduces no new or deprecated protocol parameters. It is also procedurally well-vetted: recommended by Intersect's Hard Fork Working Group and endorsed by the Technical Steering Committee, with completed security audits, performance reports showing no regressions, and conformance testing across Plutus V1, V2 and V3. The action is consistent with all eight HARDFORK guardrails; the only outstanding condition is HARDFORK-04 (at least 85% of stake by pools upgraded), which the Constitutional Committee and SPOs are expected to verify before ratification. On that basis I am voting Yes.\n\n[Japanese version follows]\n\n本提案に賛成票を投じます。van Rossem ハードフォーク（Protocol Version 11）は、Plutus の性能と機能を向上させ（CIP-0109/0132/0133/0138/0153 の新プリミティブ、V1/V2/V3 でのビルトイン統一、ネイティブな case 式）、台帳の整合性とノードレベルのセキュリティを強化します（VRF 鍵ハッシュの一意性を台帳レベルで強制、Constitutional Committee の投票制限を台帳ルールへ昇格）。これらはすべて後方互換のイントラエラ・アップグレードとして実施され、トランザクション形状は不変で、新規・廃止のプロトコルパラメータもありません。手続面でも十分に検証されており、Intersect の Hard Fork Working Group が推奨し、Technical Steering Committee が承認済みで、セキュリティ監査の完了、リグレッションのない性能レポート、Plutus V1・V2・V3 全体での適合テストが揃っています。本アクションは 8 つの HARDFORK ガードレールすべてに準拠しており、残る条件は HARDFORK-04（アクティブステークの 85% 以上を占めるプールのアップグレード）のみで、これは ratification 前に Constitutional Committee と SPO が検証する見込みです。以上の理由から、私は賛成票を投じます。
- YesRationale
I am voting Yes on this proposal. The van Rossem hard fork (Protocol Version 11) improves Plutus performance and capability (new primitives across CIP-0109/0132/0133/0138/0153, unified built-ins across V1/V2/V3, and native case-expressions), strengthens ledger consistency and node-level security (VRF key hash uniqueness enforced at the ledger level, and the Constitutional Committee voting restriction promoted to a ledger predicate), all as a backward-compatible intra-era upgrade that leaves transaction shape unchanged and introduces no new or deprecated protocol parameters. It is also procedurally well-vetted: recommended by Intersect's Hard Fork Working Group and endorsed by the Technical Steering Committee, with completed security audits, performance reports showing no regressions, and conformance testing across Plutus V1, V2 and V3. The action is consistent with all eight HARDFORK guardrails; the only outstanding condition is HARDFORK-04 (at least 85% of stake by pools upgraded), which the Constitutional Committee and SPOs are expected to verify before ratification. On that basis I am voting Yes.\n\n[Japanese version follows]\n\n本提案に賛成票を投じます。van Rossem ハードフォーク（Protocol Version 11）は、Plutus の性能と機能を向上させ（CIP-0109/0132/0133/0138/0153 の新プリミティブ、V1/V2/V3 でのビルトイン統一、ネイティブな case 式）、台帳の整合性とノードレベルのセキュリティを強化します（VRF 鍵ハッシュの一意性を台帳レベルで強制、Constitutional Committee の投票制限を台帳ルールへ昇格）。これらはすべて後方互換のイントラエラ・アップグレードとして実施され、トランザクション形状は不変で、新規・廃止のプロトコルパラメータもありません。手続面でも十分に検証されており、Intersect の Hard Fork Working Group が推奨し、Technical Steering Committee が承認済みで、セキュリティ監査の完了、リグレッションのない性能レポート、Plutus V1・V2・V3 全体での適合テストが揃っています。本アクションは 8 つの HARDFORK ガードレールすべてに準拠しており、残る条件は HARDFORK-04（アクティブステークの 85% 以上を占めるプールのアップグレード）のみで、これは ratification 前に Constitutional Committee と SPO が検証する見込みです。以上の理由から、私は賛成票を投じます。
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
I vote YES on the hard fork initiation action titled “Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)” (fdd468da5cc4ac...344d#0). This vote is submitted as both SPO and DRep and can be found in the same transaction.
I had wanted to hold off on voting until after the epoch boundary on June 28, 2026, and vote in epoch 640 as it has been my personal preference that this action not ratify on June 28, causing an enactment on July 3. Why? The July 3 epoch boundary lands on a Friday, late for UTC time zones and right before a major US holiday on July 4. Yes, we have had upgrades land close to major holidays before and this is an intra-era upgrade and so should have little-to-no breaking changes. However, given all of the headlines that Cardano has had to contend with recently, I’d much rather see this hard fork ratify on July 3 with an enactment on July 8 when we can guarantee more hands on deck to resolve any potential issues. They say, “don’t push to production on Friday”, it probably should count for hard forks too.
With that said, I do want to vote YES. This hard fork has been many months in the making, with Plutus Cost Model updates and hard fork initiation actions having passed through SanchoNet, Preview and Preprod test networks over the months of April, May and June.
Readiness is now looking strong. 87% of block production for this epoch, at time of writing, has been on node version 11. This satisfies the HARDFORK-04 constitutional guardrail of “At least 85% of stake pools by active stake should have upgraded to a Cardano Blockchain node version that is capable of processing the rules associated with the new protocol version”. This week has also seen massive progress from exchanges, with 77.37% readiness by liquidity being reported.
I have conceded to submitting my vote this epoch as there is a non-zero chance that this ratifies while I am away from my computer later today and the ledger does not care about our individual preferences, therefore this is submitted now to maintain my voting record. My voting weight certainly is not of any size to sway things one way or another, especially as a sub-1M SPO.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale