Lodestar's Position on Hegota

The Lodestar team has spent the past few weeks reviewing the proposed Hegota EIPs, and we want to share our thoughts and why.

Our position is rooted in one firm belief: Hegota should be a small fork that ships fast.

Everything below flows from this critical stipulation. We want the technical barrier to be testing and not implementation. All the features/EIPs we suggest for inclusion are well-defined and have little ambiguity that could delay the timeline. After a long Glamsterdam cycle, we believe the network is best served by a lean, focused upgrade that can be delivered without delays.

Ideally we see Hegota shipping to mainnet sometime in May or June of 2027. Working backwards, that puts the first testnets in March or April, and even earlier will be better. Allowing 3-4 months of devnets means they need to start in December or January. With FOCIL devnets now on the horizon, that leaves 3-4 months for developing non-headlining features (granted, the holidays will be during this time, so the cadence will be slower).

There is major work on the horizon, most critically post-quantum readiness, along with deeper restructuring of the consensus layer, and every additional EIP we pack into Hegota is time, coordination and most importantly, focus taken away from that runway. The proposals we support most strongly are those that either prepare the network for what is coming or simplify the protocol so that the bigger changes land on a cleaner foundation.

How we ranked

Each member of our team independently ranked the proposed EIPs. We then came together, put all of the boards side by side, and worked through each proposal until we agreed on our team position. Each of us still has our public discord. The tiers below apply to Hegota specifically and are our statement about this fork:

• S: must ship. We believe Hegota is incomplete without it.
• A: strongly support. We want it in and expect to commit resources to it.
• B: support if the timeline allows. Small, low-coordination items that shouldn't delay the fork.
• C: support only with qualifications. We are open to these, but only under specific conditions or with more data.

We reviewed all CL proposals on the forkcast rank page. Any that we did not feel belonged in Hegota are listed below under a separate ranking methodology for our vision of future forks. That longer-term outlook can be found separately at the bottom of this post.

S tier: We strongly support shipping these

EIP-8015: Remove deposit and eth1data fields

Since Electra, validator deposits flow through execution-layer deposit requests, leaving the legacy eth1data voting mechanism and its associated fields as dead weight in the beacon state and block. Removing them is a pure simplification: less state, fewer code paths, and no user-facing impact. This was an easy call as the team was unanimous.

EIP-8365: BLS withdrawal credential retirement

This is the item we feel urgency about, and the urgency is social rather than technical. Retiring 0x00 (BLS) withdrawal credentials is a necessary step on the path to a post-quantum-secure Ethereum, and it is one of the few steps that depends on action from users rather than from client teams. Anything that requires the broader community to act needs years of runway to accommodate stragglers who move slowly, and some only move when the protocol makes the status quo stop working.

We see this as the first stage of a deliberate, multi-fork retirement: stop the bleeding now by closing the door on new 0x00 credentials, and give existing validators a long, clearly signalled window to rotate to 0x01/0x02 credentials. This will give us the time to sequence the harder question of eventual balance sunsets into later forks. Starting the clock in Hegota is what makes that later timeline equitable.

There is a small discussion still ongoing within our team, and one we think the broader core group should discuss, about the exit of 0x00 validators. As the EIP is written now, it both disallows new 0x00 and removes existing 0x00 validators from active duties. We see a case for potentially splitting those two pieces so that the exit happens in another fork. There has been some very positive support for exiting though so we want to escalate this part of the discussion for H* inclusion.

A tier: strongly support with some refinement

EIP-8333: Align Checkpoint with Epoch Boundary Block

This one needed almost no discussion as every member of the team independently ranked it at the top of their board. Aligning checkpoints with epoch boundaries removes a long-standing source of confusion and complexity in fork choice and checkpoint handling. It also eliminates a class of edge cases that every client currently has to reason about and test around. It is exactly the kind of simplification we want to see land before the larger consensus-layer changes ahead.

B tier: support if the timeline allows

We like both of these and expect to commit resources to them, but neither is worth delaying the fork over. We think these should be considered, but not SFI'd until after the major pieces of the fork are well tested, and we are potentially waiting for the EL side to finish.

EIP-8025: Optional Execution Proofs

This adds an optional gossip topic for execution proofs with no consensus change at all. It is groundwork for a future where nodes can verify execution without re-executing every payload, and the implementation burden on clients is minimal. It is low-cost and has meaningful upside.

EIP-8379: Top-up Sync

A modest Engine API refinement that returns richer feedback when the consensus layer feeds payloads to the execution layer, allowing the CL to drive syncing and treat the EL as more of a companion process. What we like most is the shape of the change: it doesn't lock the network into a particular sync architecture and it opens the door to sync strategies we want to explore without requiring heavy protocol changes.

C tier: support only with qualifications

EIP-8198: Quick Slots

Our position here is nuanced, so we want to state it carefully: we support adding the machinery to make slot time configurable, and we are open to shortening slot time from 12 seconds, but there is a caveat. Shortening the slot times is purely a matter of tuning the client, not of the complexity of making the constant configurable. Slot time depends on a large number of protocol parameters and deadlines, and these do not scale linearly. The hot code paths that will need to be optimized are non-deterministic and will require careful optimization across a potentially very large cross-section of the codebase. You cannot reduce the slot time and simply expect that every timeout will work identically. Getting the knob into the codebase now means the change can be exercised and measured in isolated testing benches before any devnet/testnet decision, which is where a consideration like this should be made.

The caveat is that we want to get all other features built, including the changes to make slot times configurable. And if there is time before the spec for decoupled-consensus and the PQ key registry are ready, we are open to working on performance optimizations needed to shorten slot times. That is "the big if"; work on I* needs to not be ready, so we need to stay busy, and then we will optimize our hot paths to accommodate shorter slots.

This feels a bit backwards, though. The work a node does is not evenly distributed across the whole slot. There are definitely hot periods where the node is CPU-bound and periods with little work on the cores. This timing has changed with epbs and will change again when we reach decoupled consensus. Spending a lot of development time optimizing hot paths when they will likely change in I* seems inefficient.

We are strong advocates of shorter slot times and agree that it will benefit Ethereum, but it's a matter of prioritization. We think that if it's possible to get a jump on the PQ work, that will be a bigger benefit to the ecosystem. It's a matter of pushing back the slot, shortening maybe 6 months to I*.

This is one more small thing that we want to add to this narrative. There have been some changes to the EIP that have made it far more complicated in recent days and weeks. We are against the complexity and question the usefulness of a slot-duration schedule, as well as other details that will need simplification before we are comfortable proceeding.

EIP-8334: Bundled Attestation Propagation

Reducing attestation gossip traffic is a worthwhile goal, and this proposal builds naturally on the partial-message propagation work already underway. But we want to see measurements before committing: how much bandwidth does it actually save, and at what cost in code complexity? If its champions bring data, we're ready to listen, analyze and implement if appropriate.

EIP-7716: Anti-correlation attestation penalties

In premise, penalizing correlated failures pushes the network toward the diversity we all want, and if the math checks out, the lift on the client side is small. We had initial hesitation, but the methodology was recently fixed by Oisin at Obol. A client bug that takes a large cohort offline gets penalized extra, while minority clients and well-architected operators with diversified infrastructure barely notice. With the updated, clear, and data-backed statement of exactly what behaviour this is meant to discourage, we are interested in seeing this ship if there is time.

Ship small, ship fast

Hegota, as we see it, is a few must-ship items, a handful of cheap wins, and a clear runway for the work that matters most. Q-Day is an existential threat to the chain, and we are laser-focused on ensuring that the roadmap is delivered with plenty of time to spare. We'd rather deliver H* in Q2 2027 than deliver more stuff that does not get us closer to the PQ goal in Q4.

We're publishing this to invite discussion, not to end it. If you disagree with a placement or think we've missed something, we want to hear from you. You can join our Discord and chat with us.

Looking beyond Hegota

Everything below is our longer-term outlook. These are the proposals we reviewed that we feel do not belong in Hegota. The question here is no longer "does this fit in the next fork" but rather "do we want this at all, and when", so the tiers mean something different:

• S: a must have. Likely lands in the very next fork.
• A: a strong want for the next fork. Needs more work, discussion or refinement before it is ready.
• B: we believe this needs to be done. There is still a lot to discuss and it should only get scheduled once the idea is fully defined and the edge cases are resolved.
• C: we like the idea in premise. These are nice-to-haves, but we are not sure how or when they should be done. They should not be considered until fully verified through data-driven analysis.
• D: we do not like these at all. They should never be included.

Nothing landed in S or A this time around, and we think that is telling. The truly urgent items are already in our Hegota list above, and only if the ones above don't get into H would they fall back to I*.

B tier

EIP-8367: Balance sunset for retired BLS validators

This is the endgame of the BLS retirement we want started in Hegota, and it has to happen eventually for post-quantum security. The hard part is that it touches user funds, which means the timeline has to be generous, clearly telegraphed and debated well beyond the core dev community. Sequencing matters here: EIP-8365 starts the clock, and the sunset should only arrive after stakers have had years of runway and q-day is approaching.

C tier

EIP-8148: Custom sweep threshold for validators

This one has an actual user asking for it, which counts for something. Real demand is more than many proposals can claim. But it adds a new field to all million-plus validator record in the state, plus more machinery to the staking workflow. Most of what it offers can be handled at the application layer today. We like the intent, and we are not convinced it clears the complexity bar.

EIP-8341: Partial Execution Payload Commitments

Essentially, a delayed state root is revived. It looks simple on paper, but bids no longer committing to the state root may break unstated invariants that client code quietly relies on. Gloas already buys builders more time to build and propagate payloads, so we do not feel any urgency. Worth investigating once the ePBS dust has settled.

EIP-8371: RowDAS - Distributed Blob Reconstruction

We agree with the direction. The network should gradually move away from relying on super nodes to reconstruct everything, and sharding the reconstruction work is a reasonable way to get there. This adds a lot of complexity to custody, storage, and the partial-message propagation work that is still in flight. There is also a fair amount of research that leaves the open question of how effective this will be exactly. Only real-world numbers can prove that, and even then, the benefit has to be weighed against the feature's extremely high complexity.

D tier

We will keep these short. We don't like them and think they should not be considered in their current form for future forks.

• EIP-8363: Tapered Issuance Burn. Changing staking economics ripple through the entire ecosystem and demand real rigour. The reasoning in this proposal does not meet that bar, and the curve it picks feels arbitrary. A change of this magnitude needs broad debate with the wider stakeholder community, with actual economic analysis on the table, before it shows up on any fork list.
• EIP-8142: Block-in-Blobs. We do not see the problem this solves.
• EIP-8146: Block Access List Sidecars. Builders are unlikely to ever reveal access lists early because doing so leaks state, which undermines the entire premise.
• EIP-8205: Withdrawal credentials preregistration. This is an application-layer concern and does not belong in the protocol.
• EIP-8237: Independent CL/EL Sync. It locks the network into a sync architecture we are not sure anyone wants, adds a new accumulator to the beacon block and drags EL hashing formats into the CL. Top-up sync gets us the benefit with nothing more than an Engine API change.
• EIP-8243: Batching Attestations at Source. It favours economies of scale, since large operators can sidestep it entirely by consolidating keys, and it plays poorly with the signature schemes that come with post-quantum work.
• EIP-8321: Hash-Chain RANDAO. It's a novel idea, but we are not fully convinced by the approach. Perhaps with some modification, this can be revived.
• EIP-8359: Beacon Block Reporting Field. Client distribution tracking is not a protocol problem, and graffiti already exists for exactly this kind of thing. Only @matthewkeil likes this, and he likes it a lot. No one else does.
• EIP-8375: ePBS Mandatory Burn of Execution Rewards. As specified, it can be gamed, which makes it dead on arrival. The underlying goal has merit, but it is not exclusive to this EIP.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, infrastructure development & operations, and co-development.

ChainSafe creates solutions for developers and teams across web3. As part of our mission to build accessible, improved tooling for developers, ChainSafe embodies an open source, community-guided ethos to advance the future of the internet.

Website | Youtube | Twitter | Linkedin | GitHub