Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)
190 DReps voted · 48 with a rationale · 1 changed their vote · 4 re-voted unchanged
Open a row to read the rationale.
Changed votes: 1 to abstain, together voting with 258.8K ₳ of voting power.
- Yes10.3M ₳Rationale
Looking forward to hardfork
- Yes9.8M ₳No rationale
- Yes9.5M ₳Rationale
I see no real reason this next major hard fork shouldn't go forward.
- Yes8.9M ₳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/."
- Yes7.7M ₳No rationale
- Yes7.6M ₳Rationale
Voting YES for the Hard Fork
If at least 85% of stake pools by active stake upgrade to the version of the node, I so no reason to block it.
- Yes7.3M ₳No rationale
- Yes6.8M ₳No rationale
- Yes6.7M ₳No rationale
- Yes6.3M ₳No rationale
- Yes5.7M ₳No rationale
- Yes5.7M ₳Rationale
Supporting the upgrade with its improvements.
- Yes5.5M ₳No rationale
- Yes5.5M ₳No rationale
- Yes5.2M ₳No rationale
- Yes5.2M ₳No rationale
- Yes5.1M ₳No rationale
- Yes5.1M ₳No rationale
- Yes4.9M ₳No rationale
- Yes4.6M ₳No rationale
- Yes4.5M ₳No rationale
- Yes4.4M ₳No rationale
- Yes4.2M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" (gov_action1lh2...3cxfjc), pois a atualização para a Versão 11 do Protocolo, por meio do hard fork intra-era “van Rossem”, representa uma evolução técnica relevante para a Cardano. Avaliamos positivamente a introdução de novos primitivos Plutus, a unificação das funções built-in entre Plutus V1, V2 e V3 e o suporte a expressões case em Untyped Plutus Core, pois essas melhorias tendem a ampliar a capacidade dos desenvolvedores, reduzir custos de execução e melhorar o desempenho dos scripts on-chain. Também consideramos que a proposta fortalece a segurança, a previsibilidade e a consistência do ledger ao promover verificações importantes nas regras do próprio ledger, como a unicidade do hash da chave VRF, ajustes nas regras de reference inputs e a promoção da restrição de votação do Comitê Constitucional para uma falha determinística de ledger. Diante dos testes, auditorias, preservação das funcionalidades da Versão 10 e da exigência de prontidão mínima de 85% dos stake pools por stake ativo antes da ratificação, apoiamos o voto "SIM" por entender que a proposta entrega melhorias concretas com risco operacional controlado e benefício claro para o ecossistema Cardano.
[English]
We chose to vote "YES" on this governance action "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" (gov_action1lh2...3cxfjc), because the upgrade to Protocol Version 11, through the intra-era “van Rossem” hard fork, represents a relevant technical evolution for Cardano. We view positively the introduction of new Plutus primitives, the unification of built-in functions across Plutus V1, V2, and V3, and support for case expressions in Untyped Plutus Core, as these improvements are expected to expand developer capabilities, reduce execution costs, and improve the performance of on-chain scripts. We also believe the proposal strengthens the security, predictability, and consistency of the ledger by introducing important checks to ledger rules, such as the uniqueness of the VRF key hash, adjustments to reference input rules, and the promotion of the Constitutional Committee voting restriction to a deterministic ledger failure. Given the testing, audits, preservation of Protocol Version 10 functionality, and the requirement of at least 85% stake pool readiness by active stake before ratification, we support a "YES" vote because the proposal delivers concrete improvements with controlled operational risk and clear benefits for the Cardano ecosystem. - Yes4.2M ₳No rationale
- Yes4M ₳Rationale
I'm excited to see these critical upgrades hit the net and see no reason to vote against it.
- Yes4M ₳No rationale
- Yes3.7M ₳No rationale
- Yes3.5M ₳No rationale
- Yes2.8M ₳No rationale
- Yes2.8M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.7M ₳Rationale
Yes. Plutus性能、ZK対応、ledger整合性を高める重要な基盤アップグレードと判断します。
Yes. This is an important protocol upgrade improving Plutus performance, ZK capability, and ledger consistency.
- Yes2.6M ₳No rationale
- Yes2.5M ₳No rationale
- Yes2.5M ₳No rationale
- Yes2.5M ₳Rationale
Lets goooooo
- Yes2.4M ₳No rationale
- Yes2.4M ₳No rationale
- Yes2.2M ₳No rationale
- Yes2.2M ₳No rationale
- Yes2.2M ₳No rationale
- Yes2.1M ₳Rationale
I am voting YES on the Van Rossem Hard Fork.
This is exactly the kind of core protocol upgrade Cardano should be supporting: technically reviewed, constitutionally appropriate, infrastructure-focused, and designed to improve the long-term capability of the network. Moving to protocol version 11 strengthens Cardano’s smart contract and ledger foundations, introduces important new Plutus primitives, improves developer experience, and supports more advanced applications being built on Cardano.
This is not a speculative treasury request or vague ecosystem initiative. It is a serious protocol upgrade with clear scope, clear technical rationale, and strong alignment with Cardano’s long-term mission as a secure, decentralised, high-assurance blockchain.
Subject to the required hard fork readiness and SPO upgrade thresholds being met, I am a resounding YES.
- Yes1.9M ₳No rationale
- Yes1.8M ₳Rationale
BKIND votes Yes on the protocol-11 hard fork. The upgrade is ready by every measure I can verify myself on-chain: a rising supermajority of block production already signals protocol 11, measured by my own independent indexer and bit-exact verified against db-sync. I judge it on that evidence.
Action: HardForkInitiation fdd468da5cc4ac...344d#0 — upgrade to protocol version 11.0.
I vote Yes because the protocol-11 upgrade is ready by every measure I can verify myself on-chain. I judge this action on that evidence, not on advocacy or authority — consistent with how I registered as a DRep.
I do not take readiness claims on faith. The figures below were produced by my own independent indexer — software that reconstructs chain state from the network genesis and the live Ouroboros node-to-node protocol, decoding raw blocks itself, with no third-party indexer, API, or pre-built dump, and accepting each (slot, hash) only when a quorum of independent relays agrees. I then cross-checked every figure, bit-for-bit, against an independent db-sync instance.
Network readiness. The share of blocks signalling protocol 11 has risen monotonically from 49.9% (epoch 632) to 85.7% in the last complete epoch (638) and 86.7% in the current epoch (639). For all seven completed epochs, my independent indexer and db-sync report identical block counts — zero divergence. A rising supermajority of block production already runs protocol-11-capable software; enacting will not strand the network.
My own pool. BKIND has signalled protocol 11 since 10 May 2026 (epoch 630), on every block it has produced since, with no reverts. I do not ask the network to adopt what I have not already run myself.
Tooling built on protocol 11. Smit Blockchain Operations has built three air-gapped toolkits — SPO Tools, DRep Tools, and Wallet Tools — on the protocol-11 source, and exercised them live on Cardano mainnet (governance votes, DRep registration, delegations, payments). We encountered no issues attributable to the protocol-11 code. Their source and binaries will be released as open source for the community shortly.
On this evidence the upgrade meets my bar — verifiable readiness, not promises.
A constructive note to the protocol developers. Building an independent implementation is the most honest test of how completely a protocol is documented. We hit a meaningful number of edge cases with the same root cause: behaviour that is correct in the reference code but carries no inline documentation — for example SSC proof handling, reward-calculation timing, ledger-state diff APIs, value bounds, and hard-fork-combinator era boundaries. These are documentation gaps, not protocol defects. Because independent verifiability is itself a pillar of decentralisation, better inline documentation lowers the barrier to independent implementations and auditors — and is, in that sense, a decentralisation measure. Developers with questions are welcome to email developmentbkind@gmail.com.
I vote Yes on the protocol-11 hard fork (govActionId fdd468da5cc4ac...344d#0).
- Yes1.8M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.6M ₳Rationale
Voting yes for the van Rossem hard fork. Protocol Version 11 enables new Plutus primitives and ledger enhancements that improve Cardano.
- Yes1.6M ₳No rationale