Cardano Dijkstra Roadmap Ties Leios Throughput to Fee Economics

Cardano has published a two-phase Dijkstra hard fork roadmap that targets code completion for Linear Leios and related features by Q4 2026, then Ouroboros Peras activation in Q2 2027. The dates are readiness estimates, not mainnet guarantees, and every step still needs on-chain governance.

Intersect’s planning materials split the work so a full ledger era lands first, with Peras switched on later through an intra-era protocol bump. The quieter stakes sit underneath the TPS talk: higher sustained volume is meant to let transaction fees replace a shrinking Reserve for stake-pool rewards, while an alternative Rust node and a constitutional parameter update try to reduce single-client and single-path risk.

The Two-Phase Dijkstra Calendar

The Dijkstra era is named for computer scientist Edsger Dijkstra and continues Cardano’s research-first upgrade style. Phase 1 creates the new Dijkstra ledger era at protocol version 12. Phase 2 stays inside that era and only flips consensus rules that were already prepared.

Each phase follows the same path: Preview testnet, Pre-production, then mainnet. DReps, stake pool operators, and the Constitutional Committee must ratify a Hard Fork Initiation action under CIP-1694 before any mainnet cutover. The official Dijkstra upgrade overview states flatly that all quarters are estimates for code completion and benchmarked releases; governance windows and SPO testing will push actual enactment later.

Intersect’s mid-August weekly update said the agreed scope and target dates remain unchanged while work shifts toward ecosystem readiness and alternative node support. The van Rossem hard fork already moved mainnet to protocol version 11 in July and cleared some technical runway.

How Linear Leios Uses Idle Node Capacity

Linear Leios is the headline of Phase 1. It is a partial delivery of the broader Leios throughput research, chosen because fuller designs still carried user-experience and complexity risks the dApp ecosystem was not ready to absorb.

It keeps Ouroboros Praos security guarantees and works with two block types instead of the original three-block research design.

• Ranking Blocks are ordinary Praos blocks extended with optional fields that announce and later certify Endorser Blocks.
• Endorser Blocks are larger supplementary blocks that hold references to extra transactions, not the full transaction bodies themselves.
• A stake-based committee certifies an Endorser Block with a 75% active-stake quorum; a later Ranking Block includes the certificate so the endorsed transactions enter the ledger.

Transactions still move through the mempool. When a producer wins a slot it can announce an Endorser Block in the Ranking Block header. Peers fetch missing transactions over new node-to-node protocols. If no certified Endorser Block is ready, the Ranking Block simply carries transactions the old way. The design aims to put idle bandwidth and CPU already sitting on today’s nodes to work, lifting throughput without larger base blocks or faster slots.

The Ouroboros Linear Leios CIP-164 frames the upgrade as a response to CPS-18 on greater transaction throughput. Secondary analyses of the research cluster published targets roughly in the 10x to 65x range under different conditions, often expressed as 140 to 300+ TxkB/s of data throughput, with throughput then raised gradually through parameter updates after activation. Those figures remain design and simulation targets until mainnet measurement.

Leios also matters for the treasury math. Higher sustained volume is supposed to let fees take a larger share of rewards as the Reserve declines, supporting pool profitability without endless inflation.

Peras Turns Settlement Into Minutes

Phase 2 activates Ouroboros Peras. The codec extensions and protocol parameters ship in Phase 1 so the second hard fork does not need another full ledger era package.

Peras adds a voting overlay on top of Praos chain selection. Committees of stake pool operators vote on recent tips. Once a tip gathers enough votes it is treated as settled far sooner than ordinary Praos depth would allow. Blocks themselves are still produced the same way; only the point of practical irreversibility moves earlier.

According to the project’s own materials, realistic parameter settings can identify settled versus rolled-back blocks after as little as about two minutes with high probability, while Praos-like safety remains when adversaries control more than roughly a quarter of stake. Voting rounds can be on the order of a minute or two. If a quorum fails, the protocol enters a cooldown and behaves like plain Praos until the chain heals.

Peras snapshot

• ~2 minutes, target high-confidence settlement window under realistic parameters
• ~14 kB/s, estimated extra network traffic for SPOs, roughly a few dollars a month at cloud prices
• ~50 kB, approximate size of a Peras certificate when one must be recorded
• No fee change, Peras does not alter transaction pricing; it only speeds settlement certainty

The Peras settlement FAQ details stress benefits for exchanges, bridges, partner chains, and DeFi interfaces that currently wait many confirmations. Centralized exchanges that today demand 15 to 30 confirmations could, in principle, lower those thresholds once certified blocks are routine. Peras does not raise the number of transactions per block; that job belongs to Leios.

What Else Ships in Protocol Version 12

Phase 1 is more than Leios. Nested Transactions (CIP-118) let a parent transaction carry child transactions with their own witnesses and execution contexts. Observe/Guard scripts (CIP-112), account-address groundwork (CIP-159), removal of the isValid field, non-segregated block-body serialization, a PlutusV4 script context, reference-script pricing as true parameters, and several other cleanups ride along.

Pledge leverage-based rewards (CIP-50) arrive with a default of “Nothing,” so behavior stays identical until DReps later vote a concrete leverage value. Fair Min Fees (CIP-23) may activate with Phase 1 or wait for a later intra-era fork. Structural Peras codec work is mandatory in Phase 1 because block structure changes require a new era.

The phased Dijkstra hard fork planning page lists CIPs that were considered and cut for capacity or readiness reasons, including producer identification and some Plutus builtins. Full Leios variants that would need deeper ledger changes are deferred toward a later Euler-era path.

Amaru and the Multi-Client Push

While most headlines stop at Leios and Peras, Intersect is also tracking alternative node clients. Amaru, an open-source Rust implementation, already runs as a relay, validates blocks, and syncs to tip. Mainnet block production is targeted for November 2026, with intermediate Dijkstra-compatible and Leios-compatible milestones in the preceding weeks.

Node diversity reduces reliance on the long-dominant Haskell stack. Intersect has invited alternative node teams into the Hard Fork Working Group and is building readiness trackers for testnet performance. On X, Cardano researcher and risk analyst Dr. Cuadrado framed Amaru as the under-watched piece: less single-implementation dependence, stronger resilience, and a sturdier base for scaling, while many eyes stay locked on the ADA price chart.

That framing fits the recent on-chain picture as well. A recent Cardano active address surge arrived even as ADA traded near multi-year lows, a reminder that usage and price do not always move together.

Fees Must Replace the Reserve

Linear Leios documentation is explicit about economics. Throughput gains are not only for user experience. They are meant to keep stake pools profitable once fees must carry more of the reward load that the Reserve has historically subsidized.

If sustained throughput stays low, fee income stays thin and pressure on pool margins rises. If Leios succeeds in filling idle capacity, the same security budget can be funded by real activity. Nested transactions and richer Plutus context also aim to make more complex dApp logic practical on mainnet rather than forced onto side systems.

Charles Hoskinson has separately pushed Hoskinson’s AI agents framing for Cardano as part of the longer product story. Dijkstra does not deliver those agents, but faster finality and higher base throughput are the substrate those applications would need if they are to settle on layer one with acceptable user experience.

This is not automatic. Throughput parameters after Leios activation will be raised gradually. SPO hardware and bandwidth costs rise modestly with Peras voting. Community governance still has to accept the parameter ranges and the hard fork actions themselves.

Governance Holds the Final Switch

Dijkstra introduces protocol parameters that cannot be governed unless they appear inside the Constitution’s guardrails. Input Output plans a narrow constitutional amendment that adds the new parameters and allowed ranges without rewriting governance roles or voting thresholds. The target window discussed in mid-August was submission by Epoch 655, beginning around September 11, 2026, with community intake already open through Intersect’s amendment portal.

Only after code is ready, testnets have run, and the constitution can express the new knobs does a mainnet Hard Fork Initiation action make sense. Preview and Pre-production each need their own governance enactments and SPO testing windows of roughly one to two weeks. Mainnet timing after ratification remains TBD.

1. Now through late 2026, complete Phase 1 code, constitution parameter amendment, Preview then Pre-prod Leios forks, Amaru block-producer milestones.
2. End-2026 window, target for Dijkstra-compatible mainnet readiness; actual cutover depends on votes and testing.
3. After Phase 1 live, Peras node work, second testnet cycle, Q2 2027 code target for the intra-era Peras activation.

Cardano’s method has always traded speed of marketing for peer-reviewed incrementalism. Dijkstra keeps that bargain. Linear Leios and Peras would finally give the base chain a clearer answer on throughput and finality. The second-order test is whether fee markets, multi-client nodes, and on-chain governance mature in time to make those gains durable rather than decorative.

The roadmap is public. The switches still belong to the voters.