Cardano Node 11.1.1 Lands Ahead of Schedule as Dijkstra Hard Fork Roadmap Takes Shape

Cardano has shipped node version 11.1.1, the first of four planned node milestones on the road to the network’s next major era, the Dijkstra hard fork. The maintenance release, published through Intersect’s container registry over the weekend ending September 6, removes the ledger’s legacy tracing system, addresses known Genesis-related issues, and responds to elevated memory use observed during testing of node 11.1.0.

The release arrived slightly ahead of schedule. Intersect had previously targeted the week beginning September 7 for the package, meaning 11.1.1 landed just ahead of its stated window. It is available in standard, AMD64 and ARM64 builds, a detail that matters for stake pool operators and developers running Cardano infrastructure across varied hardware.

## What 11.1.1 does and does not change

Importantly, node 11.1.1 does not activate the Dijkstra era or introduce the full set of planned ledger features. It is a maintenance and preparation update intended for current mainnet use. The older tracing infrastructure used to monitor node operations is gone, and Cardano’s development reporting indicated the release also tackles higher resident memory use that showed up in 11.1.0 benchmarks.

With the groundwork laid, Intersect has published a more detailed Dijkstra schedule. Node versions 11.2 and 11.3 will follow, and the final protocol version 12 release will progressively introduce the code required for public testing and mainnet activation.

## The road to Dijkstra

Node 11.2 is the next milestone, expected within roughly one month of Intersect’s September 5 update. It will carry most of the Dijkstra feature set for testing, but it will not be the final hard-fork candidate. Leios components will be absent from 11.2 because they primarily concern consensus and block production; developers will still be able to test the remaining Dijkstra ledger and transaction features.

After 11.2 ships, Intersect plans to launch DijkstraNet, a public test network where developers, stake pool operators and tooling providers can exercise the broader protocol version 12 feature set. The expected lineup includes Plutus V4, Nested Transactions and CIP-50 parameters, alongside new script types, address changes, block-body serialization revisions and changes to reward withdrawals tracked in Cardano’s public development repository.

Nested Transactions would allow a single Cardano transaction to contain other transactions while preserving separate validation conditions for each. That structure could support more complex applications, coordinated actions and multi-party workflows without requiring every step to operate as an unrelated transaction. Plutus V4 represents the next version of Cardano’s smart-contract language and execution environment, and its arrival will require wallets, decentralized applications, indexers and developer tools to confirm they interpret the new ledger rules correctly. CIP-50, which concerns pledge leverage and staking rewards, means stake pool operators will need to examine how the new parameters could affect incentives and pool economics before mainnet activation.

DijkstraNet will run alongside MusashiNet rather than replacing it. MusashiNet is already live and concentrates on Leios, consensus and block-production testing. Keeping the two tracks separate lets ledger features and the new consensus architecture progress in parallel, with results eventually converging in the node version selected as the hard-fork candidate.

Node 11.3 is expected within one to two months, according to Intersect’s September 5 update, and is intended to become the Dijkstra hard-fork release candidate. Unlike 11.2, it should contain the full Dijkstra feature set, including Linear Leios, and should be capable of crossing from the current Conway ledger era into Dijkstra during test-network rehearsals.

Linear Leios is the planned first-stage implementation of Ouroboros Leios. It adds parallel transaction-processing structures around the existing Praos consensus design, aiming to raise throughput without changing the security assumptions of Cardano’s base chain. Intersect has stressed that testing must examine more than raw transaction capacity: block propagation, network bandwidth, resource use, synchronization, recovery behavior and performance under adverse conditions all need evaluation.

Node 12.0 will become the definitive protocol version 12 release under the project’s naming convention. Intersect has not assigned it a publication date.

## A timeline with confidence labels, not promises

Intersect currently places a possible Dijkstra enactment between December 5, 2026 and January 4, 2027 under its moderate confidence timeline. A later high confidence window runs from February 24 to March 26, 2027. Both are estimates. Cardano must complete development, public testing, ecosystem preparation and on-chain governance before the hard fork can activate, and Intersect has been explicit that the December-to-January period is not a guaranteed activation date.

Governance is a hard requirement, not a formality. Cardano cannot activate Dijkstra through a software release alone. Some new Dijkstra parameters must first be incorporated into the Cardano Constitution’s guardrails, with Intersect directing participants to monitor its Constitutional Amendment Portal for related proposals. A constitutional change requires approval under Cardano’s governance rules, and a separate hard-fork initiation action must then obtain the required support from delegated representatives, stake pool operators and the Constitutional Committee.

That process has a working precedent. The van Rossem hard fork, activated in July, moved Cardano to protocol version 11 after completing the network’s full on-chain approval process, the first mainnet hard fork enacted entirely under the current governance framework. Van Rossem stayed within the Conway era but added Plutus changes and prepared technical foundations for Dijkstra. The Dijkstra transition will be broader, changing the ledger era while introducing more extensive consensus, transaction and smart-contract capabilities, which is why exchanges, wallets, explorers and decentralized applications must be ready before activation.

Beyond the Haskell client, Amaru, an alternative Cardano node written in Rust, forms another part of the preparation. It can already validate and synchronize with the chain tip, with mainnet block production targeted for November 2026. Node diversity could reduce the network’s reliance on a single Haskell implementation, though it adds another testing requirement: alternative clients must interpret protocol rules consistently.

The plan has two phases. Phase 1 covers the era transition, Nested Transactions and Linear Leios, with mainnet readiness targeted around the end of 2026 subject to testing and governance. Phase 2 will activate Ouroboros Peras through a separate intra-era hard fork in the second quarter of 2027. Peras adds stake-based voting on recent chain tips to accelerate settlement, providing stronger confirmation sooner than chain-depth rules alone.

Intersect is encouraging stake pool operators and developers to join MusashiNet and DijkstraNet testing, and has scheduled node-diversity workshops in Singapore on October 6 and in London on November 13 and 14. The official Dijkstra readiness tracker remains open and marked as work in progress; it will close only when a node exists that can complete the hard fork into a functional Dijkstra era.

Market snapshot at time of writing: BTC 78,995, ETH 2,481.29, SOL 103.79.

Disclaimer: This article is for informational purposes only and does not constitute financial advice.