**Date:** 2026 / 04 / 29
**Hosts:** Ansgar / Nixo
**Time:** 13:30

## 1. Headliner Process

### 1.1 Definitional Ambiguity
No shared definition of "headliner" exists across participants. Competing definitions surfaced:
- **Most important feature** regardless of size
- **Biggest feature** in the fork
- **Feature for which the fork would be delayed**
- **A theme rather than a specific EIP**

Summarized tension: *themes are underspecified, EIPs are overspecified.*

### 1.2 Reported Benefits
- **External communications:** Provides a clear narrative for the fork (community, app developers, infrastructure providers).
- **Community engagement:** Concrete EIPs trigger meaningful community feedback. Cited Flashbots' ePBS free-option concerns surfacing because ePBS was a headliner; without that designation, feedback would have come at testnet stage.
- **Focus:** Forces selection of "the most important thing"
- **Scoping containment:** Original aim was to prevent Pectra-style scope explosion (one headliner per layer).
- **Schedule flexibility:** Headliners can be selected earlier (e.g., ePBS) or later than the standard non-headliner window, working around the EIP's needs.

### 1.3 Reported Drawbacks
- **Meta-discussion overhead:** Significant time spent debating *whether something qualifies as a headliner*, used as a loophole to reject EIPs ("we already have a headliner").
- **PR rejection vector:** Noted EIPs being rejected on grounds of headliner conflict rather than technical merit.
- **Insufficient ambition:** Argument that the most-vocal-minority-opposed dynamic stalls progress; Hegotá shipped no headliner, missing opportunities like encrypted mempools.
- **Premature EIP commitment:** Coupling the headliner concept 1:1 with a specific EIP locks in scope before scope is understood.
- **Schedule pressure:** Hegotá headliner pressure was driven by an unrealistic cadence assumption (Glamsterdam was already slipping past the assumed June ship date).

### 1.4 Theme vs. EIP Debate
**Pro-theme arguments:**
- Decouple problem statement from solution.
- Allows pipelining: theme could be declared 2–3 forks ahead, expanding the solution pool.
- Prevents premature solution lock-in (account abstraction was cited as a recurring example where competing solutions are debated without prior alignment on the problem).
- One framing: *theme = external focus (what problem); headliner EIPs = internal focus (which solutions).*

**Pro-EIP arguments:**
- Themes without candidate solutions are vacuous; community engagement and prototyping/testing/specs require a concrete artifact.
- Pandaops cannot spin devnets per candidate EIP.
- Themes "follow" EIPs in practice (e.g., ePBS + BALs → scaling theme).

**Hybrid proposals:**
- Theme + candidate solution, with explicit acceptance that the solution may change.
- New EIP category for "high-level design / problem definition documents".
- Account abstraction as a *theme-headliner* example: select the theme now, lock the specific EIP (e.g., frame transactions) months later.

### 1.5 Temperature Check
A clear majority preferred to **retain the headliner construct** rather than revert to no formal EIP distinction. Strong pushback against adding a *theme layer on top of* the existing headliner layer — argued it either adds bureaucratic overhead or shifts the process top-down.

### 1.6 Client Preparedness Issue
One individual raised that on the AA discussion, Erigon submitted *two divergent positions*.
Suggestion: when a topic is flagged as a likely headliner, client teams should be formally required to converge internally before the decision call.

---

## 2. The Straw Map

### 2.1 Stated Purpose (per Ansgar)
- A **conversation starter**, not a governance artifact.
- Explicitly named "straw map" (not "roadmap") to signal non-binding status.
- Provides visibility into long-horizon work that would otherwise happen invisibly.

### 2.2 Concerns Raised
- Insufficient detail at the EIP/link level to evaluate intent without external research.
- Limited buy-in process; participated in January but the current straw map differs significantly from what he agreed to. Risk that external observers treat it as canonical ("word of God").
- Decisions are *already* being made with reference to straw-map assumptions (e.g., today's technical decision referenced single-binary clients as a future state, even though this is not a ratified direction). Media amplification compounds the canonicalization risk.
- Years and fork assignments past 2026 should be removed.
- The artifact is presented as marching orders, not research directions.
- Framing argument: focus only on the next 2 forks; long-term should be a list of major 5–10 year goals + dependencies, not a per-fork schedule.

### 2.3 Counter-Arguments
- Long-term direction (e.g., 1000x scaling via ZK verification, dynamic state replacement strategies) materially affects current-fork decisions. Cannot be reduced to a 1–2 fork window.
- Higher friction to change long-term direction is a *feature*, not a bug — prevents flip-flopping.
- Concrete example — should not ship a feature that makes ZK-EVM impossible, then undo it next fork. Awareness ≠ constraint.
- Permissionless protocol — anyone dissatisfied can submit a competing roadmap.

### 2.4 Rough Consensus
- More transparency into ongoing workstreams: **good.**
- Current presentation (per-fork year assignments stretching to 2029): **controversial, likely needs softening.**
- The map should *inform* but not *constrain* multi-year-out decisions.

---

## 3. Non-Headliner Prioritization

### 3.1 S-Tier Ranking System
Broad agreement that the S-tier ranking system worked well for Glamsterdam selection.

### 3.2 Proposal: Cap Client EIP Review Burden
Proposed clients only submit a *top EIPs list* rather than reviewing 50+ EIPs.

Some pushback:
- Reviewing EIPs *is* core dev work; reduces quality gate.
- Raises the bar for non-core-dev/non-researcher EIP authors.
- Outcome would be determined by lobbying skill rather than merit.

### 3.3 EIP Justification / Stakeholder feedback
Guillaume argued EIPs should require demonstrated use cases (entrepreneurship analogy). Cited Rex/EOF as the rare positive example of upfront customer discovery.

**Counterpoint:** Risk of professional lobbying class drowning out diffuse stakeholder voices. Preferred direction: ACDE-side proactive outreach to apps/users, presenting candidate lists for impact assessment.

- Some valuable EIPs have inherently diffuse beneficiaries (e.g., self-destruct removal) and don't fit a customer-discovery model.
- Flagged the protocol support team's [championing guide](https://ps.ethereum.foundation/guides/champion) for stakeholder outreach.

---

## 4. SFI Redefinition

### 4.1 Problem Statement
Current EIP-7723 SFI definition (included in or planned for next devnet) is non-functional in practice — almost nothing gets SFI'd, and the testing team lacks priority signal. Spencer attempted to raise SFI status across 4 consecutive ACDs without resolution.

### 4.2 [Proposed New SFI Criteria](https://github.com/ethereum/EIPs/pull/11475/changes)
- It has been included in a devnet that has demonstrated stability (e.g., high participation, no critical bugs for ≥1 week)
- The EIP specification is finalized (no placeholder values or pending design decisions)
- It has minimal interactions with other CFI EIPs, OR those interactions have been tested in the same devnet
- Testing coverage is adequate (hive/EEST passing, no known divergence across clients)

### 4.3 Discussion Points
- Geth currently re-merges EIPs into Amsterdam branch only on SFI; current definition is broken for that workflow.
- "Finalized" may be too strict — ongoing changes are normal.
- Wants SFI to remain a *deliberate* decision, not automatic on criteria match.
- Too many EIPs CFI'd this fork; CFI semantics need tightening.

### 4.4 Decision Flow (Emerging Consensus)
- **ACDT:** Tracks criteria, signals when an EIP meets them, no objections from testing perspective.
- **ACDE/ACDC:** Final SFI decision — read out as a notice, objections heard, otherwise approved.
- Rationale: ACDT was created to accelerate testing decisions, not to absorb governance load.

### 4.5 Replacement for Devnet Prioritization Signal
Since SFI no longer drives devnet inclusion, a new mechanism is needed:
- After all non-headliner CFI decisions, the coordinator polls clients (using S-tier output) and the testing team, proposes an ordering on the next ACDE.
- Ordering is reflected in the meta EIP as a living document.
- **Not** strictly binding, but skews devnet inclusion toward the top of the list.

### 4.6 Open Concern
8037 is a counter-example: ranked second-to-last on the S-tier list due to complexity, but ultimately critical for state. A pure ordering-driven devnet pipeline would have deprioritized it. Suggests human override is still needed.

---

## 5. Individual vs. Team Representation on ACD

Temperature check on whether individual core devs should continue to express divergent personal opinions on calls vs. enforcing a unified team position.

**Result:** Majority happy with the current individual-freedom model. No change proposed.

---

## 6. Action Items / Forward Commitments

| Item | Owner | Status |
|---|---|---|
| Headliner process — refine definition, possibly accommodate "theme + candidate EIP" pattern | ACDE leads | Discussion ongoing; no formal change yet |
| Client teams converge internally on likely headliner topics before decision calls | Client teams | Suggested, not mandated |
| Straw map presentation — consider de-emphasizing year/fork assignments past ~2 forks out | EF research | Open |
| New SFI criteria (4-point list) | Nixo / ACDT | Proposed; to be operationalized |
| Devnet prioritization ordering produced after CFI decisions, reflected in meta EIP | Coordinator (Nixo) | New process for Hagota |
| SFI decisions: signaled by ACDT, ratified on ACDE/ACDC | ACDT + ACDE/ACDC | Process change adopted |
| Retrospect on new SFI/prioritization flow after Hagota | ACDE leads | Scheduled implicitly |