Skip to main content
Chile Stake Po [CHIL]

Blog

Leios reaches mainnet: the path with Dijkstra

Redacción CardumenRedacción CardumenCardano

Musashi samurai with his two swords (tachi and kodachi) stepping out of a dojo toward the dawn. Illustration for the ChileStakePo Leios series.

# Leios reaches mainnet: the path with Dijkstra

In August we told you what Ouroboros Leios is and why it is Cardano’s bet for scaling. We ended with an honest caveat: back then Leios lived on a testnet, not on mainnet, and there was no date.

Today there is a path. On October 20, 2026, Input Output (IOG) published how Leios will reach mainnet: alongside the next hard fork, Dijkstra. The promise is big: multiply Cardano’s throughput without touching its security. But the first thing to understand is that it is not a switch. It is a path in stages, with governance votes at every step. In this installment we explain what is coming and what performance improvement it brings.

What Dijkstra is

Dijkstra is the name of Cardano’s next hard fork. A hard fork updates the protocol rules: all nodes move to the new version and, from that point, the network operates under different rules.

Dijkstra brings Leios, but it does not come alone. The same package includes:

  • Nested transactions (CIP-0118): transactions that can contain others (atomic swaps without a DEX and fees paid in other tokens).
  • Account enhancements: sending ada directly to an account address, allowing a fraction of today’s 1 ada floor to be charged.
  • Guard scripts: shared checks that run once per transaction, instead of being paid for separately by each DApp.
  • Plutus V4: the smart contract upgrade that enables these capabilities.
  • Freely withdrawable staking rewards: withdraw your rewards whenever you want, and delegating to a DRep becomes a separate decision.
  • Pledge leverage: a parameter that connects a pool’s rewards to how much its operator pledges.

These changes arrive with the fork and do not depend on Leios reaching its throughput targets. Leios is one piece of the package, not the whole package.

The path in five steps

IOG describes the rollout in five milestones, and the order matters:

  1. Constitution update. Guardrails are added for the new Dijkstra parameters, so governance can change them after the fork.
  2. Dijkstra hard fork. Cardano moves to the new rules, including Leios.
  3. BLS key registration. Stake pool operators (SPOs) register the keys they will use to vote on endorser blocks.
  4. Mainnet load exercises. Planned traffic bursts to measure how endorser blocks and votes travel through the real network.
  5. Throughput increases. At least two parameter updates, backed by mainnet evidence and governance votes.
Official IOG diagram of the path of Leios to mainnet: constitution update, Dijkstra hard fork, BLS key registration, load exercises and throughput increases.
The path of Leios to mainnet in five stages. Image: Input Output (IOG).

The key is the distinction: the hard fork makes the protocol available; BLS registration makes voting possible; and the parameter updates decide how much work Leios is allowed to handle. That capacity increase does not require another hard fork.

Why Praos has a ceiling

To understand what changes, you have to understand why Cardano has a limit today.

Cardano currently uses Ouroboros Praos. On average, a pool wins the right to produce a block every 20 seconds. For Praos to work within its proven security assumptions, each new block must reach the rest of the network before the next one is likely to be produced. Mainnet allows about 5 seconds for that delivery.

Because blocks must travel within that budget, they cannot grow indefinitely. The result is a throughput ceiling of about 4.5 TxkB/s (kilobytes of transactions per second). Praos handles ordinary demand, but a busy launch, an airdrop or a market move can fill the queue. And adjusting Praos parameters alone can only raise the ceiling so far.

There is a second problem during spikes: a Praos node’s mempool holds about two blocks’ worth of transactions. When it fills, it stops accepting new ones, and wallets must retry until there is space. That waiting happens before a transaction enters the mempool, so inclusion measurements do not capture the real delay people feel.

What Leios changes

Leios keeps Praos blocks (it calls them ranking blocks) and adds a second piece: endorser blocks.

When pending transactions exceed what a ranking block can carry, the producer can announce an endorser block. An endorser block does not contain the transactions: it contains an ordered list of references to transactions. Nodes fetch that list, see which transactions they already hold in their mempool, and download the missing ones.

Then comes the voting. At the start of each epoch, the largest pools by stake take seats on a voting committee (CIP-164 discusses about 900 seats, representing ~99% of active stake). The committee validates the endorser block and, if every transaction is valid, signs a vote with its BLS key.

Once votes representing at least 75% of active stake arrive, the signatures combine into a certificate of a few hundred bytes. A later ranking block includes that certificate, and the endorser block’s transactions enter the ledger.

Beyond the blocks, Leios expands the mempool. CIP-164 reserves room for at least two ranking blocks plus two endorser blocks. That larger queue means that, during a spike, the transaction waits inside the network instead of the wallet having to retry the submission over and over. And when traffic exceeds what Praos can process, the higher throughput shortens the time between submission and inclusion.

On timing: a transaction that fits directly in a ranking block is included as quickly as today. One that goes through an endorser block reaches the ledger in about 45 to 60 seconds.

The increase in stages, not all at once

Leios starts with conservative parameters and grows in stages. The initial target is about 3 to 5 times the current 4.5 TxkB/s ceiling — that is, between 13.5 and 22.5 TxkB/s. At least two later parameter updates aim for about 10 to 15 times — between 45 and 67.5 TxkB/s. For network users, that means more transactions per block, faster confirmations and fees that stay low regardless of demand. Beyond that, demand, what builders need and the economics of running the network set the pace.

Why in stages? Because mainnet has conditions a testnet cannot reproduce: around 2,700 registered pools, spread across continents, running different hardware, software and connections, with real value at stake. MusashiNet (Leios’s testnet) tested a lot, but not everything.

There is also an economic reason. Today more than 85% of epoch rewards come from the Reserve, and that contribution shrinks every epoch. Over time, fees will matter more, and CIP-164 estimates that sustained traffic of about 50 to 70 TxkB/s would be needed to cover costs from fees alone. Leios opens a route to that level of activity, though it does not create demand by itself.

Each increase is voted by governance: the delegated representatives (DReps) with 67% of stake, the SPOs with 51%, and the Constitutional Committee with 2/3. The fork itself requires 60% of DReps and 51% of SPOs.

What you can do to prepare

  • If you run a pool: run a Dijkstra-ready node, participate in the hard fork vote and register your BLS key after the upgrade.
  • If you are a DRep: you will evaluate the constitution update, the hard fork and each parameter increase.
  • If you build (wallets, exchanges, SDKs, indexers, dApps): test the Dijkstra release on public testnets and follow the capacity that governance actually approves.

Sources

Etiquetas: , , ,