Cardano Developers Merge Leios Into Core Code, Targeting 3-5x Throughput

Praos2 Lands in the Main Code

The development report the Cardano (ADA) engineering team published on October 23 records a concrete step in the network's throughput redesign: the core code of Leios has been merged into the main development code. The integration centers on Praos2, a construction that pairs the existing consensus method with Leios, together with LeiosNotify and LeiosFetch, the two components that handle information exchange between nodes. One piece of the pipeline is still outstanding: the logic that selects endorser blocks and fetches them for processing. Leios itself is built around a division of labor. Regular block production continues as before, while the transactions inside endorser blocks, the bundles the protocol queues up for validation, are verified and certified separately from ordinary block output. That separation exists because the current consensus layer, Ouroboros Praos, carries a hard constraint: a proof-of-stake design in which blocks must spread across the network quickly, a requirement that caps how much transaction data the chain can move each second. Pulling certification out of the propagation path is how the developers intend to raise that ceiling without changing how blocks reach nodes. The report frames the merge as a development-stage milestone, not a network change. Nothing in the integrated code affects live mainnet behavior, and no activation height or date travels with it. The team's staged plan, laid out in earlier updates, puts the initial throughput goal at three to five times present capacity, with 10 to 15 times possible only after operator participation and mainnet load testing. The testnet track runs separately, as our earlier coverage of the Dijkstranet rollout detailed, so the code merge should not be read as a signal that performance gains are close. What it establishes is that the redesign now compiles, runs and evolves inside the primary codebase, the precondition for every later step.

A 4.5KB Ceiling, Then Dijkstra

Input Output's roadmap, published on October 20, supplies the numbers behind those targets. It puts the present throughput ceiling at roughly 4.5KB of transaction data per second. Converted on the same basis, the initial three-to-five-times goal lands at about 13.5KB to 22.5KB per second. The roadmap is explicit that this figure measures data volume, not transactions per second; the actual count of transactions a second depends on their size and on the computation each one requires. Delivery runs through the next hard fork, the Dijkstra upgrade, and the plan pairs Leios with it. The roadmap also states plainly that the fork alone will not lift capacity to target. Operators running staking pools must first register BLS keys, the cryptographic credentials needed to certify endorser blocks. Only once registered stake reaches roughly 90% to 95% can the network run high-load tests on mainnet. Those tests will measure how fast blocks and certification data actually propagate, and their results form the basis for deciding whether capacity rises further. Delegators weighing operator selection can consult our guide on how to choose a Cardano (ADA) staking pool. Reaching the 10-to-15-times range requires at least two further protocol parameter changes, and each one faces three approval thresholds at once: 67% of delegated representative voting stake, 51% of staking pool operator stake, and two-thirds of the constitutional committee. The roadmap adds that each proposal must rest on the mainnet test results of the preceding capacity stage. The testnet transition follows its own sequence: an Intersect update on October 9 described node 11.2 placing Dijkstra features without Leios on the public testnet, with node 11.3 then combining linear Leios.

Code Is Merged, Votes Decide Capacity

The distinction that matters now is between written code and unlocked capacity. The merge answers whether Leios can be built into the codebase; it does not move a single throughput number on mainnet. Everything between the two runs through procedures no developer can shortcut: BLS registration climbing to the 90% to 95% range, load tests whose propagation measurements justify each step, then parameter votes needing 67% delegated representative support, 51% operator support and a two-thirds committee majority. The initial three-to-five-times gain rides with Dijkstra and is the nearer deliverable. The 10-to-15-times figure is the number the roadmap advertises, and it stays hostage to votes that cannot convene until earlier stages test cleanly on mainnet.