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

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