Key points
- Leios arrives with Dijkstra. The next Cardano hard fork carries Leios alongside nested transactions, account enhancements, guard scripts, Plutus V4, and freely withdrawable staking rewards.
- The path, step by step. A constitution update, the hard fork, BLS key registration by SPOs, high-load exercises on mainnet, then throughput raised through protocol parameter updates.
- The dial turns one notch at a time. Leios starts conservatively and grows through at least two parameter updates, each backed by what mainnet showed us in the step before.
- SPOs get a new key. Right after the fork, pools register a BLS key they use to vote. Leios needs roughly 90 to 95% of the stake registered before it switches on.
- First 3 to 5 times, then 10 to 15. Leios aims to start at roughly 3 to 5 times today's 4.5 TxkB/s ceiling, and the next parameter updates aim for around 10 to 15 times. Beyond that, demand, community needs, and economics set the pace.
Ouroboros Leios is planned to arrive with Dijkstra, Cardano's next hard fork. But the hard fork is the beginning of the rollout, not the point when Cardano suddenly runs at full Leios capacity. Stake pool operators (SPOs) will first register new BLS voting keys. Once enough stake has registered, Leios can begin using endorser blocks. Capacity will then increase in stages, subject to mainnet results and governance approval.
The initial target is roughly 3 to 5 times the current Praos ceiling of 4.5 kilobytes of transactions per second (TxkB/s). At least two later protocol parameter updates aim to bring that to around 10 to 15 times today's throughput. Any increases after that will depend on demand, what builders need, and the economics of running the network.
Dijkstra also includes nested transactions, account enhancements, guard scripts, Plutus V4, freely withdrawable staking rewards, and a new pledge-leverage parameter. Those changes come with the hard fork. They do not depend on Leios reaching its later throughput targets.
The rollout in five steps
- Constitution update. Add entries and guardrails for the new Dijkstra protocol parameters so governance can change them after the fork.
- Dijkstra hard fork. Upgrade Cardano to the new protocol rules, including Leios and the other Dijkstra features.
- BLS key registration. SPOs register the keys needed to vote on Leios endorser blocks. Leios begins operating once the registered stake reaches a sufficient level.
- Mainnet load exercises. Run planned traffic bursts to measure how quickly endorser blocks and votes travel through the live network.
- Throughput increases. Use at least two parameter updates, backed by mainnet evidence and governance votes, to raise capacity.
These are different milestones. The hard fork makes the protocol available. BLS key registration makes Leios voting possible. The later parameter updates change how much work Leios is allowed to handle. Those capacity changes do not require another hard fork.
Why Praos has a throughput ceiling
Cardano currently uses Ouroboros Praos. On average, a stake pool wins the right to make a block about every 20 seconds. For Praos to work within its proven security assumptions, a new block needs to reach the rest of the network before the next one is likely to be made. Mainnet allows about five seconds for that delivery.
Two pools can occasionally produce blocks a few seconds apart. That creates a short fork at the chain tip, and the chain selection rule resolves it as nodes converge on one branch. The five-second delivery budget helps keep those forks rare and short. If blocks regularly arrived late, more honest blocks would end up on abandoned branches. Chain growth would slow, and transactions would take longer to settle with the same level of confidence.
Because blocks need to travel within that budget, they cannot grow indefinitely. The result is a mainnet transaction throughput ceiling of about 4.5 TxkB/s. Praos can handle ordinary demand, but a busy launch, an airdrop or a market move can fill the queue. Changing Praos parameters alone can only raise the ceiling so far.
There is a second problem when demand spikes. A Praos node's mempool holds roughly two blocks' worth of transactions. Once it fills, it stops accepting new ones. Wallets must retry submissions until there is space. That waiting happens before a transaction enters the mempool, so block inclusion measurements do not capture the whole delay people experience.
What Leios changes
Ranking blocks and endorser blocks
Leios keeps Praos ranking blocks. They are the blocks Cardano uses today, with a few additional header fields. When pending transactions exceed what a ranking block can carry, the producer can announce an endorser block in that header.
An endorser block contains an ordered list of transaction references, not the transactions themselves. Nodes fetch the list, check which transactions they already hold in their mempools, and download the missing ones. A node forwards the endorser block to its peers once it has all of its transactions.
Voting and certification
At the start of each epoch, the largest pools by stake take seats on a voting committee for that epoch. CIP-164 discusses a committee of about 900 seats, representing roughly 99% of active stake. Members wait briefly so the network can detect a producer that has announced two different blocks for the same slot. They then validate the endorser block. Members that find every transaction valid sign a vote using their BLS key.
Once votes representing at least 75% of all active stake have arrived, the signatures can be combined into a certificate. It contains one aggregated signature and a record of the signers, totaling only a couple of hundred bytes. A later ranking block includes that certificate instead of its own transactions, and the endorser block's transactions enter the ledger.
Timing matters. The certificate can only be included once the endorser block has had enough time to reach the network. CIP-164 works through a value of about 14 seconds. If the next ranking block arrives too soon, the endorser block is dropped. That ranking block carries transactions directly, just as a Praos block does, and any waiting transactions can be included later. The design expects this fallback for roughly half of ranking blocks.
The 75% certification threshold requires a large share of active stake to receive and validate an endorser block. That is part of how Leios can add transaction capacity while leaving ranking blocks on Praos timing and preserving the security guarantees Praos provides today. When traffic is light, the protocol does not announce endorser blocks, so operating costs stay close to Praos levels.
What transaction timing looks like
Leios keeps Cardano's sequential transaction processing. Transactions are applied in a deterministic order, so the ordering assumptions used by smart contracts remain in place. A transaction that fits directly in a ranking block can be included as quickly as it is today. Transactions handled through an endorser block reach the ledger in roughly 45 to 60 seconds.
That timing is only part of the user experience. People start waiting when they press submit, not when a node finally accepts their transaction. Leios expands mempool capacity along with block capacity. CIP-164 specifies room for at least two ranking blocks plus two endorser blocks' worth of transactions.
That larger queue is intended to reduce rejected submissions during a spike. A transaction might still wait before inclusion, but it can be held by the network instead of repeatedly resubmitted by a wallet. When traffic is above what Praos can process, higher throughput can reduce the time from initial submission to inclusion even when an individual endorser block takes longer than a direct ranking block.
Why higher capacity matters for SPOs
Transaction fees will matter more as Cardano's Reserve declines. More than 85% of epoch rewards currently come from the Reserve, and that contribution shrinks every epoch. CIP-164 estimates that fee income would need sustained traffic of about 50 to 70 TxkB/s to reach break-even, which is more than ten times the throughput Praos can support today.
Leios creates a route to that level of activity. It does not create demand by itself, so further capacity increases will also depend on what the network is actually being used for.
Why capacity increases in stages
The Leios testnet, MusashiNet, has provided extensive testing. Mainnet introduces conditions a testnet cannot fully reproduce: around 2,700 registered pools, spread across continents and running different hardware, software configurations and connections, with real value at stake.
Leios is therefore planned to begin with conservative protocol settings. The main controls include how many transactions an endorser block can reference and how much Plutus work it can contain. Governance can raise or lower those limits through protocol parameter updates without another hard fork, as long as the changes remain inside the constitutional guardrails.
After Leios is active, the team plans controlled high-load exercises on mainnet. The results will show how endorser blocks move through the live network, how quickly committee votes return, whether certificates form reliably, and how much headroom nodes retain. The first capacity increase will depend on that evidence. The next increase will use results from the higher-load settings.
SPOs will see the load rise gradually rather than all at once. Builders can plan around announced capacity increases, while governance retains the ability to approve or reject each one.
The governance roadmap
| Step | What happens | Delegate representatives (DReps) | Stake pool operators (SPOs) | Constitutional Committee |
|---|---|---|---|---|
| Constitution update | Adds guardrails for new Dijkstra parameters | 75% of stake | No vote | 2/3 of members |
| Hard fork | Moves Cardano to Dijkstra, including Leios | 60% of stake | 51% of stake | 2/3 of members |
| BLS key registration | Pools register Leios voting keys; activation follows sufficient registration | No vote | Every pool registers its key | No vote |
| Mainnet load exercises | Scheduled high-load bursts test live diffusion and voting | No vote | No vote | No vote |
| Throughput increases (at least two) | Raises Leios limits through parameter changes | 67% of stake | 51% of stake | 2/3 of members |
Where a vote is not required, the relevant work is operational rather than a separate governance action.
1. Constitution update
Before governance can change a protocol parameter, the Constitution needs to name that parameter and define the safe range for future changes. Dijkstra brings new parameters, including those that control Leios throughput. Each needs an entry and guardrails.
The plan is to submit the constitutional update before the hard fork. That way, once Dijkstra is on mainnet, the first throughput increase can be proposed as soon as testing provides enough evidence. The Intersect Parameters Committee develops the guardrails, the Plutus team updates the guardrails script, and the proposal is submitted on-chain.
Approval requires DReps representing 75% of stake and two-thirds of the Constitutional Committee. DReps should review the draft during consultation, question any limits they disagree with, and vote when the action is submitted.
2. Dijkstra hard fork
The hard fork is the coordinated network upgrade. Nodes adopt the new rules at the same epoch boundary after the community approves the change on-chain. Since Plomin, Cardano hard forks require that community governance vote.
Leios is one part of Dijkstra. The release also includes:
- Nested transactions: one transaction can contain others. This supports atomic swaps without a decentralized exchange (DEX) contract, fees paid in tokens other than ada, and DApps that cover users' fees.
- Account enhancements: ada can be sent directly to an account address, allowing wallets and batchers to charge a fraction of today's 1 ada floor.
- Guard scripts: shared checks can run once per transaction, rather than being paid for repeatedly by DApps.
- Plutus V4: the smart contract upgrade that makes these capabilities available to developers.
- Freely withdrawable staking rewards: ada holders can withdraw rewards whenever they choose, and DRep delegation becomes a separate deliberate choice.
- Pledge leverage: a new parameter connects a pool's rewards to how much its operator pledges.
The hard fork requires DReps representing 60% of stake, SPOs representing 51% of stake, and two-thirds of the Constitutional Committee. SPOs must upgrade to a Dijkstra-ready node and vote. Exchanges, wallets, SDK maintainers, indexers, and DApp teams should test against the release on public testnets. DReps vote on the upgrade.
3. BLS key registration
SPOs already operate a VRF key and a KES key. Leios introduces a BLS key for voting on endorser blocks. BLS signatures can be combined into one aggregated signature, which keeps committee certificates compact even when hundreds of pools have voted.
After the hard fork, each SPO generates a BLS key and submits an updated pool registration certificate containing the key and proof that the operator controls the matching secret. The key becomes active at the next epoch boundary. Pools will rotate these keys periodically, on roughly the same quarterly schedule as KES keys. SPOs on MusashiNet are already following this process.
A Leios certificate needs votes from 75% of all active stake. Pools without a BLS key can still produce Praos blocks, but they cannot vote on Leios endorser blocks. To account for pools that are offline or slow to vote, registration needs to be comfortably above 75%. The current estimate is roughly 90 to 95% of delegated stake, corresponding to about the top 500 to 900 pools. The exact activation requirement depends on protocol parameters that are still being finalized.
There is no separate DRep or Constitutional Committee vote for BLS registration. SPOs should register their keys as soon as the fork has taken place. Delegators can ask their pool whether its key is registered.
4. Mainnet load exercises
Once enough stake has registered BLS keys, Leios can operate when the transaction backlog is too large for a ranking block. The team also plans scheduled bursts of high transaction traffic so the protocol can be observed under partially controlled conditions. The bursts will push traffic beyond ranking-block capacity and trigger endorser blocks, committee votes, and certificates.
The main measurements are the time it takes an endorser block to spread across mainnet and the time it takes votes from hundreds of pools to return. Both must fit comfortably inside the protocol's timing limits. The exercises will also show whether certificates form reliably and whether nodes retain enough headroom. This evidence will be used to decide whether the first capacity increase is appropriate.
These exercises do not themselves require DRep, SPO or Constitutional Committee votes.
5. Throughput increases
Leios starts with settings targeting around 3 to 5 times today's throughput. If the load exercises confirm that endorser blocks and votes propagate with enough time to spare, at least two parameter updates are planned to raise throughput toward 10 to 15 times the Praos ceiling. Each proposal should include measurements taken at the preceding capacity level.
Each increase is a governance action and must stay within the already ratified guardrails. It requires support from DReps representing 67% of stake, SPOs representing 51% of stake, and two-thirds of the Constitutional Committee. DReps and SPOs should review the evidence attached to each proposal before voting. Builders should follow the approved limits when planning launches.
Beyond those first increases, further changes will depend on demand, community priorities and economic conditions. Governance can increase capacity when the evidence supports it, or hold it where it is.
What to do next
For SPOs, the immediate preparation is to run a Dijkstra-ready node, participate in the hard fork vote, and register a BLS key after the upgrade. DReps will have the constitutional update, hard fork, and later parameter changes to assess. Wallets, exchanges, SDKs, indexers, and DApp teams should test the Dijkstra release on public testnets and track the capacity that governance actually approves.
Leios is approaching mainnet in stages. The protocol comes with the hard fork, BLS registration enables voting, and mainnet results will determine when capacity can rise.
