Meeting Minutes October 08, 2025

Attendees:

Name

Attendance

Role

Voting Seat (Y/N)

Term

Kevin Hammond

No

Chair

Y

October 2025

Adam Dean

No

Vice Chair

Y

October 2025

Terence ‘Tex’ McCutcheon

Yes

Secretary

N

N/A

Markus Gufler

No

Member/Seat

Y

October 2025

Nicolas Biri

No

Member/Seat

Y

April 2026

Duncan Coutts

Yes

Member/Seat

Y

April 2026

Jonathan Kelly

Yes

Member/Seat

Y

October 2025

Sebastian Nagel

Yes

Member/Seat

Y

April 2026

Benjamin Hart

No

Member/Seat

Y

October 2025

Neil Davies

Yes

Member/Seat

Y

April 2026

Alexander Moser

Yes

Member/Seat

Y

April 2026

Community/Other Attendees

  • Christian Taylor

  • Pi Lanningham

  • Thomas Vellekoop

Recording: Technical Steering Committee - 2025/10/08 - Recording

Transcript: Technical Steering Committee - 2025/10/08 - Transcript

Chat Transcript: Technical Steering Committee - 2025/10/08 - Chat Transcript

Intros

Adam: OSC, TSC, CIP Editor, DripDropz LLC Alex: TBD Ben: TBD Duncan: TBD Johnny: Non-Custodial Co-Management SysOps Engineer (Tech Janitor) for 3 Mainnet Cardano SPO Clients. Keystone Ambassador. Voting Seat Member on Technical Steering Committee and Open Source Committee. Kevin: TBD Markus: TBD Neil: TSC, Network Params, PNSol Ltd Nicolas: TBD Sebastian: TBD Tex: Open Source Program Manager (Intersect), GMC/MCC/OSC Secretary, Committee Liaison

Agenda 10.08.25

  • No chair was present at this meeting.

  • Conversation focused around Ouroboros-Leios

Decisions/Actions

Decisions:

  • No decisions made as no chair was present.

Actions:

  • CIP Write-up Clarity: Sebastian to clarify the CIP's current write-up regarding whether new transactions are allowed in a Ranking Block (RB) when it contains an Endorsement Block (EB) certificate.

  • CIP Analysis & Quantification: Neil and the R&D Team (including Sebastian and Vashy) are to perform further analysis to quantify the frequency and magnitude of the Linear Leios overhead cost vs. benefit. This includes looking at historical data to estimate how often Leios would have provided improvement.

  • Simulation Data Improvement: The R&D Team (Sebastian) needs to generate improved simulation data, specifically a better model or visualization for the latency histogram (similar to Figure 9 in the DIP/CIP), to address concerns about the lack of predictability in transaction delays across different load scenarios.

  • Strategic Rationale Update: Duncan will put a comment on the pull request, and Sebastian should ensure the SIP's rationale is updated. The goal is to clearly articulate why Linear Leios is the right intermediate step and how it contributes to the long-term strategy for scalability and economic sustainability.

  • Future Discussion: The team agreed to schedule a future discussion to cover the concerns about asymmetric resource attacks and related attack vectors that Neil raised.

Topic

Discussion

Notes

Meeting Logistics

Duncan confirmed the recording was started. Neil asked for a clear question or agenda, noting the small group size (six people).

Recording is active. Small, technical discussion on Leios.

CIP Discussion Context

Sebastian set the stage: the time was used for a technical discussion on Leios since there was no set agenda. Neil and Duncan had time to look at the CIP (Cardano Improvement Proposal). Sebastian acted as a proxy for the R&D team.

Focus on the Leios SIP. Sebastian acts as R&D proxy.

Concerns on Linear Leios Behavior

Neil discussed concerns about the likely detailed behavior of the proposed linear Leios. He noted that the current formulation involves work that is likely to be thrown away, which is not good systems engineering and could cause issues, specifically, longer delays compared to Preos by itself.

Neil: Linear Leios may result in wasted work (EBs thrown away) and longer delays than Preos.

Wasted Work and Delays

Sebastian asked for precision on "wasted work" and "longer delays." Duncan clarified that wasted work is the Endorsement Blocks (EBs) being thrown away after production and voting. Sebastian confirmed this means re-announcement and re-voting are necessary.

Wasted work = EBs, voting, and dissemination that are invalidated. Longer delays occur for transactions in the wasted EBs.

Leios-Preos Boundary Behavior

Neil stated that if everything fits inside a Ranking Block (RB) (a Preos block), the system behaves just like Preos and never issues an EB—a desirable property according to Sebastian.

When load is low (fits in an RB), Leios should behave like Preos.

Behavior at Slight Overload (Example)

Neil presented a case: mempool has an RB's worth plus 50% extra. An EB is generated. Neil argued that because of the Poisson distribution of block arrivals, an RB will appear before the EB is incorporated at least 50% of the time, making the EB work waste.

At 150% Preos load, 50% of the time, the EB work is wasted due to a new RB arriving first.

RB Containing EB Certificate

Neil discussed the case where the EB work is done. The protocol says a new RB should contain the certificate for the previous EB but no new transactions. Sebastian noted that the SIP's current write-up is unclear if other transactions are allowed alongside the certificate, but his understanding is that it's mutually exclusive for better protocol security.

When an EB is certified, the next RB contains the certificate, potentially excluding transactions.

Transaction Inclusion Delay/Latency

Neil argued that at 150% Preos load, when an EB is successfully incorporated, the transactions that arrived during that time (the extra 50% and any new arrivals) experience a longer delay/higher latency compared to if it were a Preos implementation.

Leios can introduce higher latency for transactions compared to Preos under certain load conditions.

Low Load EB Generation

Neil asked if EBs would ever be generated at 10% Preos load. Duncan and Neil agreed it would occur rarely due to the Poisson distribution—a long gap between RBs can still fill the mempool enough for an EB. Neil noted this means Leios would be paying costs even at low load.

Due to Poisson block arrivals, EBs can be generated even at very low (10%) load.

EB Diffusion Complexity

Jonathan asked for a "sense check" on EB diffusion: it’s an optimistic protocol where only "gaps" (missing transactions) are fetched and validated, but these gaps become more significant at higher loads. Neil agreed, highlighting that fetching missed transactions introduces an expensive network delay.

EB diffusion relies on optimistic fetching, but missed transactions incur significant network delay/cost, eating into the validation time budget.

System Unpredictability

Neil raised a major system engineering concern: the protocol's probabilistic choice to operate in different modes (Preos-like or Leios-like) makes the system's behavior, specifically latency, less predictable than the current Preos system.

Leios's non-deterministic operation modes will lead to worse predictability and wider distributions of transaction times.

Leios Payoff/Turning Point

Sebastian acknowledged the boundary load case (100-200% Preos load) where Preos would outperform Leios. He asked if Leios would always be better than Preos at very high loads (e.g., 20x Preos capacity) where Preos cannot serve the demand. Neil disagreed, stating that the issue is not simply throughput, but the continuous change in probabilities and unpredictable delays.

Leios is expected to be better at very high loads, but Neil is concerned about the unpredictable nature of delays at all load levels, which drives away rational actors.

Leios Strategy and Scalability

Duncan raised a big-picture strategic question, worrying that linear Leios, while providing an intermediate capacity increase (e.g., 5x Preos), doesn't move the ecosystem closer to genuinely scalable designs, as users are not forced to adapt. Sebastian noted the motivation is economic sustainability.

Duncan is concerned that Leios is a good intermediate step for capacity but may not push the ecosystem toward true, long-term scalability.

Last updated