Cardano’s Dijkstra-era roadmap is holding to its original technical scope, with developers now locking in a staggered rollout: Linear Leios and Nested Transactions in Phase 1 around late 2026, followed by Ouroboros Peras in a separate activation window targeted for Q2 2027. The focus is gradually shifting from pure research and engineering to ecosystem readiness, testnet metrics, and making sure multiple node clients can support the coming changes.
According to the latest planning update from the project’s steering organizations, Dijkstra is now formally split into two distinct phases. Phase 1 will introduce the Dijkstra ledger era itself alongside Linear Leios. The development teams are aiming for code completion in Q4 2026. Phase 2 will then switch on Ouroboros Peras through an intra-era hard fork, with its own internal milestones and a tentative delivery window in the second quarter of 2027. The roadmap stresses that these dates are indicative only and can slide based on testing outcomes and governance decisions.
Linear Leios is the core scaling feature of the first Dijkstra hard fork. Rather than discarding Cardano’s existing Ouroboros Praos consensus, it layers on so-called Endorser Blocks. These additional blocks can reference extra transactions and have them attested by committees formed based on stake distribution. The idea is to significantly raise throughput while keeping the underlying security assumptions of Praos intact, instead of gambling on a completely new consensus design.
Phase 1 is far more than a single scaling feature. It also brings Nested Transactions, updated transaction and block serialization formats, changes to the Plutus smart contract environment via PlutusV4, and a series of new protocol parameters. Crucially, this phase will install the codec extensions and ledger-level parameters that Peras will rely on later, even though Peras itself will remain dormant until Phase 2. In other words, Phase 1 lays the structural foundation; Phase 2 flips the switch.
Much of this work has been enabled by earlier upgrades. The van Rossem hard fork, which pushed mainnet to Protocol Version 11 in July, was specifically designed to prepare the network for Dijkstra and Leios. That upgrade refined core protocol plumbing so that the more ambitious changes in Dijkstra could be slotted in without a complete re-architecture of the chain.
Ouroboros Peras, scheduled for activation in Phase 2, adds a new voting layer on top of standard consensus. Committees composed of stake pool operators will be able to vote on the most recent chain tips, allowing the network to finalize blocks more quickly than the typical chain-depth rules used under pure Praos. This is intended to improve settlement times for users and applications, especially in scenarios where faster confirmation is critical, such as institutional transactions or higher-volume DeFi activity.
The Peras phase has its own dedicated roadmap. Before it reaches mainnet, the protocol must first roll out to dedicated Preview and Pre-production environments, undergo testing under realistic load, and then pass through another on-chain governance action. Phase 1, with all its Dijkstra-era ledger structures and protocol parameters, must already be active by then, since Peras depends on those under-the-hood changes to function correctly.
Dijkstra is also being used as a lever to increase node-client diversity on Cardano. In addition to the long-standing Haskell node, work on Amaru-an open-source Rust-based implementation-is progressing. Amaru is already capable of running as a relay node and can validate and synchronize with the current chain tip. Developers are targeting November 2026 for mainnet block production support, which would mark a major step toward having more than one production-grade implementation of the protocol.
Amaru’s own internal roadmap breaks that target into several milestones. A general-purpose block-producer release is aimed for September 30, followed by a Dijkstra-compatible block producer dated around October 29, and a Leios-compatible version scheduled for delivery around November 26. These are development goals, not promises of live network activation, but they provide a clearer sense of how the Rust implementation will align with Dijkstra’s phases and features.
Diversifying node implementations reduces the ecosystem’s dependence on the reference Haskell client. It also spreads operational risk: if one codebase encounters a critical bug, another implementation could continue operating and support the network. To coordinate this, a Dijkstra readiness tracker is being assembled to monitor testnet performance, tooling integration, and infrastructure upgrades across the broader ecosystem, while bringing alternative node teams into a shared technical discussion around each hard fork.
The governance side of Dijkstra is just as important as the technical upgrades. The era introduces new protocol parameters that, by design, cannot be modified through regular governance unless they are explicitly referenced inside the Constitution’s protective framework. To avoid a future deadlock over these parameters, Input Output has outlined a narrow constitutional amendment that will insert the relevant entries and define the allowable ranges within which they can be changed.
Notably, that amendment is limited in scope. It does not attempt to redefine governance roles, alter voting thresholds, or rewrite the existing constitutional principles. Instead, it focuses on giving governance a clear, legitimate handle on the new technical parameters introduced by Dijkstra, so that the network can be adjusted over time without requiring a full constitutional overhaul every time a tuning is needed.
The working target is to submit this governance action no later than Epoch 655, which begins on September 11. Preparatory discussions and drafting work are already underway through the project’s dedicated governance tooling. Early feedback has produced several initial amendment proposals that will be distilled into a final, more focused change designed specifically around the Dijkstra upgrade.
For now, the near-term roadmap centers on finishing Dijkstra’s Phase 1 code, defining concrete readiness criteria, and then moving those changes through Preview and Pre-production test environments ahead of any mainnet vote. The latest status update confirms that the agreed scope and date targets are still in place, although everyone involved acknowledges that testing outcomes and community sentiment during governance will ultimately influence the real activation dates.
Timing remains the main uncertainty. While the Haskell node team is working toward having Phase 1 ready for mainnet deployment by the end of 2026, the formal plan is more conservative: Q4 2026 is framed as a code-completion milestone, not a guaranteed mainnet activation. After code is frozen, extensive testing, infrastructure upgrades by stake pool operators, wallet and dApp updates, and at least one governance vote still need to occur. Any of these stages could extend the schedule beyond 2026. Peras, in turn, is still anchored to a Q2 2027 goal, but is explicitly contingent on Phase 1 already being live and stable.
From a broader perspective, Dijkstra, Leios, and Peras form a multi-year strategy to upgrade Cardano’s performance without sacrificing its security or decentralization. Linear Leios tackles throughput and block capacity by offloading part of the workload to endorsed blocks and stake-based committees, while Peras attacks the finality problem by overlaying a fast voting layer. Taken together, they seek to bring Cardano closer to a high-throughput, low-latency settlement layer suitable for complex DeFi, real-world asset tokenization, and large-scale consumer applications.
The emphasis on incremental layering rather than disruptive replacement is a deliberate design choice. Cardano’s engineers are effectively saying that the existing Praos foundation is sound, but needs additional components to handle modern demands. This cautious approach stands in contrast to some networks that pivot to entirely new consensus algorithms or architectures when faced with scaling pressure. By building on top of Praos, the team seeks to preserve battle-tested security properties while still evolving the protocol.
For developers and businesses building on Cardano today, the Dijkstra roadmap signals both opportunity and planning requirements. Tools and dApps will need to adapt to new transaction formats, serialization rules, and protocol parameters introduced in Phase 1. Smart contract platforms and off-chain services must be tested against PlutusV4 changes and Leios behavior. At the same time, improved throughput and faster settlement could unlock new use cases that are currently constrained by performance ceilings, particularly for high-frequency trading, gaming, and microtransaction-heavy applications.
Stake pool operators, meanwhile, face a twofold challenge. They must keep pace with both protocol changes and the growing diversity of node software. Testing Amaru and other implementations, preparing for new hard fork combinator events, and evaluating changes to hardware, monitoring, and tooling will all be part of a multi-year operational journey. Still, if successful, this transition could leave Cardano with a more resilient infrastructure layer, less vulnerable to single-client failures or code regressions.
Finally, from a governance standpoint, Dijkstra will act as a real-world exercise in complex, parameter-heavy decision-making under a constitutional framework. The need to explicitly incorporate new parameters into constitutional guardrails shows how closely tied protocol engineering and governance design have become on Cardano. How smoothly these amendments pass-and how effectively the parameters are managed afterward-will shape perceptions of the network’s ability to evolve without internal gridlock.
In summary, Cardano’s Dijkstra roadmap is not just a set of technical upgrades scheduled for 2026-2027. It is a staged transformation that combines scalability (Leios), faster settlement (Peras), client diversity (Amaru and other nodes), and maturing governance under constitutional constraints. The dates remain targets, not promises, but the direction of travel is clear: a more capable, more flexible Cardano that preserves its security foundation while preparing for substantially higher demand in the years ahead.