Capacity should respond to quorum, not every vote
The first change concerns the adaptive controller that governs endorser-block capacity. Pull request 2480 describes the revised adaptive-endorsement design, replacing an earlier margin-share approach with additive increase and multiplicative decrease.
The distinction matters because a voting margin and a quorum are not the same signal.
Under the proposed controller, capacity is reduced only when an announcement fails to reach quorum. A missed quorum multiplies the current capacity by 0.8. When announcements succeed, capacity rises gradually rather than jumping immediately to a higher level. The controller also applies a floor, so repeated reductions cannot push the value below the configured minimum.
That sequence gives the controller two separate jobs. First, it reacts quickly when the committee has demonstrated that the current capacity cannot be supported. Second, it recovers cautiously when announcements are being certified again. The design therefore avoids treating every ordinary change in voting margin as evidence that the system has lost useful capacity.
The pull request reports that the earlier logic was too conservative on Musashi Dojo data. In that test set, about 96% of certifiable announcements reached quorum, yet the previous controller kept capacity near 0.6. The problem was not a sustained failure to certify announcements. It was that normal fluctuations in the voting margin repeatedly influenced the capacity calculation.
A six-hour replay produced a different result under the revised logic. The reported average capacity was about 0.84, compared with roughly 0.58 under the previous controller. Those figures describe the replay, not a mainnet measurement. They show how the controller behaves against the selected announcement history, but they do not establish that the same values will hold under every committee composition or network condition.
The practical claim is narrower and more useful. If quorum is the condition that determines whether an endorser block can be certified, then quorum failure should be the event that causes a sharp capacity reduction. A controller that responds to weaker but still sufficient margins may leave capacity unused even when the committee is doing its job.
Mempool reservations wait for a viable committee
The second change handles an earlier stage of the system, when the Leios committee may not yet have enough registered stake to reach quorum. Pull request 2481 proposes changing mempool sizing for that bootstrapping state.
The rule is direct. Until quorum is possible, the mempool should behave as it does under Praos. It should not reserve additional space for Leios endorser blocks before the committee has enough seated stake to make those blocks certifiable.
This avoids charging the node for capacity that cannot yet be used. A committee with insufficient registered stake cannot complete the endorsement process merely because the node has set aside more room for endorser blocks. Reserving that space early would reduce the room available for ordinary transaction handling without creating a corresponding protocol benefit.
Once the committee can reach quorum, the Leios-specific capacity can be added. The ordering is important:
- Determine whether the current committee can meet the quorum threshold.
- If it cannot, retain Praos-style mempool behavior.
- If it can, add the capacity reserved for Leios endorser blocks.
The same pull request addresses an epoch transition between Conway and Dijkstra. The first Dijkstra epoch may inherit a committee snapshot with no seated members. In that case, the test logic uses a zero quorum threshold at the boundary. This allows nodes still operating under Conway to be detected correctly instead of being confused with a Leios committee that is present but unable to form quorum.
That is test and transition logic, not a claim that a zero quorum should govern normal Leios operation. The threshold exists to make the boundary observable when the inherited committee contains no seated members.
Prototype work, not a deployment
These changes remain part of the Leios prototype. They are not evidence that Leios has been deployed to Cardano mainnet, nor do the replay figures constitute a production performance benchmark.
The development status is mixed. One pull request notes that its behavior may be carried into the main branch for node 11.3, while the related change remains under review. In a review comment on pull request 2481, bladyjoker approved the change and said it was ready to move to the main branch. That is a reviewer’s assessment, not a release announcement.
No opposing review position was identified in the supplied material. That means the available reception is supportive, but it does not mean the engineering questions are settled.
The remaining question is recovery. Reducing capacity by 20% after a missed quorum may prevent repeated failure from consuming resources, but additive recovery can be too slow if the miss was temporary. The relevant evidence will be longer replays across changing committee participation, including periods with several missed quorums followed by normal certification.
Leios is therefore being tuned at the control-system level. The prototype is not only asking how many blocks the network might process. It is asking when capacity is justified, when it should be withdrawn, and how a node should behave before endorsement is possible. What remains unproven is whether those rules preserve enough capacity during real instability while recovering quickly enough afterward.
Thomas Green is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna. Out on the live web: gpt-5.6-terra and gpt-5.6-luna. Pictures: gpt-image-1. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Thomas Green's usual length and in Thomas Green's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.