FOCIL Breakout #37, June 30, 2026

Protocol Calls & happenings
1

Agenda

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

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

GitHub Issue

2
3

Meeting Summary:

The meeting focused on development updates and specification changes for Fossil Breakout 37. Mehdi provided a technical update on integrating Glamsterdam changes into the fossil branch but encountered issues with Flowstar due to builder execution requests. Jihoon presented three main specification updates: execution APIs expected to merge within a week or two, payload attributes event changes, and a detailed discussion about reintroducing IL bit lists. The team extensively discussed the implications of adding bit lists back to the protocol, including potential benefits for correctness, soundness, and proposer incentives, though concerns were raised about protocol complexity and micro-censorship risks. The group decided to tentatively implement the bit list in the container but not yet in the fork choice mechanism, with plans to explore different implementation approaches in future discussions.

Click to expand detailed summary

The team discussed recent development updates, with Mehdi reporting integration of Glamsterdam changes into the fossil branch but encountering issues with Flowstar due to builder execution requests. The group identified that multiple clients including Lodestar and AetherX need to rebase on Glam 6, with Nico noting that the relevant PR has been merged to unstable. The conversation ended with Jihoon preparing to present spec updates, though the transcript ended before those updates could be shared.

Jihoon introduced three changes, including execution APIs, payload attributes event, and a Q&A session on adding IL bit list back. He explained the updates to payload status V2, specifying that a Boolean flag indicating IL compliance is sufficient, and outlined changes to the new payload and FCU. Mikhail and Jihoon plan to merge the execution API changes this week or next week, and Jihoon mentioned seeking resources to help with execution spec tests. The team discussed options for handling payload attributes event, including modifying the engine API, modifying the payload attributes event, or adding IL bit list as a top-level field, and sought input on the preferred direction.

Nico and Jihoon discussed keeping the bits in the specification, with Jihoon confirming it would be added back after considering the implementation details. They tentatively agreed on option three as the least invasive change, which would only require changes in the CL and could be adopted by Bill Dorff. The discussion then shifted to explaining the rationale for adding back IL bit lists, focusing on a scenario where a winning builder missed an IL, leading to a payload reorg and potential enforcement to pay. They explored how the bit list aligns incentives for proposers in both trustless and trusted payment cases.

Jihoon explained two potential implementations for handling block acceptance with bit lists, one involving testers voting for parents and another regarding trustless payments. He discussed how the new design could potentially improve liveness under specific conditions, particularly when the winning builder couldn’t listen to some IL, which caused a payload reorg. Jihoon emphasized that while the bit list approach focuses on correctness and soundness, the actual benefits depend on the probability of certain conditions being met.

The group discussed the potential risks and benefits of implementing a bit list mechanism to ensure IL compliance in block proposals. Jihoon explained that while the mechanism could improve liveness and align incentives for proposers, it would add complexity to the protocol, particularly regarding fork choice. The discussion highlighted that in ideal scenarios where both proposers and builders are honest, the bit list would not be necessary, but it becomes relevant in cases where there are discrepancies in IL compliance. Justin Florentine and Justin Traglia questioned the value of the bit list, given that builders could still potentially lie about their compliance, and raised concerns about potentially harming proposers financially. The group agreed that more discussion would be needed once a candidate specification is prepared.

The team discussed implementing a bit list feature, with Nico proposing a minimal approach where proposers select bits as a superset of their view and assume honesty from both proposers and builders. Jihoon clarified that no consensus has been reached yet on whether to include the bit list in fork choice, and the team agreed to start by implementing it in the container only while exploring different implementation options. The conversation ended with plans to proceed with the engine API spec 609 merge and for Jihoon to explore possible bit list implementations for future discussion.

The team discussed implementing bitlists in the fork choice mechanism, with Jihoon explaining that the complexity of the protocol needs further exploration before making decisions. Justin raised concerns about potential micro-censorship risks if fork choice preferentially selects blocks with more thorough bitlists, though Nico clarified that the head selection process already locks in a parent before considering bitlists. The team agreed to reschedule the next breakout meeting to the 21st due to Jihoon’s upcoming absence, and discussed updating implementations to GLAM 6 for local interop testing.

Next Steps:

  • Jihoon: Merge the engine API spec 609 (payload status V2) this week or next week.
  • Jihoon: Find resources from Steel to help with execution spec tests after the spec is merged.
  • Jihoon: Add a comment to the consensus spec regarding payload enclosure satisfaction for not validated payloads.
  • Jihoon: Tentatively implement option 3 for the payload attributes event (add IL bit list as a top-level field in the event).
  • Jihoon: Explore possible implementations for including the IL bit list in the fork choice and discuss in future breakouts.
  • All clients (e.g., Lowestar, Lighthouse): Rebase on Clan 6 (Glam 6) and apply new spec changes for local interop testing.
  • All: Prepare for the next breakout meeting on the 21st.

Recording Access:

4

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

5

FOCIL spec is nearly ripe.

Development Updates

  • Teku: Mehdi integrated the latest Glamsterdam changes into the FOCIL branch but could not interop with Lodestar because of the builder execution requests added recently. Teku expects interop to work again once builder execution requests land in the other clients.

  • Lodestar: needs to rebase on glamsterdam-devnet-6.

  • ethrex: needs to rebase on glamsterdam-devnet-6.

Spec Updates

engine API change

  • PayloadStatusV2 is introduced with a new inclusionListSatisfied field, a boolean flag indicating whether the payload satisfies the IL constraints. Since we only care about the IL compliance of the tip, a boolean is enough. It is set to null when the payload is not VALID.

  • The EL must retain the IL transactions for an ACCEPTED payload so the CL can have the same IL view after moving to a different branch. When a newPayload is called with a block from a different branch, the EL stores the corresponding ILs, and later when an FCU picks up that branch, it returns whether the tip is IL-compliant. Only the tip matters, so the EL can drop ILs for ACCEPTED payloads that are no longer at the tip and does not have to run the IL check for intermediate payloads.

  • Mikhail and Jihoon have been working on this engine API change and believe it is in the final stage, aiming to merge it this week or next. Once it is merged, Jihoon will get resources from STEEL to help with execution spec tests.

CL spec change

  • The consensus spec will add a comment clarifying that is_payload_inclusion_list_satisfied returns true for NOT_VALIDATED payloads.

payload_attributes event

  • For the payload_attributes event that builders use to start block building, people agreed to go with the option suggested by Nico that adds the IL bitlist to the event as a top-level field. This is the minimal change and people can revisit it later if more changes are preferred.

The IL bitlist

  • The IL bitlist was removed at the previous breakout but there was a discussion of adding it back. People looked at it through various lens such as trusted and trustless payments, incentives and liveness. No rough consensus was reached.

  • The bitlist will be added back to the bid container but not yet enforced in fork choice. In the meantime, Jihoon will explore possible spec candidates and bring options to the table for further discussion.

The Next Breakout Schedule

  • The next breakout moves back one week to July 21st.
1 Like