Cardano is moving toward the Dijkstra era, one of the next major stages in the evolution of the Cardano protocol.
For many community members, terms such as Dijkstra, Leios, Node 11.2, DijkstraNet, or Protocol Version 12 can make the upgrade process sound more complicated than it needs to be.
So, I wanted to put together a simple overview of what Dijkstra is, how the upgrade is progressing, and where we are today.
What is the Dijkstra era?
Dijkstra is a major evolution of the Cardano protocol that brings a new set of capabilities to the network.
Among the features associated with this era are:
- Plutus V4
- Nested Transactions
- CIP-50
- Leios
- Additional protocol parameters and other improvements
But Dijkstra is not a single event that happens overnight.
It is better understood as a process of development, testing, validation and gradual rollout.
The network needs to move through several stages before the eventual hard fork to protocol version 12.
The node upgrade journey
The process is progressing through several node releases:
Node 11.1.1
The focus is on removing the legacy tracing system and addressing Genesis fixes.
Node 11.2
This is an important testing milestone. The broader Dijkstra feature set becomes available for testing, with Leios being handled separately through its dedicated testing environment.
Node 11.3
This is planned as the hard-fork release candidate, containing the full Dijkstra feature set, including Leios.
Node 12.0
This will be the canonical node for protocol version 12.
Each release is therefore another step toward the eventual upgrade rather than the hard fork itself.
Two important testnets
One of the easiest ways to understand the current testing phase is to distinguish between MusashiNet and DijkstraNet.
MusashiNet: testing Leios
MusashiNet is focused on testing Ouroboros Leios, particularly its consensus and block-production aspects.
It is already live, and SPOs can participate in the testing.
For SPOs interested in getting involved, the Leios testing documentation provides the starting point:
DijkstraNet: testing the broader Dijkstra feature set
DijkstraNet will focus on the wider set of Dijkstra features.
This includes areas such as:
- Plutus V4
- Nested Transactions
- CIP-50
- New protocol parameters
- Other Dijkstra functionality
The public DijkstraNet is expected to launch alongside Node 11.2.
So, a simple way to remember the distinction is:
MusashiNet → Leios testing
DijkstraNet → broader Dijkstra testing
Both contribute to preparing the ecosystem for the eventual protocol upgrade.
Why does the process take several stages?
A major protocol upgrade is not simply:
New code → hard fork.
There is a lot that needs to happen in between.
The ecosystem needs time to:
Test → identify issues → improve → adapt → validate → prepare
This involves more than the core protocol developers.
SPOs, node operators, ecosystem developers, application builders and other participants all need opportunities to test the new environment and understand how the changes affect them.
This staged approach gives the ecosystem time to prepare before the network transitions to the new protocol version.
Dijkstra is also a governance matter
The Dijkstra era is not purely a technical upgrade.
Peras, for example, is one of the Dijkstra features carrying a constitutional footprint. This means that parts of the upgrade also have a governance dimension, and DReps will have a role to play in the decisions ahead.
For governance participants, therefore, understanding the technical roadmap is important because some of these changes will eventually intersect with Cardano’s governance processes.
Where are we now?
At this point, we are still in the testing and preparation phase.
The current roadmap is broadly:
11.2 → broader Dijkstra testing
↓
11.3 → hard-fork release candidate
↓
12.0 → protocol version 12
The exact hard-fork date is not fixed yet. The current planning windows published in the latest Intersect weekly update are:
December 5, 2026 → January 4, 2027
Moderate-confidence window
February 24 → March 26, 2027
Higher-confidence window
These should be understood as planning windows, not a fixed hard-fork date. The technical delivery plan can continue to evolve as development and testing progress.
What can the community do now?
The most important thing is to understand what is coming and prepare early.
For SPOs and node operators, this means following the testnets and testing the new releases when they become available.
For developers and ecosystem teams, it means assessing how the new features and protocol changes may affect applications and tooling.
For governance participants, it means keeping an eye on the constitutional and governance elements connected to the upgrade.
And for the wider community, simply understanding the process makes it easier to follow the discussions as Dijkstra progresses.
Dijkstra is a process, not a moment
The most important thing I would like people to take away is this: Dijkstra is a process, not a moment.
There are multiple releases, testing environments, ecosystem preparations and governance considerations that all come together before the final hard fork.
Test → validate → prepare → release candidate → hard fork.
I hope this helped make the Dijkstra era a little easier to understand.
The latest Intersect Weekly Update provides the full technical and ecosystem context for the current roadmap.
Link to the update : Intersect weekly update #127 Sep 5, 2026
