FOCIL Breakout #28, February 10, 2026

Protocol Calls & happenings
,
1

Agenda

  • Development updates
  • and more

Meeting Time: Tuesday, February 10, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

2

YouTube recording available: https://youtu.be/7Ru64pmLwxs

3

Meeting Summary:

The team discussed updates to the CL specification focusing on IL bit lists and compliance checks, with Jihoon proposing that PTC handle inclusivity checks and attesters verify IL constraints. The discussion covered various aspects of transaction inclusion and validation mechanisms, including view merging and fork choice processes. Pelle presented research findings on inclusion list delays and censorship detection algorithms, with the team agreeing to simulate different inclusion algorithms and explore further research opportunities.

Click to expand detailed summary

Jihoon led a discussion on FOCIL (Fork Choice IL) updates, focusing on two main changes to the CL spec: IL bit list inclusivity checks and IL compliance checks. He explained that builders will provide IL bit lists indicating which ILs they’ve considered when building a block, and proposed that PTC (Proof of Transaction Commitment) should handle inclusivity checks rather than attesters, as reorging the envelope would have less impact than reorging the beacon block. Jihoon also discussed IL compliance checks, where attesters would verify if blocks satisfy IL constraints, and proposed that non-compliant blocks could be down-scored but not necessarily rejected.

The team discussed the relationship between bit lists and inclusion lists, with Justin raising a question about how view merging handles transactions that not everyone may have seen. Jihoon explained that builders can include more transactions than expected without violating any mechanisms, and clarified that testers validate IL constraints using their local IL view rather than the bit list. The team also discussed PTC checks and fork choice, with Mehdi asking about the difference between PTC and attester checks. Jihoon proposed letting PTC vote for RLP inclusivity, but noted that this information should not be used in fork choice. Pelle presented research on different delays with inclusion lists, finding that a one-slot delay wouldn’t be too bad, but noted that the data was messy and could be improved with new information from BlockNative.

Pelle and Jihoon discussed the impact of delaying a slot by one on research results, noting a marginal increase of 0.1% in network bandwidth savings. Pelle explained the censorship detection algorithm, which identifies transactions above the base fee and top 10 or 25th percentile of priority fees, and highlighted the low inclusion rate of mock inclusion lists. They agreed to simulate various inclusion algorithms and explore further research opportunities, with Pelle planning to provide updated results in the next meeting.

Next Steps:

  • Jihoon: Update FOCIL spec (CL spec, Execution spec, and Engine API spec) with CL spec ready by next ACDC on the 19th
  • Jihoon: Make a PR for the spec changes by the end of this week
  • Pelle: Run analysis with new data from BlockNative and present results at next breakout call
  • Pelle: Simulate various inclusion building algorithms and analyze their effects on research

Recording Access:

4

FOCIL specs are being updated for Hegotá.

FOCIL for Hegotá

  • FOCIL has been proposed for Hegotá. The CL headliner decision will be made in ACDC on the 19th.

Development Updates

  • The CL spec will have two main changes: IL bitlist inclusivity check and IL compliance check.

  • An IL bitlist is added to bids so builders can signal which ILs they considered when building a block. The bitlist serves as an informational signal for proposers on whether the corresponding payload is likely to satisfy IL constraints, but it is not a guarantee. For instance, a payload can be IL compliant when the bitlist is not inclusive, if ILs overlap to cover the missing IL. Therefore, the bitlist inclusivity is not used in fork choice. However, the bitlist information can be used out-of-protocol, e.g. to downscore builders that consistently provide non-inclusive bitlists or IL incompliant blocks.

  • When an attester for slot N receives an envelope for slot N-1, they check if the payload satisfies the IL constraints against their local IL view. If the payload is not IL compliant, the attester expects the beacon block for slot N to extend the envelope for slot N-2 rather than N-1, effectively reorging the IL incompliant envelope.

Q: If the bitlist is a superset of attesters’ merged view, could this require including transactions that not everybody has seen?
A: Builders have extra time to receive and update their IL view, so they may see more ILs than attesters. However, attesters validate IL compliance against their own local IL view, not the IL bitlist. A builder including more transactions than expected does not violate any FOCIL mechanism.

IL Analysis using Xatu Data

  • Pelle shared results from the IL analysis using Xatu data from PandaOps. With the current setup, roughly 20% of transactions in a mock IL are already included in the next block.

  • The data is noisy due to spam transactions and the inability to check state on historical data. Pelle is working with new data from Block Native for higher-resolution analysis and various IL building algorithms.

Links

1 Like
5

Recording

Summary