Cardano Leios Targets Three to Five Times Current Capacity

Input Output outlined plans on October 20 to introduce Ouroboros Leios through Cardano’s Dijkstra hard fork. The protocol would initially target three to five times today’s transaction data capacity, with later parameter updates aiming for ten to fifteen times the current level. Activation would follow stake pool registration after the fork.

Leios Adds Capacity During Cardano Traffic Spikes

Ouroboros Linear Leios is designed to process more transactions when demand exceeds the capacity of existing Praos blocks. It retains those blocks and adds endorser blocks containing references to additional transactions.

The protocol also expands the mempool, where nodes hold transactions awaiting processing. This gives the network more room to accept pending transactions during busy periods.

Capacity is measured in kilobytes of transaction data per second. The number of transactions processed depends on their size and computational requirements.

Stake Pools Must Register Leios Voting Keys

After Dijkstra, stake pool operators will register BLS keys to participate in Leios voting. Input Output estimates that activation will require registered pools representing roughly 90% to 95% of delegated ADA, subject to final protocol parameters.

Under the described configuration, participating pools validate endorser blocks and cast votes weighted by the ADA they represent. Certification requires votes covering at least 75% of total active stake. BLS signatures combine those votes into a compact certificate.

Pools without registered keys can continue producing Praos blocks but cannot vote on Leios endorser blocks.

[NEWSBREAK]

Mainnet Tests Will Guide Further Leios Increases

MusashiNet’s 41-day Earth phase reached a peak of 26.8 kilobytes of transaction data per second, compared with a Praos mainnet ceiling of approximately 4.51. The test involved synthetic traffic and participating operators. The team reported fixes for implementation faults uncovered during testing, including synchronization problems and invalid-certificate handling.

After mainnet activation, controlled traffic bursts will measure block propagation, voting performance, certificate reliability, and spare node capacity.

At least two subsequent parameter updates are planned, each requiring separate governance approval within constitutional limits. These changes would not require another hard fork. The October 20 announcement did not specify a Dijkstra activation date.

Each capacity proposal would need measurements from the preceding operating level, giving governance evidence on whether the live network can support the additional load before approving a higher limit.