Cardano Unveils Two-Stage Hard Fork Roadmap for Scaling and Consensus Upgrades

The dates are targets for code development and mainnet preparation, not confirmed activation dates: Preview and Pre-production testing remains ahead, and decentralized governance bodies must approve the changes. For a validator or liquid-staking portfolio, the key signal is execution readiness—not the headline timeline.

Two sequential forks

Phase one would take Cardano to protocol version 12 and install Ouroboros Linear Leios. The Cryptonomist describes a scaling mechanism that adds Endorser Blocks capable of referencing additional transactions and receiving certification from stake-based committees, while retaining the existing Praos security model. The update also includes Nested Transactions and Script Context within PlutusV4, alongside new transaction and block serialization structures.

Those structures are not incidental additions. They establish the ledger foundations, codec extensions, and parameters that Peras will need later, even though Peras itself will not be activated in phase one. The second stage, targeted for Q2 2027, is therefore a separate intra-era hard fork rather than an optional alternative.

Peras adds a voting mechanism that allows stake pool operator committees to vote on recent chain tips. Its stated purpose is to speed transaction confirmation beyond standard Praos chain-depth rules. That dependency matters for model construction: the Q4 2026 code target and the Q2 2027 Peras target should not be treated as one catalyst, because the second stage depends on delivery from the first.

The three execution gates

The roadmap has at least three separate gates before either upgrade reaches the live chain:

• Testing: Cardano still has to complete testing on the Preview and Pre-production networks. Development targets alone do not establish compatibility across the new protocol structures.
• Governance: Delegated Representatives, stake pool operators, and the Constitutional Committee must participate in the approval process. The report says Input Output is preparing a narrow constitutional amendment to add the specific Dijkstra parameters and permitted ranges to the Constitution’s guardrails, with submission targeted for September 11, 2026.
• Client readiness: Amaru, an open-source node implementation written in Rust, is already relay-capable. Mainnet block production is targeted for November 2026, while its development tracker lists a general block-producer release around September 30, a Dijkstra-compatible milestone in late October, and a Leios-compatible release by late November. Those are development checkpoints, not confirmed activation dates.

For operators, the distinction is critical. A relay-capable client or a completed code milestone is not the same as an approved, deployed protocol change. Each milestone answers a different underwriting question: can the software work, can governance authorize it, and can the client ecosystem support it.

Underwrite the outcome, not the calendar

The disciplined approach is to model the roadmap in states rather than as a single event. Keep the base case tied to current, observable protocol conditions, then add separate scenarios for phase-one deployment and Peras activation. Intended improvements to performance, scalability, and transaction finality belong in the upside case, not in current cash-flow estimates.

Any execution-adjusted ROI should keep two figures separate: the value of a benefit if the upgrade becomes operational, and the probability of reaching that state after testing, governance, and client-readiness checks. Until those gates are cleared, the roadmap date is not itself a yield input. If the projected benefit has no execution evidence, it has no defensible place in a yield projection. That is a more reliable underwriting of Cardano than capitalizing an ambitious calendar as a deployed upgrade.