The question that kept confusing me while studying Cardano was why every upgrade takes so long. The answer is simple: a Cardano upgrade isn’t decided by a team — it’s voted in by the whole network. The van Rossem hard fork (Protocol Version 11), which wrapped up in 2026, is a living example. This post breaks down its voting mechanism: how each of the three parties votes, what each one is responsible for, and how a hard fork runs its full course.

Three bodies, three gates

Cardano’s on-chain governance (CIP-1694, also called Voltaire) has three roles that check each other:

flowchart TB
    A[Hard fork governance action] --> B[Constitutional Committee<br/>one vote per member<br/>rules on constitutionality]
    A --> C[DReps<br/>one Lovelace, one vote<br/>vote on behalf of holders]
    A --> D[SPOs<br/>one Lovelace, one vote<br/>the people running the network]
    B --> E[Hard fork: all three gates]
    C --> E
    D --> E
    E --> F[Auto-enacted at the epoch boundary]

The Constitutional Committee (CC): the constitutionality gate

The CC holds the first gate, and it answers exactly one question: does this proposal violate the Cardano Constitution? Whether a change is technically elegant or cost-effective isn’t its business — it guards the bottom line, judging whether a change would break the chain or cross a basic rule. Each member casts one vote, unweighted by stake, and a proposal passes when it meets the committee’s own threshold. That power is caged too: members can be removed by a no-confidence motion, so a committee that oversteps can be voted out by the very holders it serves.

DReps: voting for people who don’t vote

Most holders don’t have time to study every proposal, so they delegate their voting power to a DRep and let someone they trust do the reading. Weight is one Lovelace, one vote — a DRep’s ballot equals the sum of all stake delegated to them. One detail worth writing down: registered stake that doesn’t vote counts as “No” by default, and unregistered stake counts as “Abstain.” There are also two pre-set options, “Abstain” and “No Confidence,” the latter being a vote against the governance bodies themselves.

SPOs: the people running the network

SPOs are the ones actually running nodes and producing blocks, so they know the network’s condition best and get extra say on security-relevant changes. Their votes are stake-weighted like everyone else’s. For a hard fork there’s a special twist: SPO votes are measured as a percentage of the stake held by all stake pools — what’s being measured is whether the whole network is ready, which has nothing to do with any single interest group nodding it through.

How many gates a hard fork passes

Cardano’s governance has seven action types, from light to heavy. A hard fork is the heaviest and the most special: most changes need two bodies to approve, but a hard fork requires the CC, DReps, and SPOs all to approve.

The thresholds aren’t decided on a whim — they’re protocol parameters set by community vote. For example, a recent “network parameter change” action required 67% of active DRep stake plus 51% of active SPO stake; a hard fork’s bar is only higher.

Here’s the full flow:

flowchart TB
    A[Proposal: hard fork governance action<br/>new node version built and tested] --> B[Node operators upgrade first]
    B --> C[SPOs vote Yes = authorization + readiness signal]
    C --> D[DReps and CC vote too]
    D --> E[All three pass their thresholds → ratified]
    E --> F[Protocol version switches automatically at an epoch boundary]
    F --> G[Network produces blocks under the new rules]

Walking the diagram in words: the new node version is built and tested, then the proposal goes on-chain. Node operators upgrade first, because an SPO voting Yes is both an authorization and a declaration that “my node is ready.” DReps and the CC vote separately; once all three clear their thresholds, the proposal is ratified. At the next epoch boundary the protocol version switches automatically, and the network starts producing blocks under the new rules.

After approval, it happens automatically

This is the part most people miss: once the votes pass, the hard fork executes by itself.

Every governance action is checked at the epoch boundary; if it meets the bar it is “enacted,” and nobody has to flip a switch. At that moment the chain’s protocol version flips and nodes start producing blocks under the new rules. Why can it be automatic? Because the protocol version is itself on-chain state, read by the consensus layer. This is a world away from “the team announced it’s live” — whether an upgrade happens comes down to what the ledger itself recognizes, nothing else.

What actually switches on-chain

At the implementation level, how does this “automatic switch” actually land?

Each Cardano era is a separate ledger implementation, joined by the consensus layer’s hard fork combinator. When the on-chain protocol version advances, the combinator switches from the old era’s implementation to the new one at the epoch boundary — the block-production rules change, but history doesn’t, so the chain stays one continuous line.

A soft fork lets old and new rules coexist; a hard fork is the whole network moving to new rules at the same instant. That’s where the name comes from, and it’s why “upgrade the software first” is a hard requirement — a node that didn’t upgrade falls off the chain the moment the rules change.

Why such a big change stays fault-free

A hard fork rewrites the rules of the whole network, so how does it go smoothly? Spreading out van Rossem’s timeline, what I see is layer after layer of rehearsal.

Cardano runs two testnets with a clear division of labor: Preview for fast iteration, Preprod for the formal dress rehearsal — exactly the official guidance for developers. Preview usually runs the new version at least 4 weeks ahead of mainnet, which gives the whole network a buffer to make its mistakes somewhere harmless first.

Every hard fork has a matching “hard-fork-ready” node release. The team ships a candidate node, runs it through Preview then Preprod, and only then hits mainnet. Van Rossem’s actual rhythm: Preview moved to Protocol Version 11 on May 8, Preprod enacted it on June 10, the mainnet action was submitted June 16, and it completed in July — no step skipped.

The third layer is the cleverest. As noted, SPO votes are counted as a percentage of the stake held by all pools. Pools whose nodes aren’t upgraded simply can’t vote “yes” — short the votes, and the fork doesn’t move. “The whole network is ready” was never a slogan; it’s a number measured by staked votes.

With those three layers, a mainnet hard fork is basically a routine that has already been rehearsed many times over.

The upgrade plan: a release train

Finally, the cadence — it works like a release train. Each major era is split into multiple hard forks, each carrying only a limited set of features instead of one giant change. Van Rossem (Protocol Version 11) was an intra-era hard fork — it doesn’t move the era itself, just paves the way. The actual Dijkstra era is rolling out in three phases: Nested Transactions, Linear Leios, and Peras. Each phase has its own node version, testnet validation, and governance vote; official guidance targets the first two phases for mainnet by the end of 2026.

Splitting a big upgrade into small steps, each running the full process, is how Cardano turns “huge change” into “small slow steps” — no matter how large the overall change, each individual deployment stays incremental and controllable.

Why it’s designed this way: three layers of insurance

Unpacking the “slowness,” every delay is insurance. The first layer is anti-hijacking: three-way checks plus thresholds mean a minority can’t change the protocol — hijacking a hard fork would require capturing both the stake-weighted vote and the constitutional committee. The second is time for the network: a hard fork requires a prior software upgrade, node operators upgrade first, and an SPO voting Yes is both authorization and a declaration of “I’m ready”; without enough nodes ready, the votes won’t add up. The third is traceability: every action and vote is on-chain, so it’s always possible to reconstruct who drove what.

Van Rossem is the live proof: the hard fork action was submitted June 16 and completed in July. Even the name of the hard fork was voted on — the naming Info action got 83.62% DRep support and 4.44 billion ADA. When even a name has to go through a vote, it shows how seriously the process takes itself.

The long-term meaning

A chain that can decide how to upgrade itself is a chain that stays stable for the long run. Voting thresholds and process exist to seal off the path where “a minority rewrites the rules at any moment.” It’s slow, but it’s slow with confidence: every upgrade is the result of the whole network nodding together, never a press release from one team.

Article Link: