ACDC2026-10-15_189

AllCoreDevs - Consensus #189

2026-10-15 6 decisions 801 transcript lines

Transcript

Follow along

Everstake CircleBack
Iryna is using Circleback (https://circleback.ai) to record and generate AI meeting notes for this meeting.
Dima Gusakov | Lido
Gm people
Daniel Knopik
gm
Iván | ethrex
gm
Satyajit
gm
Povilas Liubauskas
gm
meditationduck
gm
cayman
gm
Pavel | MixBytes
Gm
stokes
https://github.com/ethereum/pm/issues/2247
Barnabas
time for hoodi!
Nico Flaig
Replying to "time for hoodi!" https://builder-hoodi.nflaig.dev/ ready
Mario Vega
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
Dima Gusakov | Lido
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
Mega | ethlambda
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
Barnabas
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
felipe
Reacted to "https://builder-ho..." with 🔥
Enrico Del Fante
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
Satyajit
Reacted to "https://builder-ho..." with 🔥
Iván | ethrex
Reacted to "https://builder-hood..." with 🔥
Cambridge
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
NC
Reacted to "time for hoodi!" with 🚢
Nico Flaig
Reacted to "time for hoodi!" with 🚢
Luca Donno | L2BEAT
Reacted to "https://builder-hoodi.nflaig.dev/ ready" with 🔥
Povilas Liubauskas
Reacted to "https://builder-ho..." with 🔥
Barnabas
one small note: https://dora.glamsterdam-devnet-12.ethpandaops.io launched yesterday, shutting down today. We did a bunch of builder deposits with invalid deposits, and everyone did OK.
Enrico Del Fante
We will tomorrow
kingy
we're planning to LH release early next week
felipe
Reacted to "one small note: ht..." with 👍
Stefan Starflinger
Reacted to "one small note: https://dora.glamsterdam-devnet-12.ethpandaops.io launched yesterday, shutting down today. We did a bunch of builder deposits with invalid deposits, and everyone did OK." with 👍
saulius
Grandine hopefully tomorrow, otherwise early next week.
Dima Gusakov | Lido
Excited for Hoodi!
Povilas Liubauskas
Reacted to "one small note: ht..." with 👍
Cambridge
To be clear, deposits after the 0xB0 deposit, right?
Barnabas
I’d vote keeping the protocol simpler. Validator entities have/will work around this. I don’t think we should optimize the protocol for validator entities. Also this is way too late to make such change. And this is also a non issue post gloas.
Matthew Keil
Replying to "I’d vote keeping the..." 100% agreed
Nico Flaig
you can proof that the deposit went to the builder, but worth being aware of, this should be solved by the app layer, not the protocol at this point in time
Tomer Ganor
They should be orthogonal
Cambridge
Reacted to "you can proof that the deposit went to the builder, but worth being aware of, this should be solved by the app layer, not the protocol at this point in time" with 👍
Barnabas
Reacted to "you can proof that the deposit went to the builder, but worth being aware of, this should be solved by the app layer, not the protocol at this point in time" with 👍
Luca Donno | L2BEAT
Reacted to "you can proof that the deposit went to the builder, but worth being aware of, this should be solved by the app layer, not the protocol at this point in time" with 👍
Tomer Ganor
You should not change the on-chain code to deal with this
terence
Reacted to "you can proof that the deposit went to the builder, but worth being aware of, this should be solved by the app layer, not the protocol at this point in time" with 👍
terence
Reacted to "I’d vote keeping the protocol simpler. Validator entities have/will work around this. I don’t think we should optimize the protocol for validator entities. Also this is way too late to make such change. And this is also a non issue post gloas." with 👍
Matthew Keil
Its too late to fix this at this point
cayman
I hated the validator and builder deposit coupling. But it was the direction that we took so that builders could be onboarded and active at the fork. Imo too late to change now.
Tomer Ganor
But this does not make sense
Tomer Ganor
Why should you care about this change?
Nico Flaig
I would support this if it was 1-2 months earlier, but we literally stress tested these code paths today
lightclient
we already shipped this to sepolia dog
Barnabas
Reacted to "we already shipped this to sepolia dog" with 💀
Luca Donno | L2BEAT
Reacted to "we already shipped this to sepolia dog" with 💀
Cambridge
Reacted to "we already shipped this to sepolia dog" with 💀
kingy
the main reason we're not keen is the amount of testing we've done on the current approach would need to be repeated
spencer
Reacted to "we already shipped..." with 💀
james
Based on the release process need to push hoodi back several weeks
Cambridge
It would be consensus breaking though
Tomer Ganor
Replying to "It would be consensu..." Why?
Nico Flaig
@Dima Gusakov | Lido did you check how that change interacts with deposit caches of clients? and run attacks against clients?
kingy
the onboarding cache has had bugs and would need to be retested
kingy
Reacted to "@Dima Gusakov | Li..." with 👍
james
We are not going to release tomorrow if we want this in…
Cambridge
Replying to "It would be consensu..." Depending on the pending deposits at the fork, it could result in a different state. Right? What was a builder would be a validator.
Nico Flaig
if we want this change I suggest we move hoodi back a few weeks, we already cut our 1.50 hoodi release and operators already running it
Cambridge
Replying to "It would be consensu..." If only 50% of clients make this change, it will cause a split. Therefore it’s consensus breaking.
james
Reacted to "if we want this change I suggest we move hoodi back a few weeks, we already cut our 1.50 hoodi release and operators already running it" with 👍
Cambridge
Reacted to "if we want this change I suggest we move hoodi back a few weeks, we already cut our 1.50 hoodi release and operators already running it" with 👍
Barnabas
Reacted to "if we want this change I suggest we move hoodi back a few weeks, we already cut our 1.50 hoodi release and operators already running it" with 👍
Dima Gusakov | Lido
I’m sorry that this is that late
jaczkal
I do not have a view how much effort it is to include this at this moment, but I see it as cleaner solution than how it is behaving now
Dima Gusakov | Lido
But it is what it is
james
Do we want to not release hoodi tomorrow then?
Cambridge
We should make the call today imo
james
If we want breakout tomorrow
Potuz
Oh I came fashionably late
Mario Vega
Reacted to "We should make the call today imo" with 👍🏼
Dima Gusakov | Lido
Reacted to "Oh I came fashionably late" with 😂
Oisin Kyne
Reacted to "Oh I came fashionabl..." with ➕
Cambridge
Reacted to "Oh I came fashionably late" with 😂
Kalo | Obol
Reacted to "Oh I came fashionabl..." with 😂
Dima Gusakov | Lido
Replying to "Oh I came fashionabl..." Typical potuz
felipe
Reacted to "Oh I came fashiona..." with 😅
Dima Gusakov | Lido
Replying to "Oh I came fashionabl..." lol
Potuz
Replying to "Oh I came fashionabl..." Still sleepy
Greg K | Lido
Reacted to "Oh I came fashionably late" with 😂
spencer
can it wait until hegota? it will be a fast fork 😅
Dima Gusakov | Lido
Reacted to "Still sleepy" with ❤️
Nico Flaig
eip 8282 solved it after the fork
Greg K | Lido
Reacted to "eip 8282 solved it after the fork" with 👍
Cambridge
Reacted to "eip 8282 solved it after the fork" with 👍
Mario Vega
Reacted to "can it wait until hegota? it will be a fast fork 😅" with 🔥
Luca Donno | L2BEAT
Reacted to "can it wait until hegota? it will be a fast fork 😅" with 🔥
spencer
Reacted to "eip 8282 solved it..." with 😅
james
Reacted to "We should make the call today imo" with 👍🏼
Cambridge
Doesn’t this assume a malicious insider? Which also has access to the validator private keys?
Luca Donno | L2BEAT
Reacted to "if we want this change I suggest we move hoodi back a few weeks, we already cut our 1.50 hoodi release and operators already running it" with 👍
Dima Gusakov | Lido
Reacted to "eip 8282 solved it after the fork" with 😅
Matthew Keil
Reacted to "We should make the c..." with 👍🏼
Luca Donno | L2BEAT
Reacted to "We should make the call today imo" with 👍🏼
Dima Gusakov | Lido
Replying to "Doesn’t this assume ..." It assumes delegated staking for sure
Miguel Tenorio
Reacted to "Oh I came fashionably late" with 😂
Dima Gusakov | Lido
Replying to "Doesn’t this assume ..." And an attack within this scheme
Barnabas
Replying to "Doesn’t this assume ..." so its a delegated staking issue, not a protocol issue imho
Maria Silva
Reacted to "can it wait until hegota? it will be a fast fork 😅" with 😅
Dima Gusakov | Lido
Replying to "Doesn’t this assume ..." c’mon
Dima Gusakov | Lido
Replying to "Doesn’t this assume ..." You can not get away with just saying that!
Dima Gusakov | Lido
Reacted to "so its a delegated staking issue, not a protocol issue imho" with 😂
spencer
Reacted to "so its a delegated..." with 😂
terence
Reacted to "so its a delegated staking issue, not a protocol issue imho" with 😂
Greg K | Lido
Reacted to "so its a delegated staking issue, not a protocol issue imho" with 😂
Barnabas
Reacted to "eip 8282 solved it after the fork" with 👍
Luca Donno | L2BEAT
Reacted to "so its a delegated staking issue, not a protocol issue imho" with 😂
james
Reacted to "so its a delegated staking issue, not a protocol issue imho" with 😂
Cambridge
Re the onboarding builder issue. It’s possible we make this change after the Hoodi upgrade and before the Mainnet upgrade. But it would be risky and it would require a lot of testing. We cannot do this before the Hoodi upgrade though, as it might cause a split. It’s just unclear to me if it’s worth the risk.
Barnabas
https://github.com/ethereum/EIPs/pull/12513
Nico Flaig
new landing page on https://builder-hoodi.nflaig.dev/
Luca | Vero
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 🔥
Jun Song
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 😂
Jun Song
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 🔥
Oisin Kyne
Reacted to "new landing page on ..." with 🔥
Kalo | Obol
Reacted to "new landing page on ..." with 🔥
Luca Donno | L2BEAT
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 🔥
Barnabas
I do
marc | wolovim
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 🪩
Barnabas
I don’t like burning eth for mistakes
marc | wolovim
CL client takes: https://forkcast.org/upgrade/hegota/client-priority/?quick=cl
Iván | ethrex
Reacted to "CL client takes: htt..." with 🙏
Kalo | Obol
Replying to "new landing page on ..." So that’s how you’ve utilised your wealth from being monopoly builder on sepolia
NC
Invalid signature, wrong pubkeys, wrong source address all these lead to financial loss. Protocol is just unforgiving by nature
Trent Van Epps
yep looks good
Nico Flaig
Reacted to "So that’s how you’ve..." with 😂
Mario Vega
Reacted to "So that’s how you’ve utilised your wealth from being monopoly builder on sepolia" with 😂
Mario Vega
Reacted to "new landing page on https://builder-hoodi.nflaig.dev/" with 🪩
Oisin Kyne
On CFI decisions: Correlated downtime penalties (7716) got its 2026 update merged now. https://eips.ethereum.org/EIPS/eip-7716 This site answers faqs and gives a model to play with the numbers to get a feel for the update versus status quo. https://validatordowntime.obol.org/ Hoping teams will CFI this EIP today and keep it around in a B-type grade to pick up later down the hegota shipping schedule. :) (Happy to share screen and run through it briefly if we get to 7716 today).
Potuz
Reacted to "So that’s how you’ve utilised your wealth from being monopoly builder on sepolia" with 😂
Manu
Prysm EIP-8025 - Optional proofs PR: https://github.com/OffchainLabs/prysm/pull/17690
Iván | ethrex
Hive dashboard: https://eth-act.github.io/eest-execution-witness-dashboard/#/group/tests-zkevm%20v21.0.1
Luca | Vero
Friendly reminder for CL devs to please take a look at the last Gloas-related Beacon API PR - produceBlockV4WithBid https://github.com/ethereum/beacon-APIs/pull/627 🙏
lightclient
If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects
kingy
Replying to "If we’re so worri..." oh no
Oisin Kyne
Reacted to "If we’re so worried ..." with 👎🏽
Iván | ethrex
Replying to "If we’re so worried ..." This one is important too 😅
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" it’s years away from being ready
Łukasz Rozmej
Reacted to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" with 👎🏽
Iván | ethrex
Replying to "If we’re so worried ..." Mandatory proofs maybe
Iván | ethrex
Replying to "If we’re so worried ..." This is the first step
Luca Donno | L2BEAT
Reacted to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" with 👎🏽
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" just ship optional proofs without a core eip
Toni Wahrstätter
Reacted to "just ship optional proofs without a core eip" with 👍
Iván | ethrex
Replying to "If we’re so worried ..." We need client teams commitments
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" no you dont
Iván | ethrex
Replying to "If we’re so worried ..." So the opt-in feature is there for those who want to opt-in
kingy
Replying to "If we’re so worri..." can someone open a prediction market for execution proofs vs breaking ecdsa
Oisin Kyne
Reacted to "just ship optional p..." with 👍
Luca Donno | L2BEAT
Reacted to "So the opt-in feature is there for those who want to opt-in" with 👍
kingy
Reacted to "just ship optional..." with 👍
Łukasz Rozmej
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" I somewhat agree without EIP but then we need process fr integration of experimenta features to the spec, otherwise it is clusterfuck, merge hell ect.
Barnabas
Reacted to "just ship optional proofs without a core eip" with 👍
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" guys claude can rebase things really well
Barnabas
Reacted to "So the opt-in feature is there for those who want to opt-in" with 👍
Łukasz Rozmej
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" regarldess - integrate fast
Barnabas
Reacted to "guys claude can rebase things really well" with 😂
Kevaundray Wedderburn
Reacted to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" with 👎🏽
Daniel Knopik
Reacted to "can someone open a..." with 😄
Dima Gusakov | Lido
Reacted to "guys claude can rebase things really well" with 😂
lightclient
Reacted to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" with 👍
Francesco Risitano (Tau)
Reacted to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" with 👎🏽
lightclient
if people want to opt in, just opt in and not force a core eip through the process
spencer
Bullish on CFI'ing. We can add it to the EELS main branch. and then all EL test releases can contain optional stateless fields in every fixture :D
Iván | ethrex
Replying to "If we’re so worried ..." Let’s give them the chance to opt in from their current setup
Iván | ethrex
Replying to "If we’re so worried ..." No strong reason to keep working on this in parallel
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" yeah there is, we don’t want to bog down PQ work
felipe
It's mostly about process too, not just not wanting experimental changes. Don't want to sponsor EIPs within the exection-specs repo.
spencer
Reacted to "It's mostly about ..." with 👍
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" it’s never been easier to work in parallel
Iván | ethrex
How would this bog down PQ work?
Mario Vega
Reacted to "It's mostly about process too, not just not wanting experimental changes. Don't want to sponsor EIPs within the exection-specs repo." with 👍
Kevaundray Wedderburn
Reacted to "It's mostly about process too, not just not wanting experimental changes. Don't want to sponsor EIPs within the exection-specs repo." with 👍
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" because it will cause more people to deal with the eip who don’t need to
Toni Wahrstätter
Could we make an exception in the specs repo, or make it an ERC? If managing branches is the main issue this might be simpler.
Iván | ethrex
Replying to "If we’re so worried ..." It’s almost ready on all clients
Somnath Banerjee
Processes and coordination could be better. We'll work on that ourselves too amongst teams both clients and provers. Strong Yes on CFI. Zilkworm/Erigon
Oisin Kyne
Reacted to "Could we make an exc..." with 👍🏽
Łukasz Rozmej
Reacted to "It's mostly about process too, not just not wanting experimental changes. Don't want to sponsor EIPs within the exection-specs repo." with 👍
Cambridge
If everything’s a priority, nothing’s a priority
lightclient
Replying to "If we’re so worried about PQ that we’re telling people to go into “bunker mode” I don’t think we should be spending time on non-critical non-PQ topics. Even if it’s “easy”, it will just take more time from people than anyone expects" maybe the interface is but not the actual zkvm
felipe
Replying to "Could we make an e..." oops meant to reply here. These exception is getting community consensus.
Mario Vega
Reacted to "If everything’s a priority, nothing’s a priority" with 👍🏼
Greg K | Lido
Reacted to "If everything’s a priority, nothing’s a priority" with 👍🏼
kingy
We obviously support the work since we've merged it but not sure it needs to be CFI for it to proceed.
Toni Wahrstätter
Community consensus + contaiming the word "optional" 🫡
felipe
Reacted to "Community consensu..." with 😅
spencer
If we are certain that zkEVM will be the future then CFI?
felipe
Reacted to "Community consensu..." with 💯
Barnabas
thats literally the definition of CFI
Barnabas
if there is scope we gonna sfi it
Łukasz Rozmej
If we do not CFI, we should IMO come up with better process for this long running initiatives, to both integrate as well as potentially be removed from the spec
kingy
Reacted to "If we do not CFI, ..." with 👍
lightclient
if we CFI or SFI this i promise people will leverage that to force many more poeple to work and support it and legitimize it in a way that it hasn’t earned yet on its own
Mario Vega
Reacted to "If we do not CFI, we should IMO come up with better process for this long running initiatives, to both integrate as well as potentially be removed from the spec" with 👍
felipe
Reacted to "If we do not CFI, ..." with 👍
felipe
Reacted to "If we do not CFI, ..." with 💯
Luca Donno | L2BEAT
Reacted to "If we do not CFI, we should IMO come up with better process for this long running initiatives, to both integrate as well as potentially be removed from the spec" with 👍
Kevaundray Wedderburn
I think we can change the process after the fact, instead of mid process
spencer
Reacted to "If we do not CFI, ..." with 👍
Maria Silva
Question for Ignacio: would CFI’ing this EIP release resources from your team that could be invested in PQ instead? i.e., your team is working on both zkevm and PQ. And you seem to imply that keeping zkevm up to spec is an additional burden on your team if we don’t CFI. Is this correct?
Nico Flaig
lodestar is working on it on the side either way, not sure cfi would change anything in that regard
Barnabas
Replying to "if we CFI or SFI thi..." I promise I won’t gatekeep if you haven’t implemented optional proofs.
Manu
Same reasoning on prysm side
felipe
Reacted to "I promise I won’t..." with 😅
lightclient
Reacted to "I promise I won’t gatekeep if you haven’t implemented optional proofs." with 😅
ignacio
Replying to "Question for Ignacio: would CFI’ing this EIP release resources from your team that could be invested in PQ instead? i.e., your team is working on both zkevm and PQ. And you seem to imply that keeping zkevm up to spec is an additional burden on your team if we don’t CFI. Is this correct?" Yes, this is why we want to be more efficient in the spec implementation process. It would help on that front too.
Iván | ethrex
https://eth-act.github.io/eest-execution-witness-dashboard/#/group/tests-zkevm%20v21.0.1
Barnabas
Replying to "lodestar is working ..." any reason you guys didn’t put it higher on your rankings then?
Manu
Replying to "lodestar is working ..." Yes, because this EIP does not require a hard fork
lightclient
supporting a feature and passing all the tests means much less these days with AI
Łukasz Rozmej
Replying to "lodestar is working on it on the side either way, not sure cfi would change anything in that regard" Nethermind is working on guest program
kingy
Reacted to "Yes, because this ..." with 👍
Toni Wahrstätter
Reacted to "supporting a feature and passing all the tests means much less these days with AI" with 👍
Potuz
I don’t know about CFIing this or not, but definitely strongly against Ivan’s read of forcing clients to implement a feature that is optional.
Toni Wahrstätter
Reacted to "I don’t know about CFIing this or not, but definitely strongly against Ivan’s read of forcing clients to implement a feature that is optional." with 👍
Barnabas
Replying to "lodestar is working ..." so we have lodestar, prysm, lighthouse, nethermind, ethrex all pushing for it
Łukasz Rozmej
Replying to "supporting a feature and passing all the tests means much less these days with AI" why?
Luca Donno | L2BEAT
Replying to "I don’t know about C..." I always thought that 8025 was optional for users but not for clients to provide to users as an option, did I understand this wrong?
Oisin Kyne
Reacted to "I don’t know about C..." with 👍
cayman
Replying to "lodestar is working ..." Because its not that important to us. I think we rated it as "if we have time"
Potuz
Just the fact that this read is being put out makes me think that we should not CFI this, which shouldn’t have been even proposed as an EIP IMO
lightclient
Replying to "supporting a feature and passing all the tests means much less these days with AI" because you don’t know how correct it really is
spencer
Reacted to "supporting a featu..." with 👍
Barnabas
can we just make a decision and move on please?
Greg K | Lido
Reacted to "I don’t know about CFIing this or not, but definitely strongly against Ivan’s read of forcing clients to implement a feature that is optional." with 👍
Barnabas
we have like 10 more eips to discuss
Łukasz Rozmej
Replying to "supporting a feature and passing all the tests means much less these days with AI" sure but why is that changed from pre-AI?
Iván | ethrex
Reacted to "we have like 10 more..." with 🚢
Kamil Salakhiev
Reacted to "can we just make a decision and move on please?" with 👍
Csaba
My worry is that this has long running and unexplored consequences on client population and hence decentralization.
Luca Donno | L2BEAT
Reacted to "we have like 10 more eips to discuss" with 🚢
Potuz
Replying to "I don’t know about C..." Yes, this was not stated anywhere in the scope of the EIP. This should be considered as checkpoint sync or optimistic syncing, which is not necessary to be implemented by any client.
Łukasz Rozmej
Replying to "supporting a feature and passing all the tests means much less these days with AI" to some extent I am more confident that edge cases were covered
Iván | ethrex
Reacted to "sure but why is that..." with ☝️
Luca Donno | L2BEAT
Reacted to "Yes, this was not stated anywhere in the scope of the EIP. This should be considered as checkpoint sync or optimistic syncing, which is not necessary to be implemented by any client." with 👍
Daniel Knopik
Reacted to "we have like 10 mo..." with 🚢
Toni Wahrstätter
We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already.
felipe
Reacted to "We should be clear..." with 💯
Luca Donno | L2BEAT
Reacted to "We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already." with 👍
Cambridge
Reacted to "We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already." with 💯
lightclient
Reacted to "We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already." with 👍
lightclient
Reacted to "We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already." with 💯
Nico Flaig
Reacted to "We should be clear t..." with 💯
Nico Flaig
Reacted to "We should be clear t..." with 👍
Łukasz Rozmej
IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first.
lightclient
Reacted to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." with 👍
Cambridge
Replying to "IMO Ethereum spec sh..." We do. They exist in the features directory.
Trent Van Epps
Reacted to "We should be clear that CFI'ing, merging specs, and later DFI has sunken costs, sounds easier than it is. Also, hegota is big already." with 👍
lightclient
Reacted to "We do. They exist in the features directory." with ❤️
Potuz
Reacted to "We do. They exist in the features directory." with 👍
lightclient
Replying to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." seems like a nice place for this eip
Greg K | Lido
Reacted to "We do. They exist in the features directory." with 👍
Cambridge
Replying to "IMO Ethereum spec sh..." It’s already there 😅
lightclient
Replying to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." perfect?
Dima Gusakov | Lido
Reacted to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." with 👍
Kevaundray Wedderburn
Replying to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." It’s also on the el too
Mario Vega
Replying to "IMO Ethereum spec sh..." The complain is on the EL specs
spencer
Replying to "IMO Ethereum spec ..." the branching in eels is a pain point
Cambridge
Replying to "IMO Ethereum spec sh..." Ah yeah, that’s true.
spencer
Replying to "IMO Ethereum spec ..." I really want this in the EELS main branch! Can we discuss this next ACDT?
Barnabas
Replying to "IMO Ethereum spec sh..." can’t you guys just merge it in ?
Łukasz Rozmej
can we port it to eels?
lightclient
Reacted to "can’t you guys just merge it in ?" with 👍
Trent Van Epps
Replying to "IMO Ethereum spec sh..." I think the contention is that they dont want to merge until CFId?
spencer
Replying to "IMO Ethereum spec ..." if we are happy to skip process to do so
spencer
Replying to "IMO Ethereum spec ..." personally i am
lightclient
accepting this eip has much bigger impact to ethereum than “making rebasing better” and if you disagree you are being naive
Barnabas
Replying to "IMO Ethereum spec sh..." if we can stop talking about this eip then I’m more than happy to skip the process 😂
Cambridge
Replying to "IMO Ethereum spec sh..." Just to be clear, this is what I’m referring to in the CL specs: https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip8025
Nico Flaig
on the beacon-apis side, we can merge 8025 apis as "experimental" no issue with that if that helps to avoid having to rebase branches
Łukasz Rozmej
Replying to "IMO Ethereum spec should have "Experimental" part of the spec where those things could be integrated first." I mean port the features/experimental integrations somehow?
Potuz
I repeat I am very strongly against Enrico’s read too
Kevaundray Wedderburn
Replying to "accepting this eip has much bigger impact to ethereum than “making rebasing better” and if you disagree you are being naive" What are the bigger impacts?
Mario Vega
Replying to "IMO Ethereum spec sh..." It’s already on eels, it’s on its branch, projects/zkevm, the complain here is that we merge all our work to the main development branch and then projects/zkevm has to be rebased
spencer
Replying to "IMO Ethereum spec ..." the lift on zkevm team and us will be worth it, plus future integration with PBT, also benchmarking... we have pbt/zkevm/benchmarking... creating a nasty matrix of branches that build on new EIPs
Kevaundray Wedderburn
Replying to "accepting this eip has much bigger impact to ethereum than “making rebasing better” and if you disagree you are being naive" Especially if clients are going to do it anyways
Potuz
I think the issue here is whether the branch should be merged in Heze or not. And if we do, then we would need to make sure that anything that merges into any fork is compatible with it
ignacio
Which CL are against CFIing? Can we clarify that?
lightclient
Reacted to "I think the issue here is whether the branch should be merged in Heze or not. And if we do, then we would need to make sure that anything that merges into any fork is compatible with it" with 👍
Iván | ethrex
Reacted to "Which CL are against..." with ☝️
Enrico Del Fante
Ok so we can even sfi but doesn't mean that all cleints has to support
Nico Flaig
we also have partial eip 8025 changes on our trunk branch but it's separate from heze
Csaba
My issue with the optionality is this sentence: “Proof-verifying nodes still re-execute payloads themselves; verified proofs are an additional signal, not a replacement for re-execution.” I can’t reallly understand what this wants to mean for clients.
lightclient
which CL clients want to passionately fight for it? that’s the bar we should be having for eips, not lukewarm lack of disagreement
Mario Vega
This, what Potuz describes, is exactly our issue with the EL Specs
kingy
I agree with potuz on this, we will continue to support this but it's optional and doesn't need hardfork scope
felipe
Reacted to "This, what Potuz d..." with 💯
Toni Wahrstätter
Reacted to "This, what Potuz describes, is exactly our issue with the EL Specs" with 👍
Csaba
Replying to "My issue with the op..." If we want to confront the proof verification with execution, we don’t need to do it on chain live with all its interplay
Toni Wahrstätter
Reacted to "I agree with potuz on this, we will continue to support this but it's optional and doesn't need hardfork scope" with 👍
Enrico Del Fante
Ye i'm at the end agree with potuz
cayman
Reacted to "I agree with potuz o..." with 👍
lightclient
Reacted to "Ye i'm at the end agree with potuz" with 👍
Toni Wahrstätter
Reacted to "Ye i'm at the end agree with potuz" with 👍
Cambridge
Reacted to "Ye i'm at the end agree with potuz" with 👍
Nico Flaig
Replying to "I agree with potuz o..." same reasoning why I don't like to CFI it, I wanna keep it out of heze
Cambridge
Reacted to "I agree with potuz on this, we will continue to support this but it's optional and doesn't need hardfork scope" with 👍
kingy
Reacted to "same reasoning why..." with 👍
Nico Flaig
Reacted to "I agree with potuz o..." with 👍
Toni Wahrstätter
Reacted to "same reasoning why I don't like to CFI it, I wanna keep it out of heze" with 👍
jochem-brouwer (Fairphone)
Create Meta EIP I* and PFI this there?
Mario Vega
We can review our branching process though, we can improve and make it easier for these features function
marc | wolovim
Speedrun time
Cambridge
Reacted to "Speedrun time" with 😄
Dima Gusakov | Lido
NOOOO
Dima Gusakov | Lido
Jesus!
ignacio
Replying to "We can review our branching process though, we can improve and make it easier for these features function" We would have already done that in the last year. I think not CFI gets again into the current reality; so quite sad to see this was the ACD conclusion. :(
Greg K | Lido
Reacted to "Create Meta EIP I* and PFI this there?" with 🫠
Dima Gusakov | Lido
Alex, you are killing me
Barnabas
Replying to "Speedrun time" can we limit each EIP to 60s and try to go through all of them?
Iván | ethrex
Reacted to "to some extent I am ..." with 👍
Barnabas
Could we default to DFI to all these remaining EIPs unless a client team is strongly in favor of CFI?
Dima Gusakov | Lido
Replying to "Could we default to ..." No
Dima Gusakov | Lido
Replying to "Could we default to ..." We need to discuss 8148 and 8205
kingy
also no more gossip sub extensions please
Daniel Knopik
Reacted to "also no more gossi..." with 💯
Csaba
Replying to "also no more gossip ..." What do you mean by that? No networking changes, or no GossipSub?
Łukasz Rozmej
Reacted to "We can review our branching process though, we can improve and make it easier for these features function" with 👍
Daniel Knopik
Replying to "also no more gossi..." i think he means that we should prefer existing gossipsub solutions (e.g. partial message) or work towards a leaner solution that can at some point supercede gossipsub and its weaknesses (e.g. waggle)
kingy
Replying to "also no more gossi..." I would prefer we move away from continuously extending gossip sub and work on waggle yes
cayman
Reacted to "I would prefer we mo..." with 🙏
Daniel Knopik
Reacted to "I would prefer we ..." with 🙏
Csaba
Replying to "also no more gossip ..." We can absolutely do this under the Waggle name, if naming is the important aspect.
Barnabas
I think we need to be reasonable. We trying to save bytes whereever we can. Adding not useful fields into a beacon block thats gonna be gossiped around the network is wasteful.
Enrico Del Fante
Paul is in favour:)
Dima Gusakov | Lido
This EIP is good IMO
Barnabas
Replying to "Paul is in favour:)" too bad he’s sleeping 😂
Enrico Del Fante
Replying to "Paul is in favour:)" LoooL
Dima Gusakov | Lido
Reacted to "LoooL" with 😂
Kalo | Obol
On Obol’s side we are also in favour for what it’s worth
cayman
Reacted to "also no more gossip ..." with 💯
Csaba
Replying to "also no more gossip ..." If instead the mechanism cannot be handled by waggle, it questions whether waggle is ready to support our networking needs (I think it is, just don’t fully understand your point).
Luca | Vero
Replying to "I think we need to b..." the usefulness is knowing how safe mainnet is from a Holesky-like incident. So I wouldn’t call it not useful
Oisin Kyne
https://validatordowntime.obol.org/?event=20
Luca | Vero
Reacted to "On Obol’s side we are also in favour for what it’s worth" with ❤️
Luca | Vero
Reacted to "This EIP is good IMO" with ❤️
Nico Flaig
Reacted to "also no more gossip ..." with 💯
Barnabas
what is the problem we are trying to solve ?
Luca | Vero
Replying to "I think we need to b..." But I accept EIP-8359 data may not be useful enough to add into the protocol. The question then becomes - where should we do so?
Łukasz Rozmej
Replying to "what is the problem we are trying to solve ?" I think increase incentives for dicersity (client, physical location ect)
Dima Gusakov | Lido
Reacted to "I think increase incentives for dicersity (client, physical location ect)" with 💯
Luca | Vero
Reacted to "I think increase incentives for dicersity (client, physical location ect)" with 👍
Luca Donno | L2BEAT
Reacted to "I think increase incentives for dicersity (client, physical location ect)" with 👍
Łukasz Rozmej
Nethermind is not against it, but we are not sure if it will actually change anything, before big outage comes
Nico Flaig
I like the idea behind it and it's pretty simple
Enrico Del Fante
I personally in favour of eips favouring solo stakers and val decentralization. But i agree with ben about touchig points with the other eips changing issuance
Dmitrii Shmatko
Replying to "what is the problem ..." For how long were validators offline in our real Mainnet if we take last year or another period? The rationale looks valid, but it isn’t just happening today, so I’m not sure it could affect real distribution.
Toni Wahrstätter
My feeling is the mechanism is sound and the idea makes sense, but this might be low prio for clients? Would be a low prio cfi, put on a devnet late?
Cambridge
Reacted to "For how long were validators offline in our real Mainnet if we take last year or another period? The rationale looks valid, but it isn’t just happening today, so I’m not sure it could affect real distribution." with 👍
Luca | Vero
Support the general idea behind this. Concerned about fork size which is why we assigned C-tier
Oisin Kyne
Reacted to "My feeling is the me..." with 👍🏽
Matthew Keil
Reacted to "Support the general ..." with 👍
Oisin Kyne
Reacted to "Support the general ..." with 👍🏽
Barnabé Monnot
Generally opposed myself, I worry about second-order effects, and prefer to keep the incentives as-is. how does this interact with consolidation for instance?
Barnabas
eth price?
Cambridge
I’m a little worried about how it affects multi-client setups. Like where 3/5 clients have to agree.
Barnabas
thought we doing some uniswap usdc correlation penality lol 😂
Barnabas
penality is always $50
Kalo | Obol
Reacted to "thought we doing som..." with 😂
Barnabas
Guys, you control so much stake. You have so many validators, just consolidate to 0x02, and reuse your validator index and do top up txs. We don’t need literally ANY NEW validators. We don’t need this EIP. Literally none of the large staking providers have to make 0 new deposits. All you have to do is migrate everything to 0x02 and make additional top up txs.
Greg K | Lido
Reacted to "Guys, you control so much stake. You have so many validators, just consolidate to 0x02, and reuse your validator index and do top up txs. We don’t need literally ANY NEW validators. We don’t need this EIP. Literally none of the large staking providers have to make 0 new deposits. All you have to do is migrate everything to 0x02 and make additional top up txs." with 🤯
Tomer Ganor
Lido still has withdrawals
Barnabas
you can make partial withdrawal with 0x02 too?
Tomer Ganor
Replying to "Lido still has withd..." Then how do you deposit back?
Lion dapplion
Replying to "Guys, you control so..." That’s a great point
Tomer Ganor
Replying to "Lido still has withd..." New validartor
Barnabas
what do you mean deposit back?
Pavel | MixBytes
+1 from MixBytes - we vote for including EIP-8205 in Hegotá. It solves a lot of overhead with current approaches - improving security and simplifying things
Tomer Ganor
Replying to "Lido still has withd..." Deposit etc to lido
Luca | Vero
Replying to "Guys, you control so..." Tbf Lido is currently going through a huge 0x02 migration. New deposits are needed for them to onboard new community stakers, just as an example. I think the issue being solved here is real, not just for Lido.
Nico Flaig
pq deposit contract can fix this in a sane way? anyone looked into that?
Justin Traglia
Let’s spend a few mins talking about it.
Dima Gusakov | Lido
Replying to "pq deposit contract ..." If we will not have it now, than we have decent chance of not having it in PQ
Lion dapplion
Still time to CFI eip999?
Tomer Ganor
This is very good for security of liquid staking
meditationduck
ack3 also support this
Justin Traglia
Replying to "pq deposit contract ..." Kev has been looking into it, but I don’t know what the results of that were.
Enrico Del Fante
cfi
Barnabé Monnot
Reacted to "Tbf Lido is currently going through a huge 0x02 migration. New deposits are needed for them to onboard new community stakers, just as an example. I think the issue being solved here is real, not just for Lido." with 👍
Matthew Keil
dfi
Irina T
Reacted to "cfi" with 👍
Pavel | MixBytes
Replying to "Guys, you control so..." This problem is solved for multiple protocols spending huge amounts of money on auditing and monitoring current workarounds
Greg K | Lido
Replying to "pq deposit contract can fix this in a sane way? anyone looked into that?" Not CFI-ing now, will require the PQ deposit to care about this, and currently most of proposals were struggling to solve it. So solving now, makes the PQ work harder
Barnabas
Replying to "Guys, you control so..." good motivator to move to 0x02
terence
Has any client team studied the solution and can confirm it’s simple ?
Tomer Ganor
Replying to "Guys, you control so..." 0x02 does not solve this
Barnabas
Replying to "Guys, you control so..." migrate your 0x01 to 0x02 and you can do top ups?
Matthew Keil
Replying to "Has any client team ..." Did not look too simple
Barnabas
Replying to "Guys, you control so..." how is this not solved with top ups?
Tomer Ganor
Replying to "Guys, you control so..." How do you withdraw from lido?
Matthew Keil
Replying to "Has any client team ..." Not impossible but not worth the effort
Luca Donno | L2BEAT
Reacted to "Tbf Lido is currently going through a huge 0x02 migration. New deposits are needed for them to onboard new community stakers, just as an example. I think the issue being solved here is real, not just for Lido." with 👍
Justin Traglia
Replying to "Has any client team ..." I think it’s lowish/medium complexity.
Nico Flaig
Reacted to "Kev has been looking..." with 👍
Barnabas
Replying to "Guys, you control so..." I don’t know what Lido’s internal mechanism has to do with ethereum protocol development.
Justin Traglia
Replying to "Has any client team ..." https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip8205
Dima Gusakov | Lido
Reacted to "I think it’s lowish/medium complexity." with ❤️
Greg K | Lido
Reacted to "Tbf Lido is currently going through a huge 0x02 migration. New deposits are needed for them to onboard new community stakers, just as an example. I think the issue being solved here is real, not just for Lido." with 👍
Justin Traglia
Replying to "Has any client team ..." To be clear, this isn’t support. I don’t have strong feelings about this EIP.
Dima Gusakov | Lido
Reacted to "Guys, you control so much stake. You have so many validators, just consolidate to 0x02, and reuse your validator index and do top up txs. We don’t need literally ANY NEW validators. We don’t need this EIP. Literally none of the large staking providers have to make 0 new deposits. All you have to do is migrate everything to 0x02 and make additional top up txs." with 🤯
Dima Gusakov | Lido
Reacted to "cfi" with 👍
Pavel | MixBytes
Replying to "Guys, you control so..." The thing is that it is not only Lido’s internal mechanism. Each delegated staking protocol circumvents something around it
Enrico Del Fante
Running out of battery. Going offline...
Barnabas
Replying to "Guys, you control so..." I don’t understand why protocol devs should bend backwards to facilitate delegated staking mechanisms?
Tomer Ganor
The workaround is crazy
Luca Donno | L2BEAT
Reacted to "The workaround is crazy" with 👍
Pavel | MixBytes
Reacted to "The workaround is crazy" with 👍
Barnabas
Replying to "Guys, you control so..." The ethereum protocol should stay as simple as possible imho.
Tomer Ganor
CL works against EL and not to support it, I really dont understand why
Langers | Rocket Pool
What has changed to make this important is validator queue variability. As a decentralised protocol we have to choose between fast or safe, which makes centralised solutions more attractive.
Greg K | Lido
Reacted to "What has changed to make this important is validator queue variability. As a decentralised protocol we have to choose between fast or safe, which makes centralised solutions more attractive." with 👍
Barnabas
how many known cases of such attack has happened on mainnet btw?
Tomer Ganor
You cant not do small changes just bc they are small...
Luca Donno | L2BEAT
Replying to "Guys, you control so..." There have been many EIPs to help delegated staking no? It’s not obvious to me whether the protocol should facilitate it or not
Potuz
I can chime in, but I think on this topic it would make sense to hear what Kev has to say on the constraints to PQ deposit design decisions. I believe the right course of action would be to think these problems together with the PQ crowd as they are both interrelated.
Mega | ethlambda
Reacted to "I can chime in, but I think on this topic it would make sense to hear what Kev has to say on the constraints to PQ deposit design decisions. I believe the right course of action would be to think these problems together with the PQ crowd as they are both interrelated." with 👆
Luca | Vero
Reacted to "I can chime in, but I think on this topic it would make sense to hear what Kev has to say on the constraints to PQ deposit design decisions. I believe the right course of action would be to think these problems together with the PQ crowd as they are both interrelated." with 👍
Irina T
Reacted to "Tbf Lido is currently going through a huge 0x02 migration. New deposits are needed for them to onboard new community stakers, just as an example. I think the issue being solved here is real, not just for Lido." with 👍
kingy
Replying to "I can chime in, bu..." our opinion was fix it when we do pq fiddling so agree
Nico Flaig
Reacted to "I can chime in, but ..." with 👍
Matthew Keil
Replying to "I can chime in, but ..." Also agree
Luca | Vero
Replying to "I can chime in, but ..." I would also like to know if this can be solved at that point,which is approaching soon
james
Replying to "Has any client team ..." I guess it looks ok, still c tier for us I think
Tomer Ganor
This is liquid staking protocols issue and it feels like you just dont care about them and their success
Irina T
Reacted to "What has changed to make this important is validator queue variability. As a decentralised protocol we have to choose between fast or safe, which makes centralised solutions more attractive." with 👍
Tomer Ganor
And security ofc
Barnabas
Replying to "This is liquid staki..." there are more important issues to fix on the protocol layer than issues that liquid staking protocols have.
Justin Traglia
Reacted to "our opinion was fix it when we do pq fiddling so agree" with 👍
Tomer Ganor
Replying to "This is liquid staki..." For the same lvl of complexity?
Justin Traglia
Reacted to "I can chime in, but I think on this topic it would make sense to hear what Kev has to say on the constraints to PQ deposit design decisions. I believe the right course of action would be to think these problems together with the PQ crowd as they are both interrelated." with 👍
Potuz
Is Kev here?
Luca Donno | L2BEAT
Reacted to "there are more important issues to fix on the protocol layer than issues that liquid staking protocols have." with 👍
Justin Traglia
Replying to "Is Kev here?" Yeah he responded to your message
Nico Flaig
the current deposit contract is a pita, we all agree on that, so I would like to explore how that can be improved by simply getting rid of it with pq changes
Potuz
Replying to "Is Kev here?" Damned UI I have, can’t scroll essentially
Tomer Ganor
Lets talk next time pls
Matthew Keil
It does though. It sounds like a dfi
Irina T
Reacted to "Lets talk next time pls" with 👍
Justin Traglia
Replying to "Is Kev here?" He said: our opinion was fix it when we do pq fiddling so agree
Dima Gusakov | Lido
Reacted to "Lets talk next time pls" with 👍
Toni Wahrstätter
Reacted to "It does though. It sounds like a dfi" with 👍
Oisin Kyne
Reacted to "Lets talk next time ..." with 👍
Potuz
Replying to "Is Kev here?" Oh I got that from kingy
marc | wolovim
Reacted to "Oh I got that from kingy" with 👆
Justin Traglia
Replying to "Is Kev here?" Oh what. My mistake.
Justin Traglia
Replying to "Is Kev here?" I misread the username. My bad.
Justin Traglia
Replying to "Is Kev here?" Disregard me!
Tomer Ganor
thnaks
Mega | ethlambda
gb

Call summary

Targets

•Hoodi Glamsterdam fork — October 26, 2026 - 00:18:07
•Client release deadline for Hoodi blog post — October 16, 2026 (tomorrow) - 00:18:48

Decisions

•Builder onboarding race-condition fix rejected for Glamsterdam; no change to Hoodi or mainnet; app-layer workarounds expected - 00:37:55
•DFI for Hegota: EIP-8025 (optional execution proofs) — insufficient CL team support for CFI - 01:15:42
•DFI for Hegota: RowDAS — low client support, insufficient blob demand - 01:23:33
•DFI for Hegota: EIP-8359 (BeaconBlock client-diversity reporting field) - 01:26:23
•DFI for Hegota: EIP-7716 (anti-correlation attestation penalties) — indifferent support, beacon state concerns - 01:37:06
•EIP-8205 (withdrawal credentials pre-registration) decision deferred to next call; will open next call's scoping session - 01:57:33

Highlights

Eip Proposals Hegota:
- ·EIP-8365 (disable new 0x00 validators): Barnabas proposes allowing 0x00 validators in but with no duties, enabling BLS change/exit; guard at deposit-request not apply-pending-deposits to grandfather pre-fork deposits - 00:39:31
- ·EIP-8025 (optional execution proofs): DFI for Hegota; no CL team consensus for CFI; suggestion to improve EL spec branching process instead; CL feature spec already exists - 00:46:37
- ·RowDAS: DFI; low client support; blob supply insufficient to justify; duty-allocation variant (B option) noted but not enough support - 01:18:37
- ·EIP-8359 (BeaconBlock reporting field for client diversity): DFI; not rated highly by client teams - 01:23:13
- ·EIP-7716 (anti-correlation attestation penalties): DFI; mixed/indifferent support; concern about touching beacon state and second-order effects with issuance changes - 01:26:33
- ·EIP-8205 (withdrawal credentials pre-registration): deferred to next call; insufficient time for full discussion; majority view leans DFI pending PQ deposit contract design - 01:37:30
Fork Status And Schedule:
- ·Sepolia Glamsterdam fork went well; Hoodi scheduled for October 26th UTC - 00:17:05
- ·Client release deadline: tomorrow; only Lodestar and ethrex released so far; Teku tomorrow, Lighthouse early next week, Grandine tomorrow or early next week - 00:18:20
- ·Barnabas: test builder deposits live at fork transition on Hoodi; make deposits + top-ups before fork, target builder proposal in first/second slot - 00:20:34
Builder Onboarding Glamsterdam:
- ·Lido raised: builder onboarding race condition creates third outcome (no validator, ETH credited to builder) breaking existing app-layer deposit protections - 00:21:47
- ·Core devs declined fix: Sepolia already shipped, Hoodi releases cut, fix would require re-forking Sepolia; app-layer workarounds expected - 00:37:55

Action Items

•stokes / EF - Publish EF blog post for Hoodi once quorum of client releases available - 00:18:20
•CL client teams - Review EIP-8365 proposed changes (guard at process-deposit-request, grandfather pre-fork 0x00 deposits); revisit in 1-2 calls - 00:41:22
•EL spec / EELS team - Explore EL spec branching process improvements to support long-running experimental features without CFI - 01:15:52

Key decisions

Builder onboarding race-condition fix rejected for Glamsterdam; no change to Hoodi or mainnet; app-layer workarounds expected
Core devs declined fix because Sepolia already shipped and Hoodi releases were cut; fix would require re-forking Sepolia.
DFI for Hegota: EIP-8025 (optional execution proofs) — insufficient CL team support for CFI
DFIInsufficient CL team support for CFI; suggestion to improve EL spec branching process instead.
DFI for Hegota: RowDAS — low client support, insufficient blob demand
DFILow client support and insufficient blob supply to justify inclusion.
DFI for Hegota: EIP-8359 (BeaconBlock client-diversity reporting field)
DFINot rated highly by client teams.
DFI for Hegota: EIP-7716 (anti-correlation attestation penalties) — indifferent support, beacon state concerns
DFIMixed/indifferent support and concerns about touching beacon state and second-order effects with issuance changes.
EIP-8205 (withdrawal credentials pre-registration) decision deferred to next call; will open next call's scoping session
Insufficient time for full discussion; majority view leans DFI pending PQ deposit contract design.

EIPs discussed

EIP-7716 EIP-8025 EIP-8205 EIP-8359

Links

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.