Fast Confirmation Rule (FCR) #7, May 12, 2026

Agenda

  • Client Updates
  • Spec Updates
  • Research Updates
  • Testing Updates

Meeting Time: Tuesday, May 12, 2026 at 12:00 UTC (60 minutes)

GitHub Issue

Meeting Summary:

The team held a weekly update meeting focused on client implementations and specifications for the Fast Confirmation Rule (FCR) feature. Nazar reported that his implementation was ready for deployment after fixing minor rounding bugs, with multiple nodes running successfully for over a week, though his team requested mainnet spec tests for increased trust. Mercy identified two issues in her implementation related to epoch lookups and justified drops, planning to investigate further by Friday. Mikhail discussed ongoing work on making the FCR spec compatible with Gloss, including changes to the fork choice abstraction layer, noting this would require careful consideration due to the current focus on Gloss and EIPS. The team also discussed testing constraints, with Justin highlighting a 6-hour limit for mainnet tests and the need to balance adding new tests with existing time constraints. The conversation ended with a discussion about standardizing metrics for measuring FCR performance across different clients, with Nazar confirming his implementation already tracks relevant metrics in the Grafana dashboard.

Click to expand detailed summary

The team discussed moving the git safe execution block cache function to fast confirmation, with Justin agreeing to close his PR and let Mikhail handle the implementation. Mikhail explained that the function didn’t previously have the right placement and is now more closely associated with fast confirmation following recent changes. The meeting was about to begin with client updates as the agenda item, though the full discussion was not captured in the transcript.

Nazar reported that after merging PRR to specs, he fixed minor rounding bugs and deployed the implementation for testing over a week ago. His team is currently reviewing the PR, with plans to merge it within a week. The discussion revealed that while mainnet spec tests don’t currently exist due to performance concerns, adding them would need to be carefully considered given the 6-hour test limit and existing constraints on nightly tests. Mercy provided an update on gradient side, confirming two pre-existing issues related to relative epoch HEPAs and unrealized justified drops, with plans to add tracing and update the PR after further investigation.

Mikhail discussed updates on the Fast Confirmation Rule (FCR) implementation, including issues with Nethermind’s safe head compatibility and Nimbus’s temporary disabling of FCR due to a bug. Mercy mentioned working on an edge case involving committees from previous epochs and expected to have an update by Friday. Mikhail also outlined plans to adjust the FCR spec to work with Gloss, potentially requiring changes to the fork choice abstraction layer, though he noted this might be challenging given the current focus on Gloss and EPOs. Justin suggested splitting the fork choice changes into multiple PRs if possible and noted that additional testing headroom could be used for FCR tests on mainnet.

The team discussed the status of a paper, with Luca indicating it is nearly ready for publication pending review of recent feedback from Mikael. The group then focused on metrics for measuring client performance, with Mikhail proposing to create a metrics repository including key metrics like delay between current slots and most recent confirmed slots, restarts, and runtime in milliseconds. Nazar confirmed that most desired metrics are already being tracked in the Grafana dashboard, and Jihoon suggested modifying the Dora explorer to display the most confirmed block information. The team agreed to schedule their next meeting in a couple of weeks.

Next Steps:

  • Justin: Close the git safe execution block cache PR and leave a comment before handing it off to Mikhail
  • Mikhail: Handle the git safe execution block cache move to fast confirmation topic (taking over from Justin’s closed PR)
  • Nazar: Extract and compile metrics/measurements from the 5+ nodes running the fast confirmation implementation, and share them on the PR for everyone to review
  • Nazar: Complete internal team code review and merge the fast confirmation PR within approximately one week, making it available under a feature flag
  • Nazar: Check how light client spec tests handle minimal-only testing to better understand the precedent for the fast confirmation spec tests
  • Mikhail: Try to generate a subset of fast confirmation tests that work with mainnet preset, while being mindful of the 6-hour CI time limit and current ~5-hour nightly test duration
  • Mikhail: Work on making the fast confirmation rule spec compatible with GLOS (fork choice abstraction layer changes), with plans to highlight all semantic changes and provide equivalence comparisons in the PR
  • Mikhail: Write additional edge case tests for fast confirmation after the spec work is complete
  • Mercy: Add Mikhail’s Telegram invite to join the fast confirmation group and share the PR link there
  • Mercy: Reapply the head state fix and add tracing to confirm which issue (relative epoch HEPA rejects or unrealized justified drips) was driving over-confirmation, with an update expected by Friday
  • Mercy: Update the fast confirmation PR and request team reviews once the root cause investigation is complete
  • Mikhail: Open a PR to the metrics repository defining standardized FCR metrics (e.g., distance between current slot and most recent confirmed slot, reorgs of confirmed blocks, restart counts, confirmation failures, algorithm runtime in ms) within the next couple of weeks and share with everyone
  • Luca/Roberto: Go through the latest feedback from Mikhail on the paper and address remaining comments to prepare it for publication
  • Jihoon: Explore modifying the beacon explorer (used for dev nets) to display the most recently confirmed block using fast confirmation rule data from a client
  • Mikhail: Schedule the next breakout room call in approximately two weeks and discuss how to proceed with the cadence going forward

Recording Access:

YouTube recording available: https://youtu.be/-tIIV-Wqhvc