All Core Devs - Execution (ACDE) #224, November 6, 2025

[nixorokish]

UTC Date & Time

November 06, 2025, 14:00 UTC

Agenda

• Fusaka
  • reminder: please add the relevant coordinators from your client team to this doc for the Fusaka upgrade
  • testnet updates
  • mainnet rollout
• Glamsterdam
  • H* naming
  • process update, see comment by @ralexstokes
    • FOCIL discussions on ACDC
    • STEEL testing complexity assessment prioritization
  • brief summary of initial client positions
    • Nethermind
    • Geth
    • Erigon
    • Reth (updated)
    • Nimbus (Pureth)
  • repricing breakout results
    • case for repricings by @casparschwa and @adietrichs
    • bundle options by @misilva73
    • recommendations by @MariusVanDerWijden
  • DFI / CFI candidate selections
• WELDing the STEEL

Call Series

All Core Devs - Execution

🔧 Meeting Configuration

Duration

90 minutes

Occurrence Rate

bi-weekly

Use Custom Meeting Link (Optional)

• I will provide my own meeting link

Facilitator Emails (Optional)

No response

Display Zoom Link in Calendar Invite (Optional)

• Display Zoom link in invite

YouTube Livestream Link (Optional)

• Create YouTube livestream link

[github-actions]

⚡ Protocol Call Resources:

✅ Zoom: Join Meeting
✅ Calendar: Add to Calendar
✅ Discourse: Discussion Topic
✅ YouTube Live: Watch Live

[Carsons-Eels]

The STEEL team would like to add this to the agenda

• WELDing the STEEL: EELS + EEST merger, changes and updates

[abcoathup]

Portmanteau wanted for Heka + Bogotá upgrade after Glamsterdam

[LukaszRozmej]

Nethermind opinion on Glamsterdam EIPs: https://x.com/URozmej/status/1986040895578296825

[fjl]

Geth ranking of Glamsterdam EIPs: https://notes.ethereum.org/@fjl/geth-glamsterdam-eip-ranking

[etan-status]

Light client perspective of Glamsterdam EIPs: https://pureth.guide/glamsterdam

A couple notes on some popular proposals, as I won't be on the call.

EIP-7708: ETH transfers emit a log

• Misses 0-value tx, fees (regular + priority), and withdrawal credits. Is it useful enough standalone for G*?
• Prio fees (separate recipient than regular fee!) means having hundreds of extra micro-payments per block. Prio fees also bad for scaling due to continuous write lock on fee recipient balance
• EIP-7799 consolidates all prio payments, impacts mevboost builder as the prio fee can only be spent in the next block
• Parts could be:
  • (a) EIP-7708 + 0-value tx add-on, allow enumerating all tx where the wallet was involved in
  • (b) EIP-7799 for fees + withdrawals. Note this changes block header (maybe better in H*)

EIP-7745: Trustless log index

• The EIP is super important, but rushing for a June release is too early.
• Very tricky to implement correctly, involves database, reorg handling, and complex data structure.
• Proof format still in progress, network sync protocol missing, non-standard SSZ usage (list with different element types, holes in list, 6466 Log container and 7916 ProgressiveList need bumps to latest specs)
• Parts could be:
  • (a) Implement any accelerated eth_getLogs index in ELs. Does not need coordination
  • (b) Finish the proof format, validate it against Purifiers (Helios, Nimbus); iterate until efficient
  • (c) Kurtosis config to get the root hashes to match, thorough testing with reorgs and pathologic scenarios
  • (d) Decide on storing root hash in block header vs zk-based alternative, and implement the sync.

EIP-7668: Remove bloom filters

• Backwards-compatible alternative: Only drop the computation, replace with all-1's value (100% false positive).
• EIP-6466 also drops logsBloom, but further enables proofs of partial data (reducing L2 complexity), and avoids repeated breakage for dApp buidlers / L2s.
• Parts could be:
  • (a) EIP-6466 receipts to drop receipt bloom field
  • (b) Replace the block header logsBloom with all-1's (backwards compatible)
  • (c) Future: Drop block header logsBloom when going full SSZ, or replace with EIP-7745 logIndexRoot.

[ralexstokes]

reposting here

was talking with Ansgar about the best way to approach and i think we should do the following for the glam scoping segment of thursday's call:

• each client team has an opportunity to present a high-level (< 1 min) overview of any EIPs they strongly support
• we go through all EL EIPs and try to gain consensus on a DFI candidate list (and after doing this and previous point we may also get some sense of a CFI candidate list)

this should give everyone more info to make a 2nd pass to refine their team's selections for the next ACDE where we can continue the conversation

[yperbasis]

Erigon's team view on Glamsterdam: https://github.com/erigontech/erigon/wiki/Glamsterdam-PFI-stand

[jochem-brouwer]

Erigon's team view on Glamsterdam: https://github.com/erigontech/erigon/wiki/Glamsterdam-PFI-stand

It states EIP-7610 is implemented already, but note that this is not yet part of the protocol and this EIP is intended to be shipped in to make this part of the protocol. As the EIP state, EIP-161 (which we shipped a long time ago) states that only the codeHash/nonce/balance fields should be checked for the contract creation operation, but not the storage. EIP-7610 makes the storage also part of the protocol. It is a somewhat theoretical case, but with enough computing power an address collision could happen, and there are accounts on mainnet which have storage but the other fields empty.

[yperbasis]

@jochem-brouwer EIP-7610 is already implemented in geth (ethereum/go-ethereum#28912), erigon (erigontech/erigon#14672) and probably all other clients. It's also implemented in execution-spec-tests (ethereum/execution-spec-tests#636). It's activated retroactively. So it's already part of the protocol rather than a candidate for Glamsterdam

[jenpaff]

Reth team EIP priority list https://hackmd.io/@jenpaff/S1bj9gqkbe