**Date:** 2026 / 04 / 30
**Hosts:** Thomas, Jihoon
**Time:** 11:00

**Context:** Implementation-focused working session for EIP-7805 (Fork-choice enforced Inclusion Lists), now scheduled for the Glamsterdam/Hegotá upgrade. Mechanism design is largely settled; the meeting focused on implementation, open spec questions, and a target of reaching a FOCIL devnet-0 by end of week.

## 1. Mechanism-Level Discussion

### 1.1 State Access for IL Validation (Privacy Protocols / "Branches")
- Vitalik raised whether FOCIL validation should support transactions touching state outside a constrained "box" (e.g., privacy protocol nullifiers).
- **Trade-off:** support full state access (requires Merkle proofs in transactions) vs. limited state with Bloom filters / scoped proofs.
- Decision hinges on **includer hardware assumptions**: if includers can hold significant state, fewer proofs are needed; if includers should run on minimal hardware (broad participation), branch-serving infrastructure is required.
- **No decision** — flagged for further work.

### 1.2 FOCIL × Frame Transactions (EIP-7702 / AA Compatibility)
The core problem: with frame/AA transactions, a tx that's invalid at one point in block execution can become valid later (state dependency between txs).

Two approaches considered for proving non-inclusion eligibility:
1. **O(n²) re-execution** by the builder — worst case quadratic, balloons verify gas costs. Rejected.
2. **Index-based bookmark approach (preferred)** — builder provides a small object stating "I attempted IL tx X at block index Y and it failed." Attesters verify only at that index.

**Consensus:** Go with the index-based approach. Extra complexity is worth it because it permits a higher verify-gas-limit and broader 7702 use cases.

**Sandwich/invalidation attack concerns** were dismissed for normal use cases — only the tx originator controls nonce/balance. Pathological cases (e.g., zero-slippage checks in verify phase) are explicitly **out of scope** for FOCIL; users can route those through builders/custom mempools.

**Action item:** Need more eyes reviewing the "FOCIL-native account abstraction compatibility" writeup to validate the index-based design.

## 2. Network Object for Index Proofs

**Question (Jihoon):** The index-based approach introduces a new network object alongside the block. Where does it live?

- It's small (bitfield-style: indexes only for *excluded* IL txs).
- ILs themselves are explicitly **not on chain**; should this proof be?
- **Etan** initially favored on-chain (signed, cast-verified); **Justin** clarified the natural place is the **payload envelope** — signed, broadcast, but *not retained on chain*. Hash in header, data ditched after ~1 slot (analogous to how BALs are now handled).
- **Resolution:** Put it in the envelope, retain only for ~1 slot. Attesters consume it during payload verification then discard.

## 3. Latest Spec Walkthrough (Jihoon)

### 3.1 Three Components
1. **IL Committee Selection** — bug fixed; spec now matches EIP. Committee is `IL_COMMITTEE_SIZE = 16`, derived from beacon committee (16 × 32 members) with a 2-epoch lookahead, allowing reuse of cached beacon committee data.
2. **IL Construction & Broadcast** — includers broadcast by **t = 8s** (arbitrary, tunable).
3. **View Freeze Semantics:**
- Attesters: stop storing ILs at t = 8s.
- Proposer: superset view — may store ILs received later (e.g., t = 9s) so late ILs are still considered when building the next slot's payload.

### 3.2 ePBS Timing Alignment
- 8s IL deadline sits 1s before the t = 9s PTC deadline, giving the proposer leeway to fold in late ILs and trigger an EL payload update.

### 3.3 IL Freshness & EIP-8146 (BAL broadcast separation)
- Proposal: broadcast BALs at ~3–4s into the slot, decoupled from full payload, so includers can update state and build fresh ILs without waiting on the full payload.
- **Justin pushed back:** at 12-second slots, there's plenty of slack (payload ~4s, PTC ~9–11s) — separating BAL is unnecessary now. Treat as a **wildcard** for shorter-slot futures.
- **Tomasz** raised that if BAL is broadcast independently, it needs a self-validating mechanism (e.g., embed the block hash / state root it corresponds to). Currently BAL validity is implicit via execution context.

## 4. Implementation Status

| Client | Status |
|---|---|
| **Lodestar** | Running Kurtosis local devnet with BESU; functional. |
| **BESU** | Integration working with Lodestar; debugging "IL too large" build bug. EL-spec tests passing except where they conflict with EIP-7732 baseline. |
| **Lighthouse** | Branch is ~1.5 years old (originally on Fulu); rebasing onto Hesi/Glamsterdam. Targeting "something working tomorrow." |

**CL-side complexity:** Reported as small/additive — ILs come from EL, no significant new storage. ~"few weeks of work."

**devnet-0 requirement:** 2 CLs + 2 ELs. Lodestar↔Lighthouse interop **not yet tested**. Inter-op with glamsterdam-devnet-0; will move to glamsterdam-devnet-1 once stabilized.

**Testing roadmap (Jihoon's priority):** Extend Hivetest for IL-specific cases (size limits, fork-choice compliance with IL+payload combinations). End-to-end tests across CL+EL combined with fork choice are the top priority for the next several months.

## 5. Open Spec Questions Resolved/Discussed

### 5.1 Non-Finality Behavior
**Decision:** Disable FOCIL during non-finality, mirroring proposer-boost circuit-breaker behavior.

- **Trigger:** No finality for **2 epochs** (i.e., didn't justify current epoch + didn't finalize previous).
- **Rationale (Justin):** During forks, IL committee shuffling can diverge across branches. Validating ILs already requires checking the includer's committee membership — adding shuffling-disambiguation on top of attestation handling during a fork would risk client instability.

### 5.2 IL Bit List in the Builder Bid
**Decision:** Keep the bit list (16 bits — small, safe for global topic propagation).

**Use cases (Justin):**
1. Allows the proposer to verify the bid's IL coverage is a **superset of the freeze-time view** (not the proposer's own — must match attester deadline).
2. Provides a **signed commitment** from the builder; if a builder signs "I will satisfy this bit list" and then ships a payload that censors, that builder can be **circuit-broken / blacklisted** by the network.

### 5.3 IL Construction Heuristics
- Spec leaves this client-defined (per EIP-7805) to encourage diversity.
- **Dimensions discussed:** priority fee, mempool dwell time, transaction size.
- **Justin's key suggestion:** **Reorged-out transactions should land on every honest IL** — provides a strong signal against hard censorship reorgs and is detectable.
- **BESU:** plans plugin-based heuristic system (with sane defaults) so builders/operators can swap strategies. Justin warned this risks creating a market for "buying IL inclusion."
- **Open coordination question (Julian):** how much **overlap** vs. **coverage** across ILs? Less overlap = more aggregate coverage but less redundancy. Per-client heuristics need protocol-level coordination on this trade-off (echoes the marchhill / aelowsson concerns on the Magicians thread about deterministic heuristics collapsing all 16 ILs into one).
- Vitalik's idea: stateful heuristics (e.g., transactions unincluded for 2+ slots get force-included by all includers).

### 5.4 Mempool Sharding (raised by Etan)
- Native-AA scaling may push toward mempool sharding.
- Tunable parameters: number of includers, IL size cap (currently `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB`, ~one blob's worth).
- If the mempool is sharded, "16 includers per shard" may be too much — needs revisiting. Compatible in principle, but parameters require re-tuning.

## 6. Engine API / FCU Interaction (Justin)

A subtle issue raised: under FOCIL, an EL receives a payload via `engine_newPayload` and replies whether the IL is satisfied. If **not** satisfied, the CL should *not* send `engine_forkchoiceUpdated` (because that block isn't its head — it must be reorged out).

**Current behavior across clients:**
- **Prysm:** auto-sends FCU whenever a payload extends the head, *without* running fork choice. This will need to change.
- **Lighthouse, Lodestar:** already run fork choice and then send FCU — should adapt more easily.

**Implication:** Post-Glamsterdam, the rule "payload extending head = head" no longer holds because of conditional IL satisfaction. CLs that bypass fork choice on the fast path will need engineering work.

A side discussion explored what to do when **finality advances over a region containing payloads but the tip has no payload** — Lighthouse's pattern (run fork choice, compare full FCU message, only resend if changed) was identified as a clean approach.

## 7. Action Items & Timeline

| Item | Owner |
|---|---|
| Debug BESU oversized IL bug | BESU dev |
| Lighthouse rebase + Glamsterdam port | Lighthouse |
| Lodestar ↔ Lighthouse interop test | Lodestar / Lighthouse |
| devnet-0 target | All — by end of week |
| More eyes on FOCIL × frame tx (index-based design) | Open call |
| Spec review (CL, EL, engine API) | Open call |
| Hivetest extensions for IL size, fork-choice scenarios | Jihoon + Steel |
| BAL self-validation mechanism (block hash binding) | Tomasz / spec |
| Coordination on IL overlap policy across EL clients | Future discussion |

## 8. Notable Sentiment

- Spec has been stable for ~1.5 years; mechanism is settled.
- Implementation effort is **dwarfed by ePBS**, which is consuming most client bandwidth — a recurring concern raised about resource availability.
- General optimism: FOCIL has working local devnets that already survived the Fulu→Hesi fork transition, so fewer surprises are expected vs. ePBS.