Fast Confirmation Rule (FCR) #4, March 3, 2026

Protocol Calls & happenings
1

Agenda

Bi-weekly, Tuesdays @ 14:00 UTC

Client Implementation Status

Client Status Contact
Prysm Old algo impl; 25% on latest spec Terence
Lighthouse EPF PoC; needs team review —
Teku PoC complete; production dev starting Anton
Nimbus Spec reviewed; active in spec PRs Etan
Lodestar Spec tests passing; deploying to staking env Nazar
Grandine TBD —

Testing

  • Format: Extended fork choice tests (Altair+)
  • Status: Revert/restart tests merged; epoch boundary fix tests in progress
  • Paper: Targeting mid-March
  • Repo: [consensus-spec-tests TBD]

Call 03 Summary (Feb 17, 2026)

Headline

Three spec PRs opened that directly reduce implementation complexity — a key theme from client dev feedback. Lodestar has all spec tests passing and is deploying to staking environments. We need more client teams engaged.

Client Updates

  • Lodestar (Nazar): All spec tests passing after Mikhail fixed an attestation edge case. Next: fine-tune impl, add logging, deploy to staking environments for performance metrics.
  • Nimbus (Etan): Not on call but active in spec PR discussions — drove the FCR trigger timing proposal (see below).
  • Teku / Prysm / Lighthouse / Grandine: No updates this call.

Spec Changes — Reducing Implementation Complexity

Three PRs opened against the spec branch. Client dev feedback on all three is welcome and needed.

# PR What Status
1 #25 Epoch boundary checkpoint fix — FCR was consuming the updated checkpoint in the same slot it was written; fix defers the switch to the first slot of the current epoch Fix confirmed; tests updating this week
2 #26 Flexible FCR trigger timing — let clients call FCR after block arrival / attestation deadline instead of slot start, avoiding a redundant fork choice call Open for feedback; may leave unspecified so clients decide
3 #27 Use head state for FFG check — replace checkpoint state with head state in will_checkpoint_be_justified, since head state is always available in client implementations Open for feedback

Additionally, Mikhail floated reusing fork choice weight/balance data instead of recomputing from state. Nazar confirmed this would significantly simplify Lodestar’s implementation. Worth exploring as a spec-level change.

Exchange Integration / Engine API

  • Exchanges get confirmation status via the EL safe block tag — FCR automatically populates this with the confirmed block. No exchange-side changes needed.
  • In failure/revert cases, safe falls back silently to the finalized block.
  • If FCR trigger timing moves within the slot, the rule must run before forkchoiceUpdated so the safe block propagates correctly. See related discussion.

ePBS Sequencing

  • Lodestar plan: merge ePBS fork choice changes first (~2 weeks), then layer FCR on top.
  • FCR adds store fields but doesn’t change fork choice behavior — limited conflict surface, but worth monitoring.

Testing & Research

  • Test format adjusted per Call 02 feedback. Revert/restart tests merged.
  • Next: update tests for epoch boundary fix (#25); add coverage for new code paths.
  • Paper targeting mid-March.

Action Items

Owner Item
Nazar Deploy to staking env; report performance metrics
Mikhail Update tests for #25; gather client feedback on #26 and #27
Luca Adjust tests for #25; continue paper work
All client devs Review spec PRs #25, #26, #27
Will Async outreach to LH, Prysm, Grandine teams

Agenda for Call 04

A. Client updates (round-robin)
B. Spec PRs — #25 landed? Decisions on #26 and #27?
C. Lodestar staking env metrics (Nazar)
D. ePBS merge sequencing check-in
E. Testing coverage update
F. Open discussion

Add agenda items: Comment below with topic

Prior Calls

Call Date Agenda / Minutes
#01 Jan 20, 2026 ethereum/pm#1870
#02 Feb 3, 2026 ethereum/pm#1887
#03 Feb 17, 2026 ethereum/pm#1924

Meeting Time: Tuesday, March 03, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The team discussed client updates and spec changes, with Mikhail presenting modifications to the adversarial threshold computation and fast confirmation rule implementation. Testing progress was reviewed, including coverage for the EES1 confirmed function and plans to complete rigorous testing for block confirmation cases. The conversation ended with updates on client efforts and research progress, noting positive developments in specifications and client participation.

Click to expand detailed summary

The team discussed client updates, noting that no client developers were present. Mikhail mentioned adding spec changes to discuss, but there was uncertainty about whether to address them at the start of the call or at a later time. Will mentioned that Nazar might be late due to a scheduling conflict.

The meeting began with Mikhail discussing spec changes, which Will mentioned would be shared in the chat. Will noted the absence of client developers and asked for corrections if he was wrong. The group prepared to start the session, with Will planning to wait a few more minutes for attendees to join.

Mikhail discussed changes to the adversarial threshold computation for honest FFG support, aligning it with the one-confirmed method by discounting slashed validators. He mentioned that some tests need fixing due to these changes and noted that the spec is nearly complete, except for potential issues with the spec or box. Mikhail also explained that the team decided against reusing fork-choice weights in the fast confirmation rule due to technical limitations, allowing the two components to be developed independently.

Roberto and Mikhail discussed the implementation of the fast confirmation rule in the Lighthouse algorithm, focusing on using a different balance source and reaching the intended checkpoint. Will shared a link to the Lighthouse implementation for reference. Luca mentioned that work on the paper is resuming after a pause, and he has a meeting scheduled with Roberto to plan the next steps towards finalizing it.

Mikhail discussed the progress of testing for the EES1 confirmed function, highlighting a pull request made by Luca with good coverage. He mentioned the need to complete rigorous testing for cases involving block confirmation from the previous epoch, estimating over 100 tests to be finished by the end of the following week. Mikhail noted that achieving 90-95% test coverage would provide assurance of the implementation’s correctness, with further efforts required to address edge cases.

The team discussed progress on testing and research, noting positive developments in specifications and client participation. Will mentioned that client efforts are currently focused on ePBS’ devnet zero, while Mikhail confirmed seeing progress from the client side. The conversation ended with participants expressing gratitude and signing off.

Next Steps:

  • Mikhail: Fix tests that are broken by the spec changes
  • All participants: Review the spec changes that Mikhail shared
  • Mikhail/Team: Complete rigorous testing of cases where blocks need to be confirmed from the previous epoch by the end of next week
  • Will: Meet with Roto tomorrow to plan next steps towards finalizing the paper

Recording Access:

3

YouTube recording available: https://youtu.be/-k4hboX9vIQ