FOCIL Breakout #36, June 16, 2026

Protocol Calls & happenings
,
1

Agenda

  • Development updates
  • Spec updates
  • Testing updates
  • and more

Meeting Time: Tuesday, June 16, 2026 at 13:00 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on development updates and specification changes for Fossil Breakout 36, with Jihoon leading the discussion on IL (Inclusion List) bit lists and fork choice rules. The team discussed three options for handling IL bit lists: changing FCU to send IL lists, adding bit lists to payload attributes events, or removing them entirely, with consensus reaching removal of IL bit lists due to potential for manipulation. Jihoon presented proposed changes to payload status V2 and how the EL (Execution Layer) should handle accepted payloads when moving between different branches, explaining the security assumptions and potential attack vectors. The group also debated when to turn off IL enforcement during non-finality periods, with discussion around whether to use one or two epochs as the trigger threshold, though final consensus was deferred pending further review in the Discord channel.

Click to expand detailed summary

The team discussed development updates for Fossil Breakout 36, focusing on Loadster’s rebase on Glamsterdam DevNet 5 and censoring functionality. Bharath reported a bug in Lodestar related to gossip serialization and bits serialization, which Nico confirmed had been fixed. The team identified that the next step is to test if ELS provides the correct error codes and if the CL handles them properly to complete the censoring builder implementation.

Jihoon presented plans to discuss IL bit list implementation, including whether to keep it and potential changes to the engine API or beacon event. He outlined three options for handling IL bit lists: changing FCU to send IL lists, adding them to payload attributes event, or removing them entirely. The team discussed the purpose of IL bit lists as a signal for proposers and builders regarding IL compliance, with Jihoon noting that while they could be used to punish non-compliant builders, similar punishment could be achieved without them.

Jihoon explained that the IL bitlist could help prevent issues with different branches by providing confidence that corresponding payloads satisfy collateral requirements. Bharath raised concerns about the bitlist’s potential for manipulation by builders, questioning its value if it could be easily faked. The discussion concluded with Justin asking about proposer payments in cases of bitlist manipulation, to which Jihoon and Bharath clarified that trustless payments would still proceed if sufficient attestations are obtained.

The team discussed removing the IL bit list feature due to concerns about it being easily faked and limited value. They agreed to remove the IL bit list while keeping the engine API unchanged, with the option to modify it in the future if needed for EL deduplication. The group also addressed payload status V2, proposing improvements to better represent IL satisfaction and discussing how to handle accepted payloads when moving to different branches.

Jihoon clarified that the system needs to remember only the head payload and potentially one more payload for IL compliance validation, driven by fork choice mechanisms. The discussion touched on similarities with PTC votes and the purpose of including PTC in blocks to prevent accidental reorgs. Jihoon explained a detailed example of how payload validation works across branches and how non-finality situations are handled, particularly regarding the security assumption when malicious actors control over 30% of the weight on a branch.

Jihoon and Justin discussed a scenario where a malicious actor could potentially canonicalize a non-IL-compliant payload with 30%+ control of testators in consecutive slots, particularly when using proposer boost. Nico questioned how a branch with only 33% of testators could switch to a non-IL-compliant branch, and Jihoon clarified that the scenario involves multiple branches with different weight distributions. The discussion concluded that the proposed solution is based on the same security assumptions as current ex-post reorg mechanisms.

The team discussed fork choice rules and IL (Inclusion List) enforcement during network non-finality periods. They aligned on implementing a “circuit breaker” feature that would disable IL enforcement after one epoch of non-finality, though the exact implementation details and specific trigger conditions still need further discussion and review. The group also reviewed changes to payload status V2 and how ELs handle accepted payloads, with CLs needing to properly interpret the latest IL satisfied hash to follow correct fork choice rules. Jihoon will prepare a write-up on the fork choice changes for further review and will discuss implementation details with Felix.

Next Steps:

  • Bharath: Test the censoring builder with the latest Lodestar branch (which has the gossip serialization bug fixed) and report results.
  • Nico: Verify that ELs return the correct error code when IL is not satisfied, and confirm CL handles it correctly.
  • Eitan: Continue testing Lighthouse implementation and provide an update on whether it is working.
  • Jihoon: Make spec changes to remove IL bit list from the bid, keeping the engine API as is.
  • Jihoon: Prepare a write-up on the fork choice changes (payload status V2, how EL treats accepted payloads, CL interpretation of latest IL-satisfied hash, and branch-switching behavior) and request broader review.
  • Jihoon: Open a spec PR (within one to two weeks) covering payload status V2, accepted payload handling, and the non-finality circuit breaker condition (one epoch vs. two epochs).
  • Justin: Open a discussion in the Discord channel to gather more input from client teams on the non-finality circuit breaker condition (one epoch vs. two epochs).
  • Jihoon: Discuss with Felix how the fork choice spec changes will affect test cases and how to implement those changes in testing.

Recording Access:

3

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

4
5

CROPS, lead the gwei.

Development Updates

  • Lodestar: Nico rebased on top of glamsterdam-devnet-5 and can now accept bids, so the censoring path is ready to test.

  • Lighthouse: Eitan rebased on top of glamsterdam-devnet-5. The FOCIL implementation is still being tested with another update expected in a few hours.

  • Buildoor: Bharath has a FOCIL branch where the censoring builder works.

Spec Updates

  • Jihoon walked through several IL validation topics, centered on what happens when a node moves between branches.

  • IL bitlists will be removed. The bitlist in the bid is meant to signal to the proposer that the corresponding payload will be IL-compliant. One use case was that validators can downscore or disconnect builders that produced censoring payloads. However, the bitlist can be faked and the censoring builder can be identified without it. For these reasons, people saw no value in keeping it and preferred to remove it.

  • FOCIL will introduce PayloadStatusV2 with a new latestInclusionListSatisfiedHash field, instead of piggybacking on PayloadStatusV1 with a new INCLUSION_LIST_UNSATISFIED status enum. This gives a clearer meaning especially when a node validates multiple ACCEPTED payloads after moving to a different branch.

  • The EL should remember the ILs passed by the CL for ACCEPTED payloads. This is necessary to let the CL have the same view after it moves to a different branch. Similar to the IL Store on the CL, it seems sufficient to store ILs only for the latest payload.

  • The latestInclusionListSatisfiedHash field points to the latest payload that satisfied the IL constraints. Note that it does not mean that all of its ancestors are IL-compliant, because FOCIL is a fork-choice rule, not a validity rule. Today, an attacker with more than 30% of the weight can reorg an innocent block, an ex-post reorg, and in the same vein, such an attacker can canonicalize a censoring payload.

  • ACCEPTED payloads are treated as IL-compliant, which is the natural choice for allowing nodes switch to a different branch. When a node moves to a branch that shares the same dependent root, it ends up with the same IL view as the nodes already on the target branch. If a divergence lasts more than an epoch—the branches have different dependent roots—nodes coming from a different branch hold no ILs for the target branch and validate its payloads against zero ILs, treating them as compliant. If the payload was not IL-compliant, this produces a temporary split view that will recover in a slot, with the outcome depending on the weight difference and the proposer boost for the next slot.

  • This is also related to the non-finality threshold for turning off IL enforcement. When the protocol is not finalizing, enforcing ILs does not help recover liveness. Whether to set the threshold at one epoch or two is an open question.

  • While syncing, a node follows the heaviest weight. Once it turns to synced mode, it subscribes to the necessary p2p topics, including ILs, and performs its duties. As an edge case, a node might miss an IL that happens to carry a censored transaction; it then will lose a single attestation reward while the chain still progresses as long as the majority is honest. A node can request missing ILs from peers but that requires trusting their IL views. A client can adopt a strategy of not attesting right after syncing if it has not heard any ILs for the attesting slot, which will contribute to network health.

1 Like