Fast Confirmation Rule (FCR) #10, July 7, 2026

Protocol Calls & happenings
1

Agenda

  • Client Updates
  • Spec and Testing Updates
  • API and Metrics Updates
  • Research Updates

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

GitHub Issue

2

Meeting Summary:

This was the false confirmation rule (FCR) breakout meeting number 10, focused on client updates and progress on the FCR implementation across different Ethereum clients. Boma reported that Gwen Dean passed FCR-specific tests but is still working on general spec tests, while Nazar shared that Lighthouse released version 1.44.0 with experimental features and deployed a performance fix for epoch boundary edge cases that has been running smoothly for four days without resets. Nazar’s analysis revealed that node resets were caused by low attestation reception rather than FCR issues, specifically noting that one node had insufficient votes for slots 29 and 30, and he also identified that FCR should not trigger during node syncing processes. Other client updates included Terrence being blocked by human review, Lighthouse resolving a previous regression issue, and Teku starting their production-ready implementation. The team discussed testing requirements, with Barnabas asking about verification methods and timeline coordination for FCR implementation on top of GLOS, and the group agreed that testing should begin in GLOS devnets as soon as possible. Roberto reported that proof review work is nearly complete except for adding an appendix explaining differences between the paper pseudocode and Python specs, and the team briefly discussed a potential late block improvement that could provide 1-1.5% performance gains but would require significant additional proof and implementation work.

Click to expand detailed summary

Mikhail welcomed participants to the false confirmation rule breakout session number 10 and outlined the agenda, which included client updates. The meeting was scheduled to be brief, and Mikhail indicated they would start with updates from Gwen Dean.

Boma confirmed passing FCL tests but noted that Grangian is not passing all spec tests. Nazar reported releasing version 1.44.0 with experimental features and deployed a fix for performance issues related to epoch boundary edge cases, which has been working smoothly since Friday. Nazar’s analysis revealed that node resets were caused by low attestation reception in specific slots rather than being a general network issue, and he observed unusual FCR behavior during node syncing with high reset counts reaching 250+ during out-of-memory crashes.

Mikhail and Nazar discussed the implementation of Fast Confirmation Rule (FCR), agreeing that it should only be enabled after a node is fully synced. Nazar committed to posting questions about participation issues in the Telegram group and sharing analysis. Mikhail provided updates on other clients, noting that Nimbus enables FCR by default, while others use feature flags. Barnabas inquired about validating FCR implementation and on-chain progress, to which Mikhail suggested monitoring the event stream for pause confirmation events and mentioned that Sam is running tests with various clients.

Mikhail explained that the new event stream implementation is compatible with previous forks and should work with Gloss, though it will affect payload confirmation in previous slots. Barnabas requested to test the feature on devnet 7 and asked about the timeline for shipping FCR implementation before Gloss. The team agreed to discuss branch sharing and testing details in Discord after the call, with Mikhail acknowledging the importance of proper resource allocation for the FCR implementation.

Mikhail and Boma discussed the timeline for PR reviews and testing, with Mikhail suggesting waiting for Lighthouse and Lone Star releases before proceeding with client testing. They agreed to coordinate testing in the next FCR breakout call, potentially in a couple of weeks. Mikhail also updated on spec and testing updates, mentioning that a new PR with tests for edge cases has been merged, making the manual test suite for FCR ready. Additionally, a metrics PR has been merged, and Mikhail encouraged implementing these metrics across all clients for better comparison after mainnet releases.

The team completed reviewing the algorithm proofs and identified minor differences between the pseudocode in the paper and the Python specifications that need to be documented in an appendix. Mikhail proposed considering a late block improvement that showed a 1.5% performance increase in prototype testing on Teku, though Roberto expressed concerns about the proof work required and potential impact on other projects like feeder forks and Kappa consensus. The team agreed to further evaluate the research value and time requirements for implementing this optimization before deciding whether to include it in their work.

Next Steps:

  • Boma: Follow up with Thomas for review on the PR and ensure it is reviewed soon.
  • Nazar: Share the analysis of the epoch boundary reset case in the Telegram group.
  • Nazar: Post questions in the Telegram group to ask other clients if they observed similar reset issues.
  • Nazar: Continue testing the performance fix for epoch boundary edge cases and release it in the upcoming release.
  • Nazar: Work on fine-tuning FCR to not trigger during node syncing.
  • Mikhail: Add Barnabas to the Fast Confirmation Rule Telegram group if he changes his mind.
  • Mikhail: Share details about the late block improvement (from Teku) in the Telegram group.
  • Roberto: Add an appendix to the paper explaining the differences between the pseudocode and the Python spec, and show that they don’t affect correctness.
  • Research team: Consider whether to pursue the late block improvement, evaluating proof and implementation effort required.
  • Client teams: Allocate resources to test FCR implementations on GLOS devnets as soon as possible.
  • Client teams: Implement the merged metrics PR to enable cross-client comparison after mainnet releases.
  • Mikhail: Coordinate cross-client testing of FCR implementations in the next FCR breakout call (in a couple of weeks).

Recording Access:

3

YouTube recording available: https://youtu.be/lbX6toJ-rCc