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.
- Yes1.6M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.5M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.3M ₳No rationale
- Yes1.3M ₳No rationale
- Yes1.2M ₳No rationale
- Yes1.2M ₳No rationale
- Yes1.1M ₳No rationale
- Yes1.1M ₳No rationale
- Yes1M ₳No rationale
- Yes988.4K ₳No rationale
- Yes971.5K ₳Rationale
We vote YES on this proposal because the van Rossem hard fork is a sensible and important protocol upgrade for Cardano.
The upgrade improves Plutus performance and capabilities, makes built-in functions more consistent across Plutus versions, adds useful new primitives, and strengthens ledger-level validation and node diagnostics. These are practical improvements that can help developers build more efficient and capable applications on Cardano while keeping the upgrade scope focused and manageable.
We also appreciate that this is an intra-era hard fork, meaning it does not introduce a full era transition and minimizes disruption for the ecosystem. The proposal has gone through technical review, includes clear readiness requirements, and aligns with Cardano’s long-term need for better performance, stronger tooling, and more reliable infrastructure.
For these reasons, we support the upgrade to Protocol Version 11.
- Yes964.1K ₳No rationale
- YesRevoted954K ₳History
Earlier votes
Yes1mo agoSuperseded
- Yes931.8K ₳No rationale
- Yes929.9K ₳No rationale
- Yes923.6K ₳No rationale
- Yes861.5K ₳No rationale
- Yes825.2K ₳Rationale
Voting 'YES' on the "van Rossem" hard fork aligns seamlessly with our core objective of prioritizing user trust, security, scalability, and long-term viability for Cardano. This upgrade does not merely optimize smart contract efficiency and lower execution costs through updated Plutus models; it delivers the foundational architecture necessary to bring high-throughput scaling via Leios. Furthermore, executing this upgrade via Voltaire on-chain governance transitions Cardano into a truly mature, decentralized, self-sustaining network where no single entity can unilaterally alter protocol parameters. The technical risks are well-mitigated by intensive Preview/Preprod testnet cycles and robust node readiness across the global operator community. Supporting this upgrade respects both our rigorous architectural requirements and our commitment to a decentralized future.
- Yes798.4K ₳No rationale
- Yes794.5K ₳No rationale
- Yes776.8K ₳No rationale
- Yes759K ₳No rationale
- Yes747.4K ₳No rationale
- Abstain625.9K ₳Rationale
Voting "Abstain" as a DRep I feel confident in relying on SPOs to understand when to approve a HFC. That being said I'm want to support the action as a recognition of the naming of the Hard Fork as "van Rossem" honoring a great member of our community that we lost this year.
- Yes619.5K ₳No rationale
- Yes605.7K ₳No rationale
- Yes598.3K ₳No rationale
- Yes589.7K ₳Rationale
Yes - to advance the chain. I also appreciate the effort Yuta puts into promoting this and sharing updates with the community.
- YesRevoted587.6K ₳History
Earlier votes
Yes28d agoSuperseded
- Yes533.9K ₳Rationale
Major upgrades to the Plutus Contract language and adds Ledger stability. The fork is named in memory of Cardano governance contributor Max van Rossem, RIP Max, TY for all that you did!
- Yes520.2K ₳No rationale
- Yes479.9K ₳No rationale
- Yes478.4K ₳No rationale
- Yes478.3K ₳No rationale
- Yes466.2K ₳No rationale
- Yes448.2K ₳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 fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#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 fdd468da5cc4ac8431dcd7e2b3211666c73bc229f85879469f67f1d9d51d344d#0).
- Yes442.9K ₳No rationale
- Yes431.7K ₳No rationale
- Yes387.4K ₳No rationale
- Abstain385.2K ₳Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - Yes383K ₳No rationale
- Yes381.1K ₳No rationale
- Yes365.7K ₳No rationale
- Yes360.3K ₳No rationale
- Yes341.4K ₳Rationale
From my perspective as a DRep, treasury funding should be directed toward solutions that are practical, sustainable, and capable of generating long-term value for the ecosystem. Protocol Version 11 provides infrastructure that supports exactly that objective, making it a meaningful investment in Cardano's future.
From my perspective as a DRep, treasury funding should be directed toward solutions that are practical, sustainable, and capable of generating long-term value for the ecosystem. Protocol Version 11 provides infrastructure that supports exactly that objective, making it a meaningful investment in Cardano's future.
- Yes323.2K ₳No rationale