Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)
190 DReps voted · 47 with a rationale · 5 changed their vote
Open a row to read the rationale.
- Yes584.2M ₳Rationale
Summary
Yoroi DRep votes YES on "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" as a practical and well-managed protocol upgrade that directly benefits developers and the broader ecosystem.Rationale
• Expanded Plutus capabilities for developers.
The new primitives introduced across five CIPs unlock new possibilities for smart contract design and reduce execution costs for patterns that are common in production DApps today. These are targeted improvements with a direct effect on what developers can build and how efficiently they can build it.
• Low disruption by design.
As an intra-era hard fork, this upgrade advances the protocol version without changing the ledger era, keeping the impact on SPOs, tooling, and existing applications to a minimum. Yoroi views this as the right way to deliver protocol improvements at this stage of the network's maturity.Conclusion
The van Rossem hard fork is a clear and well-justified step forward for Cardano's smart contract platform. The scope is targeted, the implementation approach is careful, and the benefits to developers are concrete. On that basis, this proposal has Yoroi's full support. - Yes435.8M ₳Rationale
I vote YES for "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)". This is a useful upgrade. Let's move forward with this.
「Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)」にYESを投票します。これは有用なアップグレードです、先に進みましょう。
- Yes293M ₳Rationale
Summary
EMURGO as a DRep votes YES on the governance action titled "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)", with rationale outlined below.Rationale
The van Rossem hard fork is a well-scoped and low-disruption protocol upgrade that delivers meaningful improvements to Cardano's smart contract layer. The new Plutus primitives introduced across CIP-0109, CIP-0132, CIP-0133, CIP-0138, and CIP-0153 expand what developers can build on Cardano, and making all built-in functions universally available across Plutus versions removes an inconsistency that has added unnecessary friction to the development process.The intra-era nature of this upgrade is also worth noting. Advancing the protocol version without an era transition minimises disruption to SPOs, tooling, and existing applications, which reflects a considered approach to hard fork management. EMURGO views this as a straightforward and timely upgrade that strengthens Cardano's smart contract platform without introducing unnecessary risk. For these reasons, EMURGO votes YES.
- Yes254.7M ₳No rationale
- Yes222.9M ₳Rationale
Eternl Wallet is hard fork ready.
- Yes174.6M ₳No rationale
- Yes165.7M ₳No rationale
- Yes120.2M ₳Rationale
The Cardano Foundation votes YES. We actively participated in the Hardfork Working Group and monitored readiness across exchanges, technical infrastructure, and SPOs. We believe that the ecosystem is sufficiently prepared for this critical protocol upgrade.
A PDF version of this rationale is also made available.
Our decision is driven by the network's ecosystem readiness and the maturity of these refined ledger enhancements. While we acknowledge the ongoing integration of Ogmios, we assess this as a manageable risk given the buffer between ratification and activation.
The Cardano Foundation votes YES. The 'van Rossem' Hard Fork is a well-refined protocol upgrade that brings essential capabilities to the ledger. We commend the collaborative efforts of the Hardfork Working Group and the broader community in ensuring a high standard of technical and operational readiness, and we consider the network prepared for activation.
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - Yes92.2M ₳No rationale
- Yes91.5M ₳Rationale
As a DRep, I voted YES for the proposal: Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)
I vote YES on the van Rossem hard fork, provided the 85% SPO readiness requirement is verified before ratification.
It improves Plutus performance and capability, expands built-in availability across Plutus versions, introduces useful new primitives, and strengthens ledger correctness and node diagnostics.
The proposal presents testing, audit, conformance, and performance evidence, and the upgrade keeps Cardano in the Conway era with unchanged transaction shape, minimizing ecosystem disruption.
I vote YES on the technical merit of the van Rossem hard fork, but I will continue to monitor SPO readiness before the end of the voting period. If the 85% active-stake readiness threshold is not confirmed, I am prepared to change my vote, because the action should not proceed unless HARDFORK-04 is satisfied.
If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp - Yes86M ₳Rationale
SIPO votes YES on the Hard Fork to Protocol Version 11 (the 'van Rossem' Hard Fork), as both a DRep and a stake pool operator.
Governance Action ID: gov_action1lh2x3kjucjkggvwu6l3txggkvmrnhs3flpv8j35lvlcan4gax3xsq3cxfjc
Governance Action Tx (CIP-105): fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#0
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-06-20This governance action upgrades Cardano mainnet to Protocol Version 11 through the intra-era "van Rossem" hard fork — Major Version 11, Minor Version 0, with no era transition; the ledger remains in the Conway era. The upgrade enables the new Plutus primitives defined in CIP-0109, CIP-0132, CIP-0133, CIP-0138, and CIP-0153; makes all Plutus built-in functions available consistently across Plutus V1, V2, and V3, expanding the capabilities of V1 and V2 scripts; and adds case-expressions for built-in types (Bool, Integer, Data) in Untyped Plutus Core for significant performance improvements and cleaner script logic.
SIPO votes Yes because this hard fork is the activation of a path SIPO has already endorsed. SIPO voted Yes on naming the van Rossem hard fork, and Yes on the Update Plutus Cost Models parameter change that prices the very primitives this upgrade switches on — a change that has since been enacted. Without this hard fork, those benchmarked, already-approved cost settings have nothing to apply to. The new primitives — multi-scalar multiplication over BLS12-381 and modular exponentiation among them — are the on-chain cryptographic foundations for the zero-knowledge and post-quantum work SIPO has supported this cycle through the Cardano Vision 2026 research programme and the Scalus application platform. Approving this hard fork is the consistent next step.
The risk profile is contained: this is an intra-era hard fork with no era transition, following the same upgrade path as the Plomin (Protocol Version 10) hard fork, with the cost models benchmarked through Intersect's published process and already enacted. As a stake pool operator, SIPO is a direct participant in the upgrade and casts its pool votes accordingly, alongside this DRep vote. SIPO notes that at the time of this vote no DRep and no stake pool has voted No — the headline "No" percentages reflect not-yet-voted and abstaining stake in the denominator, not opposition — and SIPO encourages other DReps and SPOs to participate so the upgrade can be ratified and its activation epoch scheduled.
SIPO votes Yes. This is SIPO DRep's recorded position, and SIPO casts the corresponding stake-pool votes for the pools it operates.
SIPO は、本ガバナンスアクション「Hard Fork to Protocol Version 11（van Rossem ハードフォーク）」に、DRep として、またステークプールオペレーターとして、賛成（YES）を投じます。
Governance Action ID: gov_action1lh2x3kjucjkggvwu6l3txggkvmrnhs3flpv8j35lvlcan4gax3xsq3cxfjc
Governance Action Tx (CIP-105): fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#0
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-06-20本ガバナンスアクションは、intra-era の「van Rossem」ハードフォークによって Cardano メインネットを Protocol Version 11 へアップグレードするものです（Major Version 11・Minor Version 0・era 遷移なし。台帳は Conway era のまま）。このアップグレードにより、CIP-0109・CIP-0132・CIP-0133・CIP-0138・CIP-0153 で定義された新しい Plutus プリミティブが有効になり、すべての Plutus 組込関数が Plutus V1・V2・V3 で一貫して利用可能になり（V1・V2 スクリプトの能力拡張）、Untyped Plutus Core において組込型（Bool・Integer・Data）の case 式が追加され、性能の大幅な改善とよりクリーンなスクリプトロジックが実現します。
SIPO が賛成するのは、本ハードフォークが SIPO の既に支持してきた道筋の「有効化」だからです。SIPO は van Rossem ハードフォークの命名に賛成し、本アップグレードが有効化するまさにそのプリミティブの単価を定める「Update Plutus Cost Models」パラメータ変更にも賛成しました ― そして後者は既に enact されています。本ハードフォークがなければ、ベンチマーク済みで既に承認されたそれらの単価設定は、適用される対象を持ちません。新プリミティブ ― BLS12-381 上の multi-scalar multiplication やべき剰余など ― は、SIPO が今期 Cardano Vision 2026 研究プログラムと Scalus アプリケーション基盤を通じて支持してきた、ゼロ知識・ポスト量子の作業のオンチェーン暗号基盤です。本ハードフォークの承認は、その一貫した次の一歩です。
リスクプロファイルは限定的です。これは era 遷移を伴わない intra-era ハードフォークであり、Plomin（Protocol Version 10）ハードフォークと同じアップグレード経路をたどり、cost model は Intersect の公開プロセスでベンチマークされ既に enact されています。ステークプールオペレーターである SIPO はこのアップグレードの直接の当事者であり、この DRep 投票と並んで、運用するプールの票を相応に投じます。なお本投票の時点で、No を投じた DRep も SPO も 1 件も存在しません ― 表示される「No」の割合は、未投票および abstain のステークが分母に乗っているもので、反対ではありません ― SIPO は他の DRep・SPO の参加を促し、アップグレードが批准され activation epoch が確定することを望みます。
SIPO は賛成を投じます。本投票は SIPO DRep の記録上の立場表明であり、SIPO は運用する各プールについても相応の SPO 票を投じます。
- Yes84.3M ₳Rationale
Yes to progress!
- Yes77.7M ₳No rationale
- YesRevoted76.8M ₳History
Earlier votes
Yes16d agoSuperseded
Yes1mo agoSuperseded
- Yes75.2M ₳No rationale
- Yes74.5M ₳Rationale
I vote Yes on this proposal.
I believe Protocol Version 11 represents a meaningful and beneficial upgrade for Cardano, improving Plutus capabilities, ledger consistency, and node-level security while maintaining a conservative and well-tested approach.
The introduction of new Plutus primitives, the unification of built-in functionality across Plutus V1, V2, and V3, and the addition of native case expressions are significant improvements that enhance smart contract performance and expand what developers can build on Cardano.
I also view the ledger enhancements positively. Strengthening VRF key uniqueness, improving validation rules, and promoting important governance restrictions to ledger-level enforcement contribute to a more secure, predictable, and robust network.
The proposal is supported by technical reviews, testing, performance analysis, and security assessments. Furthermore, it aligns with the constitutional hard fork guardrails and appropriately requires sufficient network readiness before ratification.
Cardano's long-term success depends on continuous and responsible protocol improvement. In my view, Protocol Version 11 delivers meaningful technical value while maintaining network stability and security.
For these reasons, I vote Yes.
僕は本提案に賛成します。
Protocol Version 11 は、Plutus の機能拡張、レジャーの整合性向上、ノードレベルのセキュリティ強化を実現する重要なアップグレードであり、Cardano の長期的な発展にとって有益であると考えています。
特に、新しい Plutus プリミティブの追加、Plutus V1・V2・V3 間でのビルトイン関数の統一、case-expression の導入は、スマートコントラクトの性能向上や開発者体験の改善につながる重要な前進です。また、VRFキーの一意性保証やレジャールールの改善は、ネットワークの安全性と一貫性をさらに高めるものと評価しています。
本提案は十分な技術的検証、性能評価、セキュリティレビューが行われており、Cardano憲法に定められたハードフォーク・ガードレールにも適合しています。加えて、ハードフォーク前に十分なノードアップグレード率を求めている点も、ネットワークの安定性を重視する姿勢として適切だと考えます。
Cardanoは継続的な改善を通じて進化していくプロトコルです。本提案はその進化を支える堅実な技術アップグレードであり、エコシステム全体に利益をもたらすものと判断しました。
以上の理由から、僕は本提案に賛成票を投じます。
- Yes73.1M ₳Rationale
I am formally registering a YES vote on the Protocol Version 11 (van Rossem) Hard Fork on behalf of my delegates.
Technically, this intra-era upgrade delivers a massive leap in Plutus performance by unifying built-ins, adding native case expressions, and unlocking ZK-SNARK capabilities.
A PDF version of this rationale is also made available.
I am formally registering a YES vote on the Protocol Version 11 (van Rossem) Hard Fork on behalf of my delegates.
Technically, this intra-era upgrade delivers a massive leap in Plutus performance by unifying built-ins, adding native case expressions, and unlocking ZK-SNARK capabilities, drastically reducing script execution costs. Beyond the vital technical improvements, naming this hard fork after Max van Rossem is a beautiful, permanent tribute to a pioneer who shaped our governance and community and whose contributions will always be remembered and valued. I fully support this essential upgrade.
- Yes69.4M ₳No rationale
- Yes62.7M ₳No rationale
- Yes53.8M ₳No rationale
- Yes50.4M ₳Rationale
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 が検証する見込みです。以上の理由から、私は賛成票を投じます。
- Yes50M ₳Rationale
The 'van Rossem' Hard Fork is an important milestone in Cardano's development, and I would like to see it on mainnet.
- Yes49.5M ₳No rationale
- Yes47.6M ₳No rationale
- Yes40.1M ₳No rationale
- Yes38.1M ₳Rationale
- Yes36.9M ₳No rationale
- Yes34.6M ₳No rationale
- Yes33.5M ₳Rationale
Yes. Intra-era hard fork to Protocol Version 11 (van Rossem): new Plutus primitives, unified built-ins across V1/V2/V3, UPLC case-expressions, plus ledger hardening (VRF key uniqueness, CC vote rule as a ledger predicate). No treasury spend, gated on 85% SPO readiness.
A PDF version of this rationale is also made available.
Vote: Yes
This is the van Rossem intra-era hard fork to Protocol Version 11. It bundles a focused set of Plutus performance and capability gains, ledger-consistency hardening, and node-level security fixes into a single coordinated upgrade, with no treasury spend and no change to transaction shape. The Cardano First framework reads as a clean Yes, led by Scalability.
HOSKY already supported naming this fork, voting Yes on the van Rossem naming action. This vote is the technical follow-through.
Pillar Analysis
Scalability (lead pillar)
This is the heart of the upgrade and the reason it earns a Yes. The new primitives attack real, named bottlenecks rather than adding surface area for its own sake: a constant-time
Arraytype replacesO(n)list indexing,dropListunlocks efficient redeemer-indexing, a nativeValuetype removes the generic-map overhead that sits under most contracts, andcase-expressions in UPLC let the interpreter dispatch onDatatags directly instead of chainedif/equalsInteger/unConstrDatapatterns. Each of those is a direct execution-cost reduction. BLS12-381 multi-scalar multiplication and on-chain modular exponentiation make pairing-based zero-knowledge proofs practical on Cardano instead of offloaded off-chain. Because the fork is intra-era, all of this lands without forcing a transaction-format migration on the ecosystem.Adoption
Unifying the built-in set across Plutus V1, V2, and V3 is the quiet win here. Historically new functionality was reachable only by recompiling to the latest Plutus version; after van Rossem, existing V1 and V2 scripts gain the full built-in set in place. That lowers the upgrade tax on every contract already deployed, and the expanded cryptographic primitives open a class of applications (ZK, advanced DeFi) that were impractical before. More capability for builders at lower cost is the adoption mechanic.
Decentralization
Two things cut toward decentralization. First, VRF key hash uniqueness is promoted to a ledger predicate, so no two stake pools can register or operate with the same VRF key, closing an SPO-level attack vector at the protocol layer. Second, the activation gate itself is decentralized: HARDFORK-04 requires 85% of stake by active stake to be on a capable node before ratification, which puts SPOs, not any single entity, in control of when the fork goes live.
Governance Transparency
Promoting the Constitutional Committee voting restriction from a mempool-only check to a ledger predicate is a governance-correctness improvement. Where an offending vote could previously only be rejected at the mempool layer, it now produces a deterministic on-chain failure that every participant observes identically regardless of submission path. The clearer non-matching-withdrawals predicate and the detailed
PPViewmismatch reporting are smaller transparency and diagnosability gains in the same direction.Economic Sustainability
A hard fork carries no treasury withdrawal and the proposal deposit is refundable, so the direct cost to the ecosystem is zero. The lasting effect is the opposite of a cost: cheaper script execution across the board lowers on-chain operating cost for every DApp that uses the new primitives. This is protocol improvement that pays for itself in reduced fees and execution units.
Risks I'm Accepting With This Yes
SPO readiness gate
The fork should only ratify once at least 85% of stake by active stake is on a PV11-capable node (HARDFORK-04). If readiness is short at ratification time, activating anyway would risk a disorderly upgrade. I am accepting this because the gate is explicit, the Constitutional Committee and SPOs verify it, and Intersect's Hard Fork Working Group publishes the readiness reports the verification rests on. The correct behaviour if the threshold is not met is simply not to ratify, and that is built into the action.
Irreversibility
Protocol Version 11 is a permanent change to on-chain ledger rules, and reversion is only possible through the CIP-0135 disaster-recovery process in extreme circumstances. I am accepting this because the testing posture is strong: reports show no behavioural regressions, complete spec-to-implementation conformance on the new ledger rules, security audits on the BLS primitives and on execution costs, and a published performance report showing no regression against PV10. The companion cost-model action is also a live safety valve, the new primitives can be disabled at the cost-model level if a problem appears post-fork.
Companion cost-model dependency
The new Plutus primitives only become usable once the companion cost-model parameter action is enacted, so this fork and that action are coupled in practice. I am accepting this because the coupling is deliberate and protective: separating primitive availability from primitive cost gives governance a clean lever to switch the primitives off without reverting the fork itself.
Bottom Line
Real execution-cost reductions and new cryptographic capability for builders, ledger and SPO-security hardening, deterministic governance rules, zero treasury cost, and a decentralized SPO-gated activation backed by clean testing and audits. Yes.
- Yes31.4M ₳No rationale
- Yes31.1M ₳No rationale
- Yes30.7M ₳No rationale
- Yes27.9M ₳Rationale
The testing has been completed and the ecosystem is ready. Send it.
- Yes27.9M ₳No rationale
- Yes27.5M ₳No rationale
- Yes26.3M ₳No rationale
- Yes26.1M ₳No rationale
- Yes23.5M ₳Rationale
Let's forking go
- Yes21.5M ₳No rationale
- Yes21.5M ₳Rationale
I vote YES on the hard fork initiation action titled “Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)” (fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#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.
- Yes20.4M ₳No rationale
- Yes20.3M ₳No rationale
- Yes19.9M ₳Rationale
I say yes to this intra-era hardfork.
- Yes17.4M ₳No rationale
- Yes17.3M ₳Rationale
I think we should move forward with this hard fork. Thanks to all the teams involved.
- Yes16.7M ₳No rationale
- Yes16.4M ₳Rationale
Vote: YES
This governance action initiates a hard fork to Protocol Version 11, named the 'van Rossem' hard fork in honour of Max van Rossem, a Cardano community member, developer, SPO, DRep, and Constitutional Convention delegate who passed away in 2025. The upgrade is an intra-era hard fork — no new ledger era, no treasury withdrawal, no ADA requested. It delivers five new Plutus CIPs: CIP-138 (Array type), CIP-153 (MaryEraValue type), CIP-109 (modular exponentiation), CIP-132 (dropList), and CIP-133 (multi-scalar multiplication over BLS12-381). The action was submitted by the Intersect Hard Fork Working Group in June 2026 and requires ratification by DReps, the Constitutional Committee, and SPOs, with an activation threshold requiring 85% of active block-producing stake to run compatible nodes before the fork executes.
Vampyre Fund votes YES.
This is foundational protocol infrastructure in its purest form. The five new Plutus primitives materially expand what builders can accomplish on-chain: modular exponentiation and BLS12-381 multi-scalar multiplication are prerequisites for practical zero-knowledge proof systems; the Array and dropList builtins improve execution efficiency and reduce script costs; MaryEraValue optimises multi-asset handling. These are not features that generate marketing impressions over a single event cycle — they are the substrate on which the next generation of Cardano applications will be built. Vampyre Fund exists to support exactly this kind of work.
The governance structure of this hard fork merits specific recognition. This is the first hard fork in Cardano's history to be initiated through the Voltaire on-chain governance framework rather than by IOG acting unilaterally. The 85% SPO node-readiness threshold before activation is a meaningful safety mechanism — it prevents chain fragmentation and ensures the upgrade executes only when the network is genuinely prepared. Preview testnet forked successfully on May 8, 2026. DRep ratification reached 68.57% of active stake. The Constitutional Committee provided 5-of-7 sign-off. These are the governance processes Cardano has been building toward, and they are working as designed.
Vampyre Fund casts this YES vote also as an SPO. The VAMP stake pool has upgraded to the required node version and voted YES in the SPO track. We encourage all remaining SPOs who have not yet upgraded to do so. The 85% threshold exists to protect the network; crossing it promptly benefits every participant in the ecosystem.
- Yes14.3M ₳No rationale
- Yes13.3M ₳Rationale
RCADA votes YES on the van Rossem Hard Fork — Protocol Version 11.0.
This is a focused intra-era upgrade that strengthens Plutus capabilities, ledger consistency, node diagnostics, and stake-pool security while keeping Cardano in the Conway era and preserving the existing transaction shape.
RCADA supports the upgrade because it delivers practical improvements for builders and operators. The new Plutus primitives, unified built-in availability across Plutus V1, V2, and V3, and native case expressions should improve script performance, reduce execution costs, and expand what developers can build on Cardano. The ledger changes also improve consistency and correctness through stronger VRF key-hash rules, revised reference-input handling, deterministic Constitutional Committee voting restrictions, clearer withdrawal validation, and improved protocol-parameter mismatch reporting.
This action is also consistent with RCADA’s earlier support for the companion Plutus Cost Models update. That action provides the cost-model entries required to activate the new primitives safely across the supported Plutus versions. Supporting the hard fork therefore completes a coordinated set of upgrades rather than approving an isolated change.
RCADA is voting from both a DRep and stake-pool operator perspective. As an SPO, RCADA has already upgraded its Mainnet infrastructure to a Protocol Version 11-compatible node and has also participated in the corresponding Preview and Preprod testnet upgrades. That operational experience gives us additional confidence that the upgrade path is manageable and that the changes have been exercised across the expected testing environments.
The most important constitutional condition remains HARDFORK-04. At least 85% of stake pools by active stake should be running a compatible node version before ratification. RCADA’s support does not replace that network-wide readiness requirement. The Constitutional Committee and the relevant readiness reporting process should verify that the threshold has been met before enactment proceeds.
RCADA also recognises that a hard fork is a permanent ledger-rule change and cannot be treated casually. The reported testing, security review, conformance work, performance checks, Hard Fork Working Group recommendation, and Technical Steering Committee endorsement are therefore important parts of our support.
For these reasons, RCADA votes YES. The van Rossem hard fork is a technically focused and strategically useful upgrade that improves Cardano’s smart-contract platform, ledger correctness, node operation, and long-term developer capabilities, provided the required SPO readiness threshold is confirmed before ratification.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- Yes12.1M ₳No rationale