FOCIL Breakout #44, October 13, 2026

Protocol Calls & happenings
1

Agenda

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

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

GitHub Issue

2

Meeting Summary:

The FOCIL Breakout meeting focused on updates from various clients and specifications for the Hazy DevNet implementation. Rahul from Lighthouse reported that they had implemented fork choice enforcement and submitted a PR for review, while Iván from EthereX confirmed readiness for JoseDevNet2 with implementation of EIP-8198 using 12-second slots. Jun from the PRISM team shared that they were working on FOCIL implementation and planning to sync with current DevNet testing, while NC from Lowstar mentioned merging several EIPs into their trunk branch and planning to address IL creation timing issues. The team discussed technical details around execution layer (EL) implementation, with Fabio explaining Basel’s approach to building blocks iteratively and handling new inclusion lists. Marc presented updates on fossilized frames implementation, including new claims objects and verification gas limits, though questions remained about the efficiency of the new ID system and potential alternative designs. The conversation ended with a discussion of the breakout schedule, deciding to potentially push back the next meeting to November 17th instead of November 10th due to travel considerations around DEF CON.

Click to expand detailed summary

Jihoon led a discussion about ACDEVnet1, noting that the network is generally healthy but some slots are being missed. Rahul from Lighthouse reported that they had participated in testing with the assumption that payloads would satisfy the inclusion list, but realized they needed fork choice enforcement after diverging from other clients during censorship testing. Rahul mentioned that a PR for adding enforcement was under review and hoped to get merged that week. The team also discussed inactive validators from index 2,200 to 2,206, though no specific cause was identified, and Iván reported that their team was ready for JoseDevNet2 with implementation 8198.

The team discussed updates on various client implementations for the upcoming HEISA-DEFINIT 2. Jihoon mentioned plans to test slot reduction to 10 seconds locally for zkVM2 and requested two versions of the implementation. Jun from the PRISM team reported progress on FOCIL implementation and plans to sync with the current DevNet. NC from Lowestar reported merging several EIPs into their trunk branch and identified a need to change IL creation timing. Marc from Nethermine shared progress on frames and fossil specs implementation, noting the need to review EIP 8198.

The team discussed a race condition issue with payload execution and IL creation, where Nico explained they currently use the payload available event but trigger IL creation too early, potentially building it incorrectly on the parent. NC confirmed that their implementation follows the spec by trying to eagerly run the execution payload first, then creating the IL, but falling back to creating IL without execution if that fails. Nico also mentioned that their FOCILDEFNET1 branch was accidentally broken by merging trunk, but they successfully tested quick slots with 10-second slots on Hazy, though the team needs to determine the long-term plan for maintaining separate branches.

Jihoon discussed updates to the EIP, which was rebased to Hazy from Falu, and mentioned several PRs related to SAW2 and fossil changes. The team agreed to keep devnet1 running until devnet2 is ready. Nico raised concerns about branch management and the efficiency of ELs in applying new transactions on top of sealed payloads, questioning how quickly ELs can process these additional transactions.

The team discussed how ELs (Execution Layers) are implemented in the building process, with Fabio explaining that in their case, the block building process already includes iterations where the EL continues to build a better block considering new inclusion lists. Jihoon raised questions about optimization strategies for IL compliance and suggested the possibility of implementing a building strategy that could quickly adapt to new ILs without running the entire building process again. The discussion included technical questions about payload resealing and fork choice updates, though specific answers were not provided in the transcript.

Fabio explained the process of building a minimal block that includes only the ELs received, which should be faster than previous iterations and allows for quicker response to getPayload requests. He also mentioned that these ELs are sent to the public transaction pool for bulk building in an optimistic manner. Jihoon inquired about the possibility of transaction order changes in previous building cycles, to which Fabio responded that while it could happen in some implementation-specific cases, it likely wouldn’t be a significant issue.

The team discussed the timing of EL (Execution Layer) payload revisions and calls. Nico asked about the current process for calling getPayload and FCU on Glamsterdam, and Jihoon explained that the timing depends on when fork choice update and getPayload are called, as well as the EL building duration. They discussed the trade-offs between giving EL enough time to produce a good payload and ensuring the payload is produced on the correct head, with Nico suggesting a potential adjustment to call prepare payload later at around 10 seconds in the previous slot.

The team discussed the implementation of inclusion lists (ILs) and payload handling, with Jihoon explaining that while local build time might not be significantly affected, the exact performance impact depends on how Execution Layers (ELs) handle ILs. Fabio raised a question about normal cases where a new payload might be called with different inclusion lists, but Jihoon clarified that such cases should not occur since testers freeze their IL view nine seconds before calling the payload. The conversation ended with Jihoon preparing to move to the discussion of Fossilized Brains, with Mark having prepared materials for review.

Marc provided a summary of his work on implementing Tomas’ informational EIP, focusing on handling Profile 2 transactions within frame transactions. He explained the addition of a new claims object that maps transaction hashes to evaluation indices specified by builders, along with a new ID to bind execution payloads. Marc also described the introduction of a membership bitmap to handle computation limits per inclusion list to prevent one proposer from consuming all validation gas. He requested that the specifications be reviewed, particularly by EtherX.

Jihoon asked about the expected number of frame transactions that could be executed with a 1 million gas limit. While Marc and others provided some estimates, including 50 regular transactions and 2-3 privacy transactions, the exact numbers remained unclear. Iván mentioned that he would look into the details but was unlikely to provide an answer that week.

The team discussed transaction handling and verification processes, focusing on whether the CL or EL should handle transaction mapping and validation. Jihoon proposed letting the EL handle all transaction-related operations as a cleaner design, though this would increase engine API bandwidth consumption. The discussion also covered the enforcement of the 1 million verified gas limit per frame transaction per IL, which requires mapping at the EL level. Marc noted that the new ID proposal might not be necessary if the alternative approach is taken, and the team agreed more feedback from CL and EL developers would be helpful. Nico raised a question about censoring builders and how they should work, specifically questioning whether an empty payload approach was appropriate.

The team discussed the current capabilities of their builder, noting that it is not yet updated for FOCIL. They considered using DevNet in the future to develop censoring payloads similar to Death Star. The group reviewed the upcoming DevNet schedule, deciding to maintain the next call in two weeks but push the following call back to November 17th instead of November 10th. There was discussion about whether FOCIL breakouts would still be needed given the development of Hazzy Dev Net 2 and ACDT, though the timing of this transition remains uncertain.

Next Steps:

  • Rahul: Get the PR for fork choice enforcement in the Redwood branch reviewed and merged this week.
  • Iván: Implement two versions of the slot timing (12 seconds and 10 seconds) for zkVM2 testing.
  • Jun: Rebase Terrence’s FOCIL implementation, make it running in the current DevNet, and sync with the current DevNet for testing.
  • NC: Merge the FOCIL branch into the trunk branch in the next couple of days to be ready for Hazy definite two.
  • NC: Change the implementation to create ILs after the execution payload is executed, not when it is received.
  • Marc: Look into EIP-8198 to see if it requires EL changes.
  • Nico: Fix the FOCILDEFNET1 branch which was accidentally broken by merging the trunk branch.
  • Marc: Gather feedback from CL and EL devs on the proposed fossilized frames specs, especially regarding the new ID and membership bitmap.
  • Jihoon: Schedule the next breakout for two weeks from now, and the one after that for November 17th.

Recording Access:

3

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