The upgrade has not happened yet
Intersect said in its October 24 weekly update that the public testnet was respun on October 21. The next step is a pre-release of node version 11.2, followed by submission of a hard-fork initiation action. Only then will the testnet move to protocol version 12, known as Dijkstra.
That sequence matters because it separates software availability from protocol activation. A node release can be published without a network upgrade taking place. The hard-fork action is the point at which the transition becomes an explicit protocol event.
For operators, that creates a practical test window. They can prepare infrastructure against the current public environment, then validate the changes required for version 12 when the pre-release arrives. Developers and tooling teams can do the same with integrations that depend on node behavior, protocol data or network monitoring.
The testnet therefore represents readiness work, not a throughput result. It does not show that Cardano’s mainnet has become faster. It shows that the ecosystem has a public place to discover whether operators and builders can move through the upgrade process without breaking their systems.
Leios is staged, not switched on at full capacity
The Dijkstra upgrade is important because Cardano presents it as the platform for the first phase of Linear Leios. Cardano’s Leios glossary says the design requires stake pools to register BLS voting keys and will increase throughput through staged parameter changes rather than immediate full activation.
That distinction is central to the numbers attached to the rollout. The initial target is described as roughly three to five times the current Praos ceiling. Later parameter changes could aim for ten to fifteen times current throughput, but those changes would depend on governance-approved guardrails and operational evidence.
The hard fork, in other words, would make the machinery available. It would not automatically deliver the final capacity target on day one. Registration, measurement and parameter changes would come afterward.
That gives the testnet two jobs. The first is conventional compatibility testing. Operators need to determine whether their nodes, deployment processes and monitoring tools behave correctly. The second is more demanding: the network must provide evidence that later Leios settings can be increased without exceeding the system’s operational limits.
A higher theoretical ceiling is useful only if the network can sustain it. The relevant evidence will include how endorser blocks and votes behave under load, whether operators can keep up, and whether the guardrails are conservative enough to prevent a scaling change from becoming a reliability problem.
The friction is the story
The available reporting does not establish how many stake pool operators, tooling teams or application developers have already joined the testnet. It also does not provide participation figures, test results or a schedule for the node 11.2 pre-release. That leaves onboarding as an open question rather than a success metric.
The absence of those figures is not a minor reporting gap. A public testnet can be technically available while seeing limited practical use. The more useful measure will be whether independent operators actually deploy it, whether application teams test against it and whether problems are reported before the hard-fork action is submitted.
SIPO’s account of the rollout welcomed the significance of the testnet but criticised the delayed node 11.2 release, missed delivery expectations and weak participation in a related governance poll. Those are opinions from SIPO, not evidence that the testnet itself has failed. They do, however, identify the coordination problem Dijkstra must solve: a protocol upgrade needs software, operator participation and governance activity to arrive in the same process.
The supplied material contains criticism, but no source offering an opposing view. That means the public record available for this article is weighted toward concerns about delivery and readiness. It does not justify declaring the rollout either successful or troubled before the testnet produces more operational evidence.
Earlier testing leaves a risk checklist
Block Stream Media reported that earlier Leios testing was associated with memory leaks, chain forks, stalled synchronisation and a network halt caused by invalid-certificate handling. The report also said developers had reported fixes.
Those incidents are not proof that the same failures will occur on the Dijkstra testnet. They are a checklist of what the public rehearsal should expose or rule out. Memory use must remain manageable. Nodes must stay on the same chain. Synchronisation must recover cleanly. Certificate validation must not create a halt under adverse conditions.
The next meaningful milestone is therefore not the phrase “three to five times.” It is the arrival of node 11.2, followed by a visible hard-fork test and published evidence from operators and developers. If those steps show stable participation and clean measurements, Dijkstra will look like a credible production rehearsal. If they do not, the upgrade will remain a roadmap promise with a public test environment attached.
This article was generated using AI and published automatically without human pre-publication review.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.