Inconsistent Summaries, Broken ToC Links & Unwanted Emojis Across Resources Page Blogs

[yashkamalchaturvedi]

Describe the bug
Several inconsistencies & errors are observed across the Resources page blogs:

• Quick summaries look different across blogs, and some look “weird” or incorrectly formatted.
• Table of Contents (ToC) does not work consistently — some sections do not link properly.
• Certain blogs show altered or incorrect content compared to the originally published version.
• Emojis are being added automatically where they should not appear.
• Some summaries are missing or replaced with unrelated/incorrect text.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Resources page.
2. Open different blogs (e.g., Motivation, Education, Security Considerations, Conclusion).
3. Observe that:
   • ToC links like Motivation & Education do not work, while Conclusion does.
   • Quick summary formatting is inconsistent across blogs.
   • Emojis appear in some blogs where none were added.
   • Content in blogs does not match the original.
4. See errors & inconsistencies.

Expected behavior

• Quick summaries should appear consistent across all blogs.
• ToC should function properly for every blog.
• Content should remain exactly as published (unaltered, without unwanted additions).
• Emojis should not appear unless manually added by the author.
• Each blog's summary should reflect the correct, concise version of its content.

Screenshots
https://www.loom.com/share/425235fe1be54e4285d4d7797e20d809?sid=95c41a1f-1767-4ee6-851e-6df97471b9ff

[yashkamalchaturvedi]

@dhanushlnaik fix the https://eipsinsight.com/resources page. It is not working properly. https://eipsinsight.com/Blogs/glamsterdam-scope-narrows-as-core-devs-confirm-cfi-dfi

1. Cover Image was not uploaded
2. Image URL is also not showing
3. Same goes with auth role.

[yashkamalchaturvedi]

Glamsterdam Scope Narrows as Core Devs Confirm CFI & DFI

The path toward Ethereum’s Glamsterdam upgrade became clearer after core developers gathered for a high-level scoping session to sort more than 40 EIPs into CFI or DFI status. What had been a broad and somewhat chaotic list of proposals was narrowed into a more manageable set, giving teams a firmer sense of direction.

The meeting was not intended for deep technical debate on every proposal. Instead, it served as a strategic checkpoint to identify which items were mature enough to advance and which required additional design work or external dependencies.

With Ethereum undergoing rapid innovation across MEV research, PBS discussions, state growth initiatives and execution-layer refinements, such scoping has become essential for predictable upgrade cycles.

• EIPs Marked CFI
• EIPs Marked DFI
• Unresolved Themes Requiring Deeper Alignment
• Path Forward

EIPs Marked CFI

The call produced a focused list of EIPs that received sufficient consensus to move ahead as Glamsterdam candidates. These proposals are considered technically stable, low-risk, or strategically important for the network’s future.

1. EIP-7778: Block Gas Accounting Without Refunds
2. EIP-7708: ETH Transfer Logs
3. EIP-7843: Slot Number Opcode
4. EIP-8024: SWAP/DUP/EXCHANGE Opcodes
5. EIP-8070: Sparse Blob Pool

Together, these decisions give Glamsterdam clearer edges and highlight the network’s focus on simplifying gas mechanics, improving execution flexibility and preparing for future timing or blob-related changes.

EIPs Marked DFI

Several proposals were deferred due to complexity, incomplete design, lack of cohesive direction, or dependencies on external standardization efforts. These items may re-enter consideration later but are not suitable for Glamsterdam at this stage.

1. EIP-8011: Multidimensional Gas
2. EIPs 8053, 8059, 8057: Gas Precision and Locality
3. EIPs 7791, 7819, 7979, 8013: Opcode Improvements
4. EIP-7619: Falcon PQ Signatures
5. EIPs 7932, 8030, 6404, 6466: Signature and SSZ Proposals

DFI decisions ensure the upgrade remains lean, manageable and aligned with well-understood engineering priorities.

Unresolved Themes Requiring Deeper Alignment

While the CFI/DFI sorting resolved many questions, it also highlighted broader architectural topics that require more research and coordination.

Current gas repricing proposals are considered too monolithic. Developers agreed that the approach must be broken into cleaner, modular components to avoid unnecessary coupling and reduce implementation risk.

Several contributors submitted alternate models for handling long-term state growth. Instead of selecting one prematurely, developers marked the issue for structured comparative study.

Two approaches remain under consideration: a simple increase to contract size limits or a more complex chunk-based mobilization model. Both could significantly impact developer experience and require deeper analysis.

With EIP-7708 advancing, related improvements such as EIP-7745 must be reconsidered. ETH transfer logs change the assumptions underlying indexing and may reduce the need for additional log-level features.

Multiple signature and PQ-related EIPs were deferred, revealing the absence of a cohesive PQ security strategy. Ethereum must align on a single path before incorporating PQ-ready primitives.

Some proposals relate more to ecosystem infrastructure than to the protocol itself. Developers must decide which of these deserve formal signaling.

Path Forward

The scoping session successfully fulfilled its purpose: removing ambiguity and creating a clearer upgrade blueprint. By filtering proposals early, core developers can now focus their resources on areas with the strongest alignment and most immediate value.

This type of structured scoping reflects growing maturity in Ethereum’s upgrade processes. It reduces the risk of proposals lingering in undefined states and helps maintain predictable development cycles, which are essential for client teams, researchers and the broader ecosystem.

While several areas require deeper coordination, the CFI and DFI decisions provide a stable foundation for the next development phase. Glamsterdam remains on course, with a more manageable scope and clearer direction for both execution and consensus layers.

[yashkamalchaturvedi]

[yashkamalchaturvedi]

1. https://eipsinsight.com/Blogs/eip-proposal-builder-validation-legacy
2. https://eipsinsight.com/Blogs/gas-limit-cap-eip-7825
3. https://eipsinsight.com/Blogs/ePBS-EIP-7732

[Old blogs are not looking that great too]

[yashkamalchaturvedi]

@dhanushlnaik any ETA on this?

[yashkamalchaturvedi]

Tentative Scoping Timeline for Ethereum's Heka/Bogotá Upgrade

Ethereum core developers have released a tentative scoping timeline for the upcoming Heka/Bogotá network upgrade, captured in EIP-8081. Shared by Ethereum Foundation researcher Alex Stokes (ralexstokes), the meta-thread outlines how Ethereum will scope the fork, when proposals will be evaluated, & what decision will finalize the upgrade’s contents.

The timeline is explicitly tentative, with room for modification after the Fusaka retrospective & additional process refinements as Glamsterdam reaches mainnet.

• Why This Timeline Matters
• Phase One: Fork Focus & Headliner Proposals (Jan 8–Feb 4)
• Phase Two: Headliner Discussion & Finalization (Feb 5–Feb 26)
• Phase Three: Non-Headliner EIP Proposals (From Feb 27)

Why This Timeline Matters

Ethereum’s upgrade process has matured from informal coordination into a more structured, milestone-based model. Publishing a scoping timeline early helps Ethereum:

• reduce late-stage surprises .
• create predictability for implementers.
• focus debate on the highest-impact goals first.
• widen legitimacy by requiring broader ecosystem input.

Phase One: Fork Focus & Headliner Proposals (Jan 8–Feb 4)

The first window is designed to define high-level goals for Heka/Bogotá. During this period, ACDE/ACDC calls are expected to focus less on individual EIP mechanics & more on what the fork should prioritize.

A core concept here is the “headliner proposal.” Headliners represent the major themes that could define the upgrade’s identity. Examples could include themes like improving node sustainability, mitigating state growth, or strengthening protocol efficiency.

Key process requirements include:

1. Headliner champions must open an Ethereum Magicians thread with a TBD tag.
2. The thread must be posted at least 48 hours before the ACD call where they want to present.
3. A fully drafted EIP is not required at this stage
4. Broad objectives are allowed if they are clear & defensible (for example, “reduce disk requirements for nodes”).

This phase is designed to surface ambitious ideas early, before the upgrade scope hardens. EIP-8081 emphasizes that headliner champions must go beyond developer preference & gather evidence of broader support.

While ACD calls can provide guidance on which stakeholders to consult, the champion is responsible for:

• identifying impacted groups.
• gathering feedback.
• showing credible signals of support.
• presenting trade-offs in a way the ecosystem can evaluate.

Phase Two: Headliner Discussion & Finalization (Feb 5–Feb 26)

Once headliner candidates are identified, Ethereum core developers plan to spend the next phase evaluating them in detail. This window will focus on technical feasibility, execution-layer & consensus-layer impacts, and risk & complexity assessment of proposed headliners.

It will also incorporate community feedback while ensuring alignment with Ethereum’s longer-term roadmap. By the end of this phase, core developers aim to finalize which headliner feature(s) will define Heka/Bogotá.

Phase Three: Non-Headliner EIP Proposals (From Feb 27)

After headliners are finalized, attention shifts to non-headliner EIPs. These are generally smaller improvements or complementary changes that fit the upgrade’s goals without defining its narrative.

EIP-8081 indicates that the process here will broadly follow the Glamsterdam scoping framework, helping maintain consistency across upgrades while keeping the scope controlled.

EIP-8081 also references Ethereum’s key inclusion checkpoints:

• CFI (Considered for Inclusion): formal shortlist decision for non-headliner EIPs
• SFI (Selected for Inclusion): final decision on what ships in the upgrade

Exact dates are still TBD, but the governance structure is intended to follow the same model used for Glamsterdam.

Even though EIP-8081 does not change Ethereum’s protocol directly, it is meaningful because it formalizes a disciplined approach to decision-making. Ethereum’s roadmap is increasingly shaped not only by technical possibility, but also by what is procedurally sustainable.

While the schedule remains tentative, EIP-8081 sets a clear direction: Ethereum wants upgrades that move fast, but do so predictably, with early clarity on what matters most.

[yashkamalchaturvedi]

[yashkamalchaturvedi]

@dhanushlnaik please add these 2 blogs

[yashkamalchaturvedi]

Why Ethereum Core Developers Removed FOCIL from the Glamsterdam Upgrade

Ethereum core developers have confirmed that FOCIL (Fork-Choice enforced Inclusion Lists) will not ship in the upcoming Glamsterdam upgrade, despite strong technical support from Layer-2 teams, censorship-resistance researchers, & intent-based protocol designers. The decision, finalized during ACDC #171, was not driven by a newly discovered security flaw or a loss of confidence in FOCIL’s goals.

Instead, it reflects a process-first governance choice as Ethereum transitions to a more structured & predictable upgrade pipeline.

• FOCIL’s Value Was Not in Question
• The Core Tension Was Governance, Not Engineering
• Community Support Created Pressure, Not Consensus
• Why Glamsterdam Moved Forward Without It

FOCIL’s Value Was Not in Question

FOCIL is designed to strengthen Ethereum’s censorship-resistance by enforcing transaction inclusion guarantees at the fork-choice level. Research discussed during the call indicated that FOCIL can improve censorship-resistance economics by nearly an order of magnitude in certain attack models, dramatically increasing the cost for attackers attempting sustained censorship while keeping user costs relatively low.

The feature has particular importance for protocols that rely on time-sensitive transaction inclusion, including:

• Optimistic rollups
• Intent settlement layers
• Prediction markets
• Exit windows in staking & bridging protocols
• Any system with fraud-proofs or challenge-period timers

As a result, many ecosystem participants viewed FOCIL as a natural fit for Glamsterdam.

The Core Tension Was Governance, Not Engineering

The longest & most contentious discussion of ACDC #171 focused on how FOCIL was being advanced, not whether it should exist. Ethereum has recently adopted a headliner-first upgrade process, explicitly designed to reduce scope creep, last-minute surprises, & repeated delays that plagued earlier forks.

Under this new process, major protocol changes are expected to compete transparently for inclusion during defined scoping windows. Several developers argued that pre-declaring FOCIL’s inclusion risked bypassing these shared rules, even if the feature itself was valuable.

One recurring theme during the debate was that credible commitments to ship a feature must not override the governance framework itself. In other words, Ethereum’s long-term scalability depends not only on technical correctness, but also on predictable & trusted decision-making.

Community Support Created Pressure, Not Consensus

FOCIL enjoys unusually broad support across advanced protocol designers, especially those building censorship-sensitive systems. That support, however, also created pressure to accelerate inclusion without fully resolving disagreements about scope, timelines, & architectural implications.

Core developers acknowledged that community fatigue had set in after extended debates across multiple calls. Ironically, that fatigue reinforced the case for sticking to the new governance process rather than bending it under pressure.

Rather than rejecting FOCIL outright, the call converged on a compromise that preserves momentum without destabilizing Glamsterdam:

• FOCIL is DFI (Deferred for Inclusion) for Glamsterdam, meaning it will not ship in this fork
• FOCIL is CFI (Considered for Inclusion) for HEKA, the following upgrade

This outcome ensures FOCIL receives dedicated analysis, structured debate, & proper headliner consideration, rather than being rushed into a fork whose scope was already nearing lock-in.

Why Glamsterdam Moved Forward Without It

By the end of ACDC #171, Glamsterdam’s scope was effectively finalized. With Trustless Payments confirmed to remain in the fork, & several other ePBS-related components already consuming review bandwidth, developers agreed that adding FOCIL would re-open scoping risks at exactly the wrong moment.

FOCIL is now positioned as a serious HEKA candidate, not an abandoned proposal. Its deferral signals that Ethereum’s core developers are prioritizing process legitimacy & upgrade stability, even when that means postponing widely supported features.

[yashkamalchaturvedi]

[yashkamalchaturvedi]

@dhanushlnaik check Ghost Mirroring to resolve this.