Fast Confirmation Rule (FCR) #8, May 26, 2026

Protocol Calls & happenings
1

Agenda

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

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

GitHub Issue

2

Meeting Summary:

This meeting focused on updates for the Fast Confirmation Rule Breakout Number 8, covering client updates, specification changes, testing, APIs, and research progress. Mikhail provided updates on client work, noting that Nazar was waiting for team review on a PR before merging and releasing, while Mercy had made code adjustments based on feedback and added up to 6 metrics, pending review. Mikhail presented two specification updates: a PR changing validation conditions during reconfirmation to better handle edge cases, and another PR making the fast confirmation rule compatible with GLOS forks. On the testing side, Mikhail proposed disabling BLS for fast confirmation rule tests to improve speed, and planned to enable tests for Gloss and Heza after a related PR is merged. Samcm shared significant research updates, including a public dashboard showing 97% immediate confirmation rates over the last 30 days and a historical simulation that analyzed fast confirmation performance across different clients, finding that no slots were fast confirmed that later got reorged or orphaned. The team discussed challenges with visualizing non-confirmed blocks and measuring confirmation delays through metrics. Mikhail announced he would be on vacation in two weeks and proposed holding an asynchronous update in the chat instead of a regular call, with Roberto volunteering to host if needed.

Click to expand detailed summary

Mikhail led a meeting on fast confirmation rules and provided updates on specifications, testing, and APIs. He reported that Nazar, who was unable to attend, is waiting for team review on a PR before merging and releasing it, after which he plans to work on the loss confirmation API event for fast confirmation. Mikhail asked Mercy for updates but did not receive a response in the provided transcript.

Mercy updated her code based on feedback and added up to 6 metrics, with plans to push the updated code within an hour. Mikhail provided updates on Nimbus adding an event to the event stream and noted that Nethermind is waiting for fixes related to the safe block hash with Engine API. Mikhail also shared a PR he opened that changes the validation during reconfirmation to address edge cases where confirmed blocks may not properly follow checkpoint chains.

Mikhail provided updates on two PRs related to the fast confirmation rule. The first PR includes a test to ensure proper implementation, and the second PR makes the fast confirmation rule compatible with GLOS and other forks. Mikhail also discussed plans to disable BLS for fast confirmation rule tests to improve speed and mentioned upcoming work on edge case tests. Additionally, Mikhail presented a small PR to the Beacon API that clarifies what is sent in the fast confirmation event and introduced new core metrics for the Beacon Metrics, seeking feedback on standardizing these metrics across different clients.

Roberto reported that they are completing the final round of proof reviews, addressing only minor internal issues without impact on the algorithm results. Samcm shared two links: a public dashboard showing fast confirmation rates at approximately 97% over the last 30 days, and a simulator that wraps Consensus clients to analyze historical data from canonical chain era files and orphaned blocks. The simulator analysis showed that no fast-confirmed slots were eventually reorged or orphaned, though there were some discrepancies between different client implementations, particularly with Teku being more optimistic.

The team discussed a dashboard displaying beacon FCR (fast confirmation rule) metrics, with Sam explaining that “not confirmed” blocks appear due to limitations in reconstructing parent-child relationships from Grafana data. Sam agreed to create a temporary fix for the visualization issue and noted that a proper solution would require additional beacon API events to track block confirmations across the chain. Mikhail announced he would be on vacation in two weeks and proposed holding an asynchronous update in the Telegram chat instead of a regular call, with Roberto volunteering to check if a call was needed and the group agreeing to default to skipping the meeting.

Next Steps:

  • Nazar: Wait for team review on the PR to get it merged and released, then work on the loss confirmation API (Beacon API event for fast confirmation).
  • Mercy: Push the updated code with the 6 added metrics within the next hour and share the link in the group.
  • Mikhail: Follow up on Nethermind releases to ensure the fix for the safe block hash issue with Engine API is included in an upcoming release.
  • Mikhail: Open a PR to enable fast confirmation rule tests to run with Gloss and Heza, after the related Gloss compatibility PR is merged.
  • Mikhail: Disable BLS for fast confirmation rule tests to speed up test generation, and notify the team if any issues arise.
  • Mikhail: Continue working on edge case tests for the fast confirmation rule after the Gloss refactor and follow-up test updates are complete.
  • All attendees: Review the Beacon Metrics PR introducing the core metrics (total reorgs, fallbacks, restarts, fast confirmed slot) and provide feedback.
  • samcm: Hack together a fix for the “non-confirmed” visualization issue on the Grafana dashboard to properly reflect blocks confirmed via parent-child relationships, and post the update in the group chat.
  • Roberto: Review the fast confirmation proofs and finalize the last round of minor fixes to ensure all proofs fit together.
  • Mikhail: Announce in the Telegram group whether the call in two weeks will be skipped (defaulting to async updates) or hosted by Roberto if needed, and confirm the decision this week or next week.

Recording Access:

3

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