Cardano’s public Dijkstra testnet has opened to stake pool operators ahead of node 11.2, which will support a planned test-network upgrade to protocol version 12 without Leios.
Summary
- DijkstraNet currently runs node 11.1.3, with the protocol upgrade waiting for the next release.
- A separate MusashiNet prototype includes Leios, while formal node 11.3 development remains unfinished.
- Input Output estimates Leios activation will need voting keys covering roughly 90–95% of stake.
- Constitutional changes, BLS key management and ecosystem risk reviews remain part of upgrade preparations.
Intersect said in its Oct. 22 Upgrade Bulletin #39 that DijkstraNet became publicly available after an Oct. 21 restart, inviting stake pool operators to begin joining before the next node release.
The organization described two parallel testing paths. DijkstraNet will use node 11.2 to test Dijkstra features without Leios, while MusashiNet gives downstream teams early access to a prototype containing the Leios-inclusive feature set.
The bulletin provided no mainnet activation date or required percentage of operators that must upgrade their node software.
Cardano DijkstraNet awaits its protocol version 12 upgrade
Intersect said DijkstraNet currently runs protocol version 11, within the Conway era, using node 11.1.3. Once the node 11.2 pre-release becomes available, a hard-fork initiation action will be submitted to move the network to protocol version 12, known as Dijkstra.
For operators joining now, the bulletin directs participants to configuration files and a testnet faucet through Cardano book. Intersect listed one-day epochs and an available Kleioscan explorer among the network’s testing resources.
Node 11.2 remained in development when the bulletin was published, with a tagged version expected during the week. Intersect described its scope as:
“Includes the full Dijkstra hard fork feature set, apart from Leios”
The release is expected to clear LSM for mainnet use, with memory requirements estimated at approximately 12 GB when using LSM, according to the bulletin. Intersect said it was already working with operators to test LSM and gather feedback.
Cardano previously activated the van Rossem hard fork on July 18, moving mainnet to protocol version 11. The current bulletin concerns preparations on separate test networks, not another completed mainnet upgrade.
Leios testing proceeds separately on MusashiNet
Intersect described the weekly RC 2026w42 pre-release as a Leios-based prototype containing the complete Dijkstra hard-fork feature set. Downstream tooling teams can use it on MusashiNet to explore integrations before the formal node 11.3 release.
For node 11.3 itself, the bulletin said substantial development work remained, and a tagged release was still at least two weeks away. Intersect presented the prototype as an early integration opportunity, without describing it as a finished release.
Input Output’s Oct. 20 rollout plan, previously reported by crypto.news, set initial Leios capacity targets at three to five times Cardano’s current transaction capacity, followed by later targets of 10–15 times.
The developer’s plan separates the hard fork from full Leios operation. Input Output said pools must register BLS voting keys after the fork, with roughly 90–95% of stake registered before Leios can begin operating.
Its proposed sequence then moves through mainnet load exercises and at least two protocol parameter updates, with capacity changes dependent on network results and governance approval. The throughput figures remain targets, not performance delivered by the public opening of DijkstraNet.
Earlier Intersect planning placed Linear Leios in Dijkstra’s first phase and Peras activation in a separate, later hard fork. The two-phase Dijkstra roadmap described its dates as estimates, with testing and governance able to affect the mainnet schedule.
BLS key management remains under discussion
Intersect said developers were considering two ways to handle BLS key registration and rotation without requiring pool owners to participate in those operations.
The existing pool registration certificate mechanism requires signatures from the pool cold key and every pool owner, according to the bulletin. The proposed alternatives are a dedicated BLS key management certificate or permission to update BLS keys in pool parameters without owner signatures.
Intersect identified the second approach as the more likely option for Dijkstra, while noting that a more comprehensive solution could be deferred to the Euler era. The bulletin identified stake pool operators, wallet providers and tooling teams as affected participants.
On upgrade scope, Intersect confirmed that CIP-23 is fully included in Dijkstra. It said several operators had welcomed the development teams’ response to that long-standing request.
The organization reported that the Technical Steering Committee had reviewed an updated Leios impact assessment, which was expected to be merged into the Cardano Upgrades GitBook. Other assessments would follow after outstanding review comments were addressed.
Intersect asked downstream teams to compare the assessments with their own integrations and flag missing dependencies or impacts.
Governance and node diversity work continue
Intersect said the Hard Fork Working Group had completed an initial walkthrough of the Dijkstra risk log. Each risk will receive an owner with editing access, and the log will gain a column for formal risk assessments.
Following discussions between the Parameter Committee and developers, an updated constitutional draft was expected during the week, according to the bulletin.
Intersect scheduled a constitutional update and guardrails meeting for Oct. 23 at 14:00 UTC, open to Constitutional Committee members, stake pool operators, and delegated representatives. The organization said the session would be recorded and shared afterward.
The bulletin listed a separate Node Diversity Workshop organized by the Amaru team for Nov. 12–13 at the London Marriott Hotel Canary Wharf. Its working agenda includes reviewing future hard-fork features through implementation costs and community needs to help inform how subsequent upgrades are scoped and prioritized.
