Fast Confirmation Rule (FCR) #11, July 21, 2026

Protocol Calls & happenings
1

Agenda

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

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

GitHub Issue

2

Meeting Summary:

This was the 11th Fast Confirmation Rule (FCR) breakout meeting where client teams shared updates on their implementations and progress. Lion from Lighthouse reported completing their FCR implementation with maximum spec parity, achieving 30 milliseconds per slot performance, though they identified issues with node restarts causing artificial reversion metrics due to starting from finalized rather than confirmed states. Dimitrii from Teku shared that their implementation is in branch and merging in stages, running at 150-200 milliseconds per slot with mostly conservative results compared to Lighthouse, while Nazar from Lodestar reported performance improvements and is working on disabling FCR during range sync to prevent false reversions. Jun from Prism indicated their implementation is still under review with performance improvements being considered, and Roberto announced the release of an updated paper that presents the algorithm more accessibly while moving formal proofs to an appendix. The team discussed potential fuzzing efforts for FCR implementations and debated whether the safe block hash should default to finalized rather than justified when FCR is disabled, though concerns were raised about potential usage in other contexts.

Click to expand detailed summary

The meeting began with technical difficulties as participants joined, including audio issues that were eventually resolved. Mikhail announced they would wait 2-3 minutes for more attendees to join before starting the FCR (Finality Confirmation Rule) breakout session number 11. The meeting was scheduled to follow an agenda starting with client updates, beginning with Lighthouse, though the specific updates were not captured in the transcript.

Lion reported completing the FCR implementation, which now runs in 30 milliseconds on most slots with maximum spec parity and performance optimizations. The previous reversion issues were fixed by addressing state advance with the wrong slot, though Lion clarified that from a user perspective there were no actual reversions as the system would immediately restart justification after hitting the reversion condition. Mikhail suggested Lion open a PR to improve the metrics tracking for better measurement of confirmation route backtracking.

Mikhail and Lion discussed issues with block confirmation after node restarts, particularly when the beacon node stops and restarts. They identified that the current implementation only persists the four choice state in FCR, causing problems with reconfirming previously confirmed routes after restarts. The discussion touched on safety proof requirements limiting block confirmation to within one epoch of the current epoch, and they noted that metrics might incorrectly show reversion events during node restarts. Jun provided an update on Prysm development, mentioning ongoing testing and reviewing with plans to add metrics to a specific branch.

The team discussed the safety of persisting a confirmed route to disk and starting from it instead of a finalized route when booting Lighthouse. Mikhail and Roberto explained that while using a confirmed route from two epochs ago could be considered unsafe under certain assumptions about network stability, the current system only assumes network goodness for two epochs, not for the entire period of downtime. Lion suggested a potential solution where the confirmed route in the CL process could be updated before sending the FCU, which Mikhail acknowledged as a valid approach.

Mikhail, Lion, and Roberto discussed the potential issues with node restarts and block finalization. Lion explained that if a restart is long, it could cause problems with block epoch tracking, leading to confusion between confirmed and finalized blocks. Roberto clarified that after a restart, the CL would update the EL about the confirmed block. They agreed to think asynchronously about this edge case and its implications. Additionally, Roberto mentioned that while there is a prototype for optimizing late blocks, it is not yet released due to the need for further proof and focus on other priorities.

Lion reported that the current FCR user percentage of 97% is performing well, though Julian indicated he would need to investigate further to confirm this assessment. Lion confirmed that the FCR implementation will be released in the next version, with no observed issues or reversions beyond node restarts. Dmitrii updated on the Teku implementation of FCR and TECO, noting it’s currently in branch with merging expected to take at least two weeks, though there are some performance concerns with 150-200 milliseconds per slot that are being investigated but not blocking the implementation.

The team provided updates on Fast Confirmation Rule (FCR) implementation across different clients. Dmitrii reported passing reference tests and mainnet performance metrics, while Nazar shared performance improvements and work on disabling FCR during node range sync. Jun mentioned ongoing performance review of Prism’s implementation, which is still under review. The team discussed potential integration of FCR with simulators and the need for fuzz testing of implementations. Roberto announced the release of an updated paper on the FCR algorithm. The group also addressed concerns about the safe block hash property and its potential impact on network behavior during stalls.

Next Steps:

  • Lion: Open a PR to update the standardized FCR metrics to better track actual confirmation route backtracking, and share the proposed changes.
  • Lion: Debug the issue where, after a beacon node restart, Lighthouse cannot reconfirm the previously confirmed route, and explore solutions (e.g., persisting the confirmed route).
  • Lion: Share statistics on observed reversions (outside of node restarts) with the group.
  • Dmitrii: Investigate the divergence in confirmed routes between Teku and Lighthouse during the December 2025 incident, focusing on potential Harness timeout issues.
  • Dmitrii: Finalize and merge the FCR implementation into Teku’s master branch over the next few weeks.
  • Nazar: Complete the PR to disable FCR during range sync in Lodestar and aim for inclusion in the upcoming RC.
  • Boma’s: Investigate whether FCR should be disabled during range sync in their client to prevent reversions.
  • Jun: Coordinate with Terence to run the Prism FCR implementation on mainnet and in their Clift cluster.
  • Jun: Follow up with EF Ops team about integrating Prism into the FCR simulator for historical data testing.
  • Mikhail: Follow up with EF Ops team about the possibility of running the FCR simulator with Prism.
  • All interested parties: Express interest in the Telegram chat about fuzzing the FCR implementations, to coordinate efforts.
  • Mikhail: Follow up after the call on the proposal to revert the safe block hash to finalized by default if FCR is not enabled.

Recording Access:

3

YouTube recording available: https://youtu.be/xROg726R6FM