db-sync

CardanoScope Research

Leios Primer: What Cardano's Throughput Upgrade Is, and What May's Progress Review Actually Showed

ada · analysis · 2026-06-24

cardano leios ouroboros scaling musashi-dojo dijkstra governance testnet

Cardano's Leios scaling protocol has a public testnet now. It went live June 23 under the name Musashi Dojo（武蔵道場）, and the project's own monthly contributor call happens to land today, June 24 — good timing to explain what Leios actually is, in plain terms, and recap what the team had already reported as of its last review, on May 27, before this testnet existed.

The branding is worth a look on its own: the official site (leios.cardano-scaling.org) opens with a samurai-themed hero banner — a tribute, in the project's own words, "to Cardano's Japanese community and to the philosophy of Miyamoto Musashi." It's genuinely well done. Go look at it yourself rather than take my word for it.

What problem is Leios actually solving?

Cardano today produces one block roughly every 20 seconds, and each block has a hard size limit. Think of it like a single mail truck doing rounds on a fixed schedule, with a fixed amount of cargo space — if more letters show up than the truck can carry, they have to wait for the next round. That's the bottleneck: Cardano's current throughput tops out around 4.5 KB of data per second, network-wide.

Leios doesn't replace the mail truck (that's Ouroboros Praos, Cardano's existing consensus engine — Leios runs *alongside* it, not instead of it). It adds a second, much bigger truck that only shows up when there's a backlog of mail:

  • When demand is high, a randomly-selected participant can also build an endorser block (EB) — a much larger batch of transactions, separate from the regular block.
  • Other stake pool operators check that EB and vote on it. Think of this like several different post offices independently confirming "yes, I've seen this batch, it's legitimate."
  • Once enough votes (weighted by how much ADA each voter represents) pile up, the EB is "certified" — and that certificate, not the bulky EB itself, is what actually gets written into the permanent chain record to count those extra transactions.

The target is to take Cardano from ~4.5 KB/s up toward roughly 200 KB/s — IOG describes this as 30-65x today's throughput — without changing how secure the chain is.

Why a testnet now, and what's still pending

This work is being paid for through Cardano's on-chain voting system, where ADA holders' delegated representatives (DReps) decide whether to fund proposals. The Leios team reported 88% support for the proposal funding this phase of work, according to their own May 27 review call; separate news coverage of Leios governance more broadly cites over 84% support — these may refer to different specific votes taken at different times, not the same number reported twice, but either way the message is the same: this has strong backing.

Two more pieces of the puzzle worth knowing:

  • A smaller, separate upgrade called the "van Rossem" hard fork (named after a Cardano community member who passed away in October 2025) is moving through governance right now. It doesn't turn Leios on — it just tidies up some underlying protocol plumbing so the bigger upgrade has a cleaner foundation to build on.
  • The next *major* era after that is called Dijkstra (named after computer scientist Edsger Dijkstra) — and Dijkstra is the era that's actually meant to carry Leios to Cardano's mainnet. IOG's roadmap currently points to a mainnet hard fork by late 2026.

The testnet's five planned phases — Earth, Water, Fire, Wind, Void — are named after the chapters of Musashi's *Book of Five Rings*, and walk from basic protocol checks, up through deliberately throwing attacks at it, toward "ready for mainnet."

What the May 27 review actually covered

This section runs long on purpose — it's the most recent full checkpoint before today's call, and several of the unsolved problems below are exactly what a public testnet now has to prove it can survive.

1. A live demo of the voting mechanism, with one big caveat:

  • The team ran a real three-node network live on the call. An EB got announced, reached the vote threshold needed for certification, and got certified in the very next block — exactly as designed.
  • The caveat: the cryptographic signing keys used in this demo were *fake* — short-cut versions derived insecurely from public keys, just for testing. Real stake pool operators registering their real keys is the next concrete step, and it's currently blocked on finishing a code migration to the Dijkstra-era codebase. (The meeting transcript spells this "Dystra," which doesn't match any real Cardano era name — Dijkstra is the documented one, and it's the obvious intended word.)

2. A dedicated "red team" trying to break it on purpose:

  • A separate group from the core protocol designers is now building deliberate attack scenarios, using an upgraded simulator plus a new lightweight tool called "Piranha" — a stripped-down node that can pretend to misbehave instead of cooperating.
  • In one demo, they made roughly a third of the voting committee simply refuse to vote ("lazy voters") and showed, live, that this causes EBs to fail certification — proving the failure mode behaves the way the design predicts.
  • More attack types are explicitly planned but not yet demoed: blocking EB delivery, and sending different versions of the same EB to different parts of the network.

3. A stress test that found a real weak spot:

  • The team deliberately built an unfriendly network layout — nodes spread across Europe, the US, and Asia-Pacific, connected more sparsely than usual — and hammered it with transactions.
  • Result: the European node, closest to where the test transactions originated, filled up fast. The US node filled up slower. The Asia-Pacific nodes — roughly 200-250 milliseconds away — never filled up at all.
  • In plain terms: the "waiting room" where transactions sit before being picked for a block (the mempool) doesn't currently treat far-away, high-delay parts of the network fairly, even though there's plenty of spare computer power sitting idle (they measured only ~3% CPU use in a normal test).

4. A more fundamental design question about that same waiting room:

  • Today, a transaction only has to make sense against one version of "the current state of the ledger."
  • Leios complicates that: once an EB gets certified, it creates a *second*, slightly different version of the ledger state — and a transaction can be valid in one version but not the other.
  • The team is now seriously discussing whether Leios needs two separate waiting rooms (one per ledger-state version) or a more fundamental redesign. Nothing is decided yet.

5. A fix for nodes that show up late:

  • If a node joins the network late, or goes offline for a while and comes back, it can miss the specific message announcing a new EB — and without that EB's contents, it can't process a later block that certifies it. Without a fix, that node would simply get stuck.
  • The team demoed a fix: the node temporarily sets that block aside, fetches the missing EB content it needs, and then catches back up. They tested this for real — taking a node offline for 5-10 minutes and watching it successfully rejoin.

6. A smarter way to move a 12-megabyte file across the planet:

  • An EB can be up to roughly 12 MB — much bigger than a normal block. Naively asking all 25-ish neighboring nodes for it at once would waste enormous bandwidth.
  • The new approach: send one big, unrestricted request to the *first* far-away ("high-latency") neighbor offering the file, since that's the slow part of the journey and it's worth using fully. Once it arrives anywhere on a continent, it can spread fast to nearby nodes anyway. If a neighbor's request beats yours, you piggyback on theirs instead of duplicating the work.
  • Tested with simulated transfers like Germany-to-Tokyo and Australia-to-South America, this approach delivered the file roughly 3-4 seconds faster than a bandwidth-limited version — which matters because the whole protocol is working against a 7-14 second budget for data to spread everywhere.
  • The catch, openly acknowledged: today's test simulator assumes a neighbor who offers data will always actually hand it over. A real attacker could offer data and then deliberately stall (sometimes called a "slow loris" attack), and the team hasn't finished working out how exposed this new approach is to that.

7. Fixing mistakes in the team's own math model:

  • Separately from running real network tests, the team also keeps a mathematical model (called DeltaQ) that predicts how data should spread across a realistic, geographically spread-out network — a kind of forecast rather than a live experiment.
  • They found and fixed a real bug in it: it had been modeling two different data-fetching paths as racing each other in parallel, when Leios actually only ever takes one or the other.
  • They also added a comparison between two real-world internet congestion-control methods (Cubic, the Linux default, came out faster and more reliable on long-distance links than Reno, the BSD default) and fixed a separate error that had underestimated, by roughly half, how long it takes to re-process transactions after fetching an EB.
  • Bottom line from the corrected model: the 14-second target still holds for the EB sizes they tested, using Cubic — but the model also suggests the true safe maximum EB size might end up smaller than the 12 MB target. That's flagged as an open question, not a settled answer.

One concrete win worth calling out on its own

Separately from all the open problems above, one change has already been merged into the official Cardano Improvement Proposal: a redesign of how the voting committee is selected. Its direct effect is shrinking the certificates that get permanently stored on-chain for every certified EB by roughly 1,000x — from about 8 kilobytes down to roughly 200 bytes. Since these certificates accumulate forever, that's a real, lasting cost saving, not just a one-time optimization.

What to watch for in today's call

The May review ended with the stress test "basically done" and testnet preparation as the explicit next step — and that testnet is now, as of yesterday, actually live. Worth watching for in today's update: whether real stake pool operator key registration has landed now that the Dijkstra-era migration is further along, which direction the mempool redesign went, and whether the team has a firmer answer on how exposed the new file-fetching strategy is to a deliberately stalling attacker.

--- Sources:

https://cardanoscope.com/reports/2026-06-24-ada-leios-musashi-dojo-primer-may-review