EIPsInsight

Loading Experience

Preparing your insights...

Loading0%
ACDE2026-03-12_232

AllCoreDevs — Execution #232

2026-03-12 3 decisions 662 transcript lines

Transcript

Ask about this call

Answered from this call's summary and transcript only.

AI-generated — verify against the recording.

Call summary

Targets
  • March 19 - Repricing breakout to resolve EIP-8037/7928 alignment — 00:22:28
  • March 26 - Final frame transactions headliner decision — 01:25:37
Decisions
  • SSE/Pure ETH rejected as Hegotá headliner — 00:39:56
  • Lucid rejected as Hegotá headliner — 00:40:56
  • Frame transactions headliner decision delayed to March 26; requires Besu, Nethermind, or Reth support to proceed — 01:33:46
Highlights
  • Testing Progress:
    • ·bal-devnet-2: Aragon syncing issues being fixed; benchmarking shows prefetch slower than expected — 00:07:30
    • ·bal-devnet-3 blocked: most clients not ready for EIP-8037; test release 5.4.0 available — 00:09:36
    • ·epbs-devnet-0: running 1 week, Lighthouse/Lone Star/Prism working; Teku/Nimbus joining; exits/builders not working — 00:33:05
  • Repricing Updates:
    • ·Repricing breakout scheduled next Wednesday to address 8037 complexity and align with 7928 — 00:22:02
  • Headliner Selection:
    • ·SSZ/Pure ETH rejected as Hegotá headliner; focus on out-of-protocol implementation — 00:39:28
    • ·Lucid rejected as Hegotá headliner; can be reconsidered for I-Star — 00:40:56
    • ·Frame transactions support: 2 clients favor (Geth, Aragon); 3 prefer no headliner (Nethermind split, Besu, Reth) — 00:48:54
    • ·Post-quantum urgency highlighted: DAO migration timeline 2028-2029 requires native AA soon — 01:00:30
  • Critical Infrastructure:
    • ·EIP-8037 concerns raised: gas accounting complexity across 7928, 7778, 8037, blob gas needs principled alignment — 00:10:47
    • ·8037 implementation complexity: refund logic, state gas reservoir, testing gaps identified — 00:26:02
  • Fork Status And Schedule:
    • ·Glamsterdam devnet progress: bal-devnet-2 running, devnet-3 delayed pending EIP-8037 resolution — 00:07:01
    • ·SSZ experiments for engine API proposed as non-consensus change — 00:40:15
    • ·Frame transactions headliner decision delayed 2 weeks; default is rejection without additional client support — 01:25:37
Action Items
  • Maria Silva, Andrew Ashikhmin, all interested teams — Repricing breakout next Wednesday: address 8037/7928 alignment and mempool rule clarity — 00:22:28
  • Felix, Geth team, ethrex — Frame transactions champions: develop prototype mempool rules, clarify 8141 txpool spec for 2-week review — 01:26:30

Meeting chat475

  • Justin Traglia

    Gm

  • dionysuz.eth

    gm

  • lightclient

    gm

  • spencer

    lfgm

  • Justin Florentine (Besu)

    lfhagoooooooota

  • Justin Traglia

    Reacted to "lfgm" with 😄

  • spencer

    Reacted to "lfhagoooooooota" with 🚀

  • Justin Traglia

    Reacted to "lfhagoooooooota" with 🚀

  • Kevaundray Wedderburn

    Reacted to "lfhagoooooooota" with 🚀

  • Ben Adams

    Reacted to "lfhagoooooooota" with 🚀

  • Barnabas

    g[frame]m

  • Josh Davis

    Ben looks like a steampunk Seth Rogan

  • lightclient

    lol

  • Will Corcoran

    Replying to "Ben looks like a ste..." Looks like he is about to invite me on an amazing adventure

  • Barnabas

    thats better 😂

  • felix (eest)

    hey i was watching that

  • Justin Traglia

    Reacted to "lol" with 😄

  • Ben Adams

    Reacted to "Ben looks like a ste..." with 😂

  • Josh Davis

    Reacted to "lol" with 😄

  • nixo

    ahahahahah

  • wolovim

    Reacted to "lol" with 😄

  • lightclient

    standup session with V?

  • Ben Adams

    Reacted to "Looks like he is abo..." with 👍

  • Louis

    Reacted to "standup session with..." with 😂

  • Ansgar Dietrichs

    Reacted to "hey i was watching t..." with 😂

  • FLCL

    Depends on how prefetch is implemented probably

  • Toni Wahrstätter

    Replying to "Depends on how prefe..." yeah and what matters are worst-cases not average cases.

  • spencer

    JICYMI, new EELS release for bal-devnet-3 with the latest 8037 tests: https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0

  • Łukasz Rozmej

    8037 is ☠️

  • felipe

    Reacted to "Depends on how pre..." with 💯

  • Karim T. (matkt)

    Replying to "Depends on how prefe..." And state size also

  • Ansgar Dietrichs

    my understanding is that the read locations part of BALs is only for allowing deterministic prefetch, right? so we’d need to see it actually have (significant) benefits for the worst cases there to justify keeping it in the EIP?

  • felipe

    Reacted to "yeah and what matt..." with 💯

  • FLCL

    Any simple way to benchmark prefetch for an EL? Liek a pipeline or so?

  • Karim T. (matkt)

    Replying to "Depends on how prefe..." If it is on top of devnet 2 state I think we will see less performance improvement than mainnet state

  • Dragan Rakita

    Replying to "JICYMI, new EELS rel..." I think there is a bug here. Have reported in discord

  • Łukasz Rozmej

    Reacted to "my understanding is ..." with 👍

  • Stefan Starflinger

    Replying to "my understanding is ..." yeah

  • felipe

    Reacted to "If it is on top of..." with 👍

  • FLCL

    Replying to "Depends on how prefe..." We want to not wait prefetching state, but start execution in parallel and hope it will speed up

  • Łukasz Rozmej

    Replying to "my understanding is ..." probably it is not worth it

  • Stefan Starflinger

    Replying to "Any simple way to be..." what do you mean with pipline?

  • Karim T. (matkt)

    Replying to "Depends on how prefe..." Yes the same in Besu we start without waiting for the prefetch

  • FLCL

    So the testing happend for different optimizations right? But what if I have a new branch with more optimizations and want to test if it is more performant. Currently reruning some blocks from devnet locally, but it's very inconvinient

  • my side regarding 8037 etc

    moving to a more “principled” approach to gas accounting would be high up my priority list for H*, but I worry that trying to change things for G* will block process a lot. better to just try to just ship things now with minimal changes

  • Stefan Starflinger

    Replying to "Any simple way to be..." Felipe has been working on making it possible to run benchmarks with benchmarkoor

  • Dragan Rakita

    Reacted to "from my side regardi..." with ➕

  • DanielVF | Monad

    Reacted to "from my side regar..." with ➕

  • Stefan Starflinger

    Replying to "Any simple way to be..." do you have testing_buildBlockV1 implemented?

  • Ansgar Dietrichs

    Replying to "from my side regardi..." but obv I am missing the implementer perspective, maybe this is impractical

  • Greg K | Lido

    Reacted to "from my side regar..." with 👍

  • FLCL

    And no huge gains?

  • Łukasz Rozmej

    Reacted to "We want to not wait ..." with 👍

  • Anders Elowsson

    Replying to "from my side regardi..." Yeah so EIP-7999 would here be the principled solution, but EIP-8037 is still to our benefit today.

  • Karim T. (matkt)

    Replying to "Depends on how prefe..." As I said I think the devnet 2 has a really small state so not sure we will see huge difference. Compared to only // transactions imo

  • jochem-brouwer

    Antwoord verzenden naar "Any simple way to ..." We are setting up benchmarkoor to run (BAL) benchs against bloatnet (mainnet fork but then beefed up in state) which targets BAL branch in order to run it. So a re-run should then use the new image of that branch

  • Karim T. (matkt)

    Replying to "Depends on how prefe..." But in mainnet or bloatnet I think we will see more better performance imo

  • Marius van der Wijden

    Reacted to from my side regardi... with "➕"

  • Ansgar Dietrichs

    Reacted to "8037 is ☠️" with 😱

  • DanielVF | Monad

    Replying to "from my side regar..." I don't think EIP-8037 has immediate benefits beyond what a simple repricing would do.

  • Dragan Rakita

    Replying to "from my side regardi..." EIP-8037 is really desirable for bigger blocks

  • Ben Adams

    EIP-7999 as H* headliner?

  • raxhvl

    Reacted to from my side regardi... with "➕"

  • Francesco

    Reacted to "EIP-7999 as H* headl..." with 👍

  • Anders Elowsson

    Replying to "EIP-7999 as H* headl..." Hehe late headliner. It will be proposed as a regular EIP

  • Łukasz Rozmej

    8037 is very very complicated

  • jvn

    Reacted to "8037 is very very ..." with 👍

  • spencer

    Reacted to "8037 is very very ..." with 👍

  • lightclient

    Reacted to "8037 is very very co..." with 👍

  • Guru

    Reacted to "8037 is very very co..." with 👍

  • felix (eest)

    Reacted to "8037 is very very ..." with 👍

  • Ben Adams

    Reacted to "8037 is very very co..." with 👍

  • Łukasz Rozmej

    and then we will complicate it even more in next forks

  • Mario Vega

    Reacted to "8037 is very very co..." with 👍

  • Luis Pinto | Besu

    Me likes coherent approach

  • Ansgar Dietrichs

    we won’t be able to completely rework gas (including say blob gas) by Glamsterdam

  • Daniel Lehrner (Besu)

    Reacted to "we won’t be able to ..." with 💯

  • Stefan Starflinger

    Reacted to "8037 is very very co..." with 👍

  • Marius van der Wijden

    I don't think that 8037 is actually that complex. There is a few things about the refund logic

  • Karim T. (matkt)

    Reacted to "We are setting up be..." with 👍

  • Daniel Lehrner (Besu)

    Reacted to "I don't think that 8..." with ➕

  • Stefan Starflinger

    Reacted to "I don't think that 8..." with ➕

  • Dragan Rakita

    Reacted to "I don't think that 8..." with ➕

  • Toni Wahrstätter

    Reacted to "we won’t be able to ..." with 💯

  • felipe

    Reacted to "We are setting up ..." with 👍

  • Dragan Rakita

    EIP-8037 as a change is good, I would not change it at all imo.

  • felipe

    Reacted to "8037 is very very ..." with 👍

  • Stefan Starflinger

    Reacted to "EIP-8037 as a change..." with 👍

  • Ben Adams

    Replying to "I don't think that 8..." Drop refunds? https://eips.ethereum.org/EIPS/eip-3298

  • spencer

    Reacted to "EIP-8037 as a chan..." with 👍

  • Francesco

    What is the alternative? We are not going to do 7999 in Glamsterdam. What is this simple solution?

  • Dragan Rakita

    Replying to "I don't think that 8..." H*

  • felipe

    Reacted to "EIP-8037 as a chan..." with 👍

  • FLCL

    Replying to "Any simple way to be..." Just a draft of testing_buildBlockV1 for now looks like

  • FLCL

    Reacted to "We are setting up be..." with 👍

  • CPerezz

    Replying to "8037 is very very co..." The alternative is doing nothing then wrt. Multidimensional & state-size/growth? I mean, complexity only can’t be an argument. Complex and not useful sure, complex and underspecified sure. But complex only isn’t an argument enough powerful. Marius implemented it in 3 days passing 99% tests. Can’t be that impossibly complicated

  • FLCL

    Reacted to "But in mainnet or bl..." with 👍

  • Stefan Starflinger

    Replying to "Any simple way to be..." when merge?

  • Ameziane Hamlat

    Reacted to "We are setting up be..." with 👍

  • Stefan Starflinger

    Replying to "8037 is very very co..." make no mistakes

  • Toni Wahrstätter

    Reacted to "We are setting up be..." with 👍

  • Łukasz Rozmej

    what did we just changed?

  • Łukasz Rozmej

    Reacted to "make no mistakes" with 👍

  • Daniel Lehrner (Besu)

    Replying to "what did we just cha..." https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0

  • Marius van der Wijden

    Replying to "8037 is very very co..." None of it was done with ai, I had an ai version but it was very ugly

  • Ansgar Dietrichs

    if we think it’s at least possible we make larger changes here still, how do ppl feel about bal-devnet-3? still go ahead with 8037 as-is, or delay?

  • FLCL

    Replying to "Any simple way to be..." 🤷‍♂️ Will ping back when merged or can say more

  • Łukasz Rozmej

    Replying to "8037 is very very co..." Ethereum narrative: simplify protocol Ethereum reality: spaghetti? :(

  • jvn

    Reacted to "Ethereum narrative..." with 🙃

  • spencer

    Replying to "what did we just c..." Only EELS spec & test changes in the above release: https://github.com/ethereum/execution-specs/pull/2468

  • felix (eest)

    https://github.com/ethsteel/pm/blob/main/complexity_assessments/EIPs/EIP-8037.md old take but u can see how much pain it is for us

  • CPerezz

    Replying to "8037 is very very co..." Open for improvements. But saying it’s complex doesn’t help simplifying it. Nor gives any alternative solutions 🙁

  • Stefan Starflinger

    I agree

  • Luis Pinto | Besu

    Well I would argue the spaguetti is already there and right now gas cost does not only reflect client effort. Having a coherent solution just makes it leaner.

  • Maria Silva

    I also agree with Spencer

  • Stefan Starflinger

    We wanted to do this EIP early before the others exactly becuase it's not easy but worthwile

  • Dragan Rakita

    Reacted to "We wanted to do this..." with ➕

  • Ansgar Dietrichs

    Reacted to "We wanted to do this..." with 👍

  • lightclient

    how will 8037 and 8038 affect contracts on mainnet?

  • CPerezz

    Replying to "how will 8037 and 80..." I think Carl was running the analysis IIRC. He has all the data. @Carl Beekhuizen

  • CPerezz

    Replying to "how will 8037 and 80..." (For 8037)

  • Maria Silva

    Replying to "how will 8037 and 80..."

  • the ecosystem

    https://x.com/EFprotocol/status/2031056150427242892

  • Maria Silva

    Replying to "how will 8037 and 80..." Also, Carl is currently looking into 7904 and 2870

  • Maria Silva

    Replying to "how will 8037 and 80..." We will do the analysis on 8037 and 8038 next

  • lightclient

    Replying to "how will 8037 and 80..." im looking more for analysis to see what will break when the prices change, not people’s concern level

  • Maria Silva

    Replying to "how will 8037 and 80..." Got it. That analysis is what Carl as been working on

  • Maria Silva

    Replying to "how will 8037 and 80..." We will share when we have final results

  • Marius van der Wijden

    Replying to "how will 8037 and 80..." We will also give grants for security reviews to see what breaks once the eip is in a more final form (hopefully starting in ~2weeks)

  • Marius van der Wijden

    Epbs devnet 0 can be implemented in 1 hour

  • Marius van der Wijden

    Replying to "Epbs devnet 0 can be..." *on EL!

  • Daniel Lehrner (Besu)

    Replying to "Epbs devnet 0 can be..." Where can we see the spec changes needed for the devnet?

  • Barnabas

    Replying to "Epbs devnet 0 can be..." https://notes.ethereum.org/@ethpandaops/epbs-devnet-0

  • Daniel Lehrner (Besu)

    Reacted to "https://notes.ethere..." with 🙏

  • Barnabas

    Replying to "Epbs devnet 0 can be..." For this devnet we are going to use: engine_forkchoiceUpdatedV3 engine_newPayloadV5 engine_getPayloadV5

  • Barnabas

    Replying to "Epbs devnet 0 can be..." we need to be able to trigger amsterdam without activating bal which is the important bit

  • Łukasz Rozmej

    we are open for engine API SSZ as non-consensus change

  • Ben Adams

    Reacted to "we are open for engi..." with 👍

  • Marius van der Wijden

    Reacted to we are open for engi... with "👍"

  • Lumi | Offchain Labs

    Reacted to "we are open for engi..." with 👍

  • Iván | ethrex

    Reacted to "we are open for engi..." with 👍

  • Luca Donno | L2BEAT

    Reacted to "we are open for engi..." with 👍

  • Luis Pinto | Besu

    Replying to "we are open for engi..." Are you fine with adding content-type from HTTP headers into the Ethereum protocol?

  • Łukasz Rozmej

    Replying to "we are open for engi..." Although PR we got from Giulio needs to be compleatly reworked from ground up.

  • Stefan Starflinger

    Reacted to "we are open for engi..." with 👍

  • Luis Pinto | Besu

    Replying to "we are open for engi..." Or how would we do it in a non-consensus way?

  • Derek Chiang | ZeroDev

    Felix posted a summary of the major updates to Frame Txns since the last discussion: https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879

  • Marius van der Wijden

    Replying to "we are open for engi..." We should use this as a shelling point to rework the engine api imho

  • Łukasz Rozmej

    Replying to "we are open for engi..." Isn't it just a transport entry-point? Not sure if we are talking same thing

  • Barnabas

    Replying to "we are open for engi..." https://github.com/ethereum/execution-apis/pull/764

  • Barnabas

    Replying to "we are open for engi..." do you mean this?

  • FLCL

    Reacted to "https://github.com/e..." with 👍

  • Łukasz Rozmej

    Reacted to "https://github.com/e..." with 👍

  • Ben Adams

    Replying to "we are open for engi..." Non-consenus as via discovery either engine capability and/or accept headers

  • Ben Adams

    Reacted to "https://github.com/e..." with 👍

  • Barnabas

    Replying to "we are open for engi..." negotiation could happen with json, but once negotiation is done, it would use ssz if CL and EL both support ssz, otherwise fall back to using json

  • Ben Adams

    Reacted to "negotiation could ha..." with 👍

  • Luis Pinto | Besu

    Replying to "we are open for engi..." >do you mean this? yup

  • nixo

    https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879

  • Łukasz Rozmej

    Reacted to "negotiation could ha..." with 👍

  • FLCL

    May be a separate rest endpint for metadata btw and don't touch capabilties (there rest of the spec is super cool)

  • Luis Pinto | Besu

    I think I would prefer it through an exchange capabilities request instead of using HTTP headers

  • Lumi | Offchain Labs

    Reacted to "Felix posted a summa..." with 👍

  • Ben Adams

    Replying to "we are open for engi..." capabilities exchange has benefit of allowing different urls rather than having to generically parse payload first

  • Barnabas

    Replying to "we are open for engi..." We can hash this out, this is just a detail question

  • Ben Adams

    Reacted to "We can hash this out..." with 👍

  • Luis Pinto | Besu

    Reacted to "We can hash this out..." with 👍

  • Barnabas

    Replying to "we are open for engi..." the main question is whether people are willing to add ssz in their codebase. If the answer to that is a yes, then we should finalize the spec and lets get it merged

  • FLCL

    Replying to "we are open for engi..." http headers are necessary if you mean Accept/Content-Type

  • Derek Chiang | ZeroDev

    What was the reason for the change for Besu?

  • Lumi | Offchain Labs

    Reacted to "What was the reason ..." with ➕

  • lightclient

    IMO the complexity of frame tx is in the txpool, and we have the ability turn the knob of how much the txpool allows based on time available. so i guess i’m not sure what complexity you are worried about?

  • Ansgar Dietrichs

    Reacted to "IMO the complexity o..." with 👍

  • Felix (Geth)

    Reacted to "IMO the complexity..." with 👍

  • jvn

    Reacted to "IMO the complexity..." with 👍

  • Parthasarathy Ramanujam

    Reacted to "IMO the complexity o..." with 👍

  • Luca Donno | L2BEAT

    Reacted to "IMO the complexity o..." with 👍

  • Orca 0x

    Reacted to "IMO the complexity o..." with 👍

  • Iván | ethrex

    Reacted to "IMO the complexity o..." with 👍

  • Fredrik

    Reacted to "IMO the complexity o..." with 👍

  • Daniel Lehrner (Besu)

    Replying to "What was the reason ..." No headliner was not a realistic option when you did a team internal pool the last time. Now that it is, that was preferred. Frame tx and LUCID where close 2nd options.

  • jvn

    IMO When trying out a impl , abstracting mempool , maybe Frame Tx might not be as complicated as I thought

  • Barnabas

    I think not handling frame tx as a headliner could lead to wasting huge amount of resources and not including afterall. Which is not an ideal outcome imo.

  • FLCL

    Frames look a bit like a separate simplest language on top of contract. Might be one top frame with simplified rules.

  • Lumi | Offchain Labs

    Reacted to "I think not handling..." with ➕

  • Trent

    Wasn’t LUCID just rejected 5min ago?

  • lightclient

    I think we can keep LUCID in mind with respect to frame tx design

  • Luis Pinto | Besu

    Replying to "Wasn’t LUCID just re..." What he’s saying is that he wants to look at them both holistically

  • Ansgar Dietrichs

    Reacted to "I think we can keep ..." with 👍

  • Marius van der Wijden

    Replying to "Wasn’t LUCID just re..." Erigon can still work on it if they choose to

  • Barnabas

    I’d prefer to keep our focuses on a single/few EIPs instead of working on mutliple headliner sized EIPs

  • Greg K | Lido

    Reacted to "What he’s saying ..." with 👍

  • Fabio Di Fabio

    Reacted to "What he’s saying is ..." with 👍

  • Stefan Starflinger

    Reacted to "I’d prefer to keep o..." with 👍

  • FLCL

    Reacted to "I think we can keep ..." with 👍

  • soispoke

    Reacted to "I think we can keep ..." with 👍

  • Łukasz Rozmej

    Replying to "IMO the complexity o..." that sounds a bit handwavy, I would like to have a proper mempool spec/consensus as it is a main unknown at the moment

  • lightclient

    it seems like the main concern is that frame tx would delay the next fork? does it change people’s opinion knowing we could simply not allow frame tx in txpool and the implementation is very straightforward

  • Anders Elowsson

    Replying to "it seems like the ma..." But we would like to eventually right?

  • Ansgar Dietrichs

    so say a scenario of shipping frame txs as headliner, but with very limited txpool support at first. would that be worth it?

  • Dragan Rakita

    Reth take is that it is over abstracted and simpler solution would be better in general.

  • spencer

    Reacted to "I’d prefer to kee..." with 👍

  • Parithosh Jayanthi

    TBF we have taken out headliners before

  • Łukasz Rozmej

    It is always harder to remove

  • Parithosh Jayanthi

    Reacted to "It is always harder ..." with 👍🏽

  • CPerezz

    Replying to "Reth take is that it..." You refer to the PQ part? Or the entire thing?

  • Fredrik

    It’s part of the process that we can take it out though, for example if we find security issues and such

  • DanielVF | Monad

    Reacted to "Reth take is that ..." with ➕

  • Anders Elowsson

    From a decision-theoretic perspective, we may have not gathered sufficient information to make a robust decision. The marginal cost of exploring non-headliner EIPs at this point is relatively low, meaning one option is to not take a decision but to start exploring non-headliners over the next month. So that we know what the competition is so to speak.

  • Danno Ferrin - Tectonic.xyz

    It’s less damaging to the process to elevate a feature to headliner than to demote it.

  • Dragan Rakita

    Reacted to "It’s less damaging t..." with ➕

  • soispoke

    That rule of not being able to repropose as a non headliner is still puzzling to me

  • Marius van der Wijden

    There are two competing definitions of headliner 😅

  • spencer

    Footliner?

  • Maria Silva

    Reacted to "That rule of not bei..." with 💯

  • Josh Davis

    Reacted to "Footliner?" with 😂

  • Maria Silva

    Reacted to "Footliner?" with 😂

  • Lumi | Offchain Labs

    Reacted to "Footliner?" with 😂

  • Iván | ethrex

    In ethrex we’ve made an early implementation of EIP-8141. We got it working in 1-2 days. You can take a look at it and see if it looks complex for you https://github.com/lambdaclass/ethrex/pull/6326. There’s some docs listing some gaps and the decisions we took

  • nixo

    Reacted to "Footliner?" with 🦶

  • soispoke

    Reacted to "Footliner?" with 🦶

  • lightclient

    Reacted to "In ethrex we’ve made..." with 👍

  • Fredrik

    Reacted to "In ethrex we’ve made..." with 👍

  • Greg K | Lido

    Replying to "it seems like the ..." I think also people are not convinced of the effectivness of this EIP for the problem is supposed to solve

  • Shruti Gandhi

    Reacted to "Footliner?" with 😂

  • Derek Chiang | ZeroDev

    Reacted to "In ethrex we’ve made..." with 👍

  • Barnabas

    Reacted to "In ethrex we’ve made..." with 👍

  • Chris H

    Reacted to "Footliner?" with 🦶

  • lightclient

    Replying to "it seems like the ma..." that’s not what i’m hearing?

  • lightclient

    Replying to "it seems like the ma..." seems like people are just worried about ability to ship in a timely manner

  • Iván | ethrex

    There’s also a web demo for the e2e with some examples https://demo.eip-8141.ethrex.xyz

  • Barnabas

    I’d like to take the input of not only core devs to make a decision whether we want frame txs or not.

  • Greg K | Lido

    Reacted to "Footliner?" with 😂

  • Iván | ethrex

    Replying to "In ethrex we’ve made..." Using an ethrex dev node

  • Barnabas

    Replying to "I’d like to take the..." we always say that we should listen to the community more, so lets give the floor to them, and hear them out.

  • Iván | ethrex

    Replying to "In ethrex we’ve made..." The code still needs to be cleaned up a little bit, but it’s clear enough

  • lightclient

    one important point to do native AA in H*, if we don’t then smart accounts won’t be able to take advantage of FOCIL

  • Greg K | Lido

    Reacted to "I’d like to take ..." with 👍

  • jvn

    Reacted to "I’d like to take ..." with 👍

  • Luis Pinto | Besu

    Replying to "I’d like to take the..." TBF what I hear mostly about the community it’s to raise code size and nothing about frame txs

  • Barnabas

    Replying to "I’d like to take the..." thats already happening in glammy tho

  • Luis Pinto | Besu

    Replying to "I’d like to take the..." Not lifting the limit altogether, just pushing the bar a bit up

  • Łukasz Rozmej

    I'm also afraid it will end up in YAGNI space and don't get hoped adoption, similar to 7702, due to complexity

  • CPerezz

    Reacted to "I'm also afraid it w..." with 👍

  • Parthasarathy Ramanujam

    Replying to "I’d like to take the..." @Luis Pinto | Besu There is demand for native AA amongst all wallet developers. 8141 seems to be the most popular candidate now. Especially, a poll conducted by @lightclient among wallet and AA developers.

  • Derek Chiang | ZeroDev

    Reacted to "@Luis Pinto | Besu T..." with 👍

  • lightclient

    Replying to "I'm also afraid it w..." this is why we’re adding the default account, it solves these problems for wallets and users that are more skittish

  • spencer

    Reacted to "In ethrex we’ve m..." with 👍

  • Derek Chiang | ZeroDev

    Reacted to "this is why we’re ad..." with 👍

  • FLCL

    We can agree on frames as is not final design, pick at as headliner and improve it on the way. It a significant change that may need more time that usually

  • lightclient

    Reacted to "We can agree frames ..." with 👍

  • Derek Chiang | ZeroDev

    Reacted to "We can agree frames ..." with 👍

  • Parthasarathy Ramanujam

    Replying to "I'm also afraid it w..." The only way, you can increase adoption is by deprecating EOAs. That will get “lazy” users to migrate to smart accounts.

  • Felix (Geth)

    Reacted to "We can agree frame..." with 👍

  • Fredrik

    Reacted to "We can agree frames ..." with 👍

  • felix (eest)

    Reacted to "We can agree on fr..." with 👍

  • Lumi | Offchain Labs

    Reacted to "We can agree on fram..." with 👍

  • Marius van der Wijden

    Reacted to We can agree on fram... with "👍"

  • Łukasz Rozmej

    Reacted to "We can agree on fram..." with 👎

  • Dragan Rakita

    Reacted to "We can agree on fram..." with 👎

  • Dragan Rakita

    Reacted to "I'm also afraid it w..." with 👍

  • Parthasarathy Ramanujam

    Reacted to "We can agree on fram..." with 👍

  • Iván | ethrex

    Reacted to "We can agree on fram..." with 👍

  • jvn

    Reacted to "We can agree on fr..." with 👍

  • stokes

    Reacted to "We can agree on fram..." with 👍

  • Dragan Rakita

    Reacted to "I’d like to take the..." with 👍

  • frangio

    Reacted to "We can agree on fr..." with 👍

  • Łukasz Rozmej

    Frame transaction doesn't solve post quantum, it gives a potential to solve it later

  • DanielVF | Monad

    PQ doesn't require frame transactions though

  • felipe

    Reacted to "Footliner?" with 🦶

  • Dragan Rakita

    Replying to "I’d like to take the..." From devtooling feedback that I shared last time, it is unnecessary complex and bad eip.

  • Dragan Rakita

    Reacted to "PQ doesn't require f..." with 👍

  • Danno Ferrin - Tectonic.xyz

    We need a PQC algo as a precompile

  • lightclient

    hoping we have a PQ precompile as a non-headliner in H* 🙂

  • FLCL

    PQ is not solved at all for now and can be solved purely in parallel by people with very different competency

  • Greg K | Lido

    Reacted to "We need a PQC algo..." with 👍

  • Luis Pinto | Besu

    Reacted to "We need a PQC algo a..." with 👍

  • lightclient

    guys 7702 has 4 million ops per week

  • Barnabas

    Reacted to "@Luis Pinto | Besu T..." with 👍

  • Parthasarathy Ramanujam

    Reacted to "guys 7702 has 4 mill..." with 👍

  • Ansgar Dietrichs

    7702 is very synergistic with native AA, because it allows EOAs to upgrade to smart accounts that can then use e.g. frame txs

  • CPerezz

    Replying to "hoping we have a PQ ..." Can’t cheaper compute and bigger gas limits get us there already without precompiles?

  • soispoke

    One thing to maybe keep in mind is that we’re also deciding very early (compared to last time) so in theory it gives more time to iterate on EIPs after the decision point

  • Felix (Geth)

    Most definitely there will be iteration on the EIP

  • DanielVF | Monad

    Reacted to "guys 7702 has 4 mi..." with 👍

  • Ansgar Dietrichs

    Replying to "7702 is very synergi..." then we’d just at some point have to introduce a way to fully revoke the original ecdsa key

  • Marc

    Reacted to "We can agree on fram…" with 👍

  • Parthasarathy Ramanujam

    Adoption of 7702 or the lack of it, wasn’t due to the EIP, it was the reluctance of few wallets to support it and also due to a lot of false information spread about “alleged” vulnerabilities!

  • Trent

    Reacted to "guys 7702 has 4 mill..." with 👍

  • Nico Consigny

    FCLC for some reason I can't reply directly to

  • Luis Bezzenberger

    Reacted to I think we can keep ... with "👍"

  • Nico Consigny

    > PQ not solved at all

  • Luis Bezzenberger

    Reacted to Erigon can still wor... with "👍"

  • Łukasz Rozmej

    Replying to "Adoption of 7702 or ..." so won't they have similar issues with frame transactions?

  • lightclient

    Replying to "Adoption of 7702 or ..." i think the default code will basically guarantee that frame tx has wide adoption

  • Parthasarathy Ramanujam

    Replying to "Adoption of 7702 or ..." As I said earlier, unless EOA are specifically deprecated, you wont have users migrate. But the default code definitely help here.

  • Orca 0x

    Reacted to "i think the default ..." with 👆

  • Parthasarathy Ramanujam

    Reacted to "i think the default ..." with 👆

  • Łukasz Rozmej

    Replying to "Adoption of 7702 or ..." @lightclient but then it is basically standard transaction?

  • Ahmad Bitar | Nethermind

    My personal stance is to support frame as headliner for hegata

  • Barnabas

    What do EL teams want to work on in the second half of this year, if they oppose all headliners?

  • lightclient

    Replying to "Adoption of 7702 or ..." it is a standard tx, but it doesn’t make non standard accounts 2nd class

  • lightclient

    Replying to "Adoption of 7702 or ..." which is important

  • Marc

    Reacted to "My personal stance i…" with ➕

  • Barnabas

    does ethrex count?

  • Francesco

    Sorry but reth should clearly not be considered in this decision?

  • Iván | ethrex

    +1 for ethrex

  • nixo

    i think the idea here was clean up on a lot of non-headliners (based on comments from last ACDE)

  • Luca Donno | L2BEAT

    Reacted to "Sorry but reth shoul..." with 👍

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." Why is that?

  • Francesco

    Replying to "Sorry but reth shoul..." There’s a clear conflict of interest\

  • lightclient

    Reacted to "Sorry but reth shoul..." with 👍

  • spencer

    Reacted to "Why is that?" with 👍

  • Luca Donno | L2BEAT

    Reacted to "There’s a clear conf..." with 👍

  • soispoke

    Reacted to "Sorry but reth shoul..." with 👍

  • Trent

    Reacted to "Sorry but reth shoul..." with 👍

  • Trent

    Reacted to "There’s a clear conf..." with 👍

  • Francesco

    Replying to "Sorry but reth shoul..." (I don’t care or have opinions about frame txs at all fwiw)

  • Ahmad Bitar | Nethermind

    Reacted to Sorry but reth shoul... with "👍"

  • Barnabas

    @Daniel Lehrner (Besu) its a chicken and egg

  • Parthasarathy Ramanujam

    Reacted to "Sorry but reth shoul..." with 👍

  • Barnabas

    you could make it the majority lol

  • Lumi | Offchain Labs

    Reacted to "you could be the maj..." with 😂

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." This does not make sense, we still think what is better for eth protocol

  • Mega | Lambda

    Reacted to "+1 for ethrex" with 👍

  • Francesco

    Replying to "Sorry but reth shoul..." You can say that and we can choose to believe you, there’s still a glaring conflict of interest

  • Pablo Deymo | Lambda

    Reacted to "+1 for ethrex" with 👍

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." Frame tx or not, it does not effect tempo at all.

  • Josh Davis

    Reacted to "Sorry but reth shoul..." with 👍

  • jonny (geth)

    Reacted to "you could make it th..." with 👍

  • Hsiao-Wei Wang

    Reacted to "@Luis Pinto | Besu T..." with ❤️

  • Anders Elowsson

    Replying to "What do EL teams wan..." 7999 😎

  • Giulio

    Unreal chat

  • Daniel Lehrner (Besu)

    Reacted to "you could make it th..." with 😂

  • Luca Donno | L2BEAT

    Reacted to "You can say that and..." with 👍

  • Ansgar Dietrichs

    Reacted to "Unreal chat" with 😂

  • FLCL

    3h sound scary now, 2 days may be a lot 😂

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." We did a lot good for the protocol, this just feel a bad take.

  • Chris H

    Reacted to "3h sound scary now, …" with 😂

  • Fredrik

    Reacted to "My personal stance i..." with ➕

  • Francesco

    Replying to "Sorry but reth shoul..." On a personal level, I believe you. But it is a conflict of interest, there’s a competing standard being proposed essentially...

  • lightclient

    mempool rules: https://eips.ethereum.org/EIPS/eip-7562

  • lightclient

    i wouldn’t say that “it isn’t defined” we just have to decide how much of 7562 we want in the core protocol

  • lightclient

    it is very well thought through and thorough

  • Ansgar Dietrichs

    I will keep the discussion open for however much longer there are things to discuss, but I would need either Besu, Nethermind, or reth to flip to frame tx headliner support to not then propose rejecting this headliner proposal at the end.

  • Iván | ethrex

    Reacted to "Sorry but reth shoul..." with 👍

  • Marius van der Wijden

    Replying to "Sorry but reth shoul..." I agree, Reth should be able to voice their opinion, even if they have a conflict of interest. I would hope that they won't die on the hill of not implementing it if it came to that though.

  • Marc

    Replying to "I will keep the disc…" Nethermind team is split on this, personally I would be open to making headliner

  • Pablo Deymo | Lambda

    Reacted to "Sorry but reth shoul..." with 👍

  • DanielVF | Monad

    EIP-8141 spec metions rules "similar to" https://eips.ethereum.org/EIPS/eip-7562

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." If you believe me, you wouldn’t state it like that, it is really hurtful. The outcome we all want is what is best for etheream, proposing different approach does not make our vote invalid. It is just a bad take.

  • Ansgar Dietrichs

    Reacted to "Nethermind team is s..." with 👍

  • Francesco

    Replying to "Sorry but reth shoul..." It’s not personal, really

  • Lumi | Offchain Labs

    Reacted to "Nethermind team is s..." with 👍

  • Mega | Lambda

    Reacted to "Sorry but reth shoul..." with 👍

  • lightclient

    Reacted to "Nethermind team is s..." with 👍

  • Francesco

    Replying to "Sorry but reth shoul..." And one thing is expressing an opinion, a different thing is getting a “vote”. Seems very standard to not get a vote when there’s a clear conflict of interest?

  • Lumi | Offchain Labs

    Replying to "I will keep the disc..." Where is Tomasz when we need him 😜

  • Alex Forshtat

    Replying to "Sorry but reth shoul..." Just a question, why didn't Reth propose Tempo transactions for Hegota headliner?

  • soispoke

    Replying to "i wouldn’t say that ..." I agree, the only thing to point out is that this was designed without FOCIL in mind which will impact some of the parameters (e.g., VERIFY gas)

  • Dragan Rakita

    It is like saying drop everyone oppinion except geth

  • lightclient

    some non-headliners may depend on frame tx, such as tx assertions. this is a very important upgrade to improve security of transacting on ethereum

  • lightclient

    Replying to "some non-headliners ..." frame tx works very well for this because you can have a post-op frame to analyze the outcome of other frames

  • lightclient

    Reacted to "I agree, the only th..." with 👍

  • Ahmad Bitar | Nethermind

    Reacted to Nethermind team is s... with "👍"

  • Giulio

    Replying to "Sorry but reth sho..." Claude, should Reth be included in decision-making? Make no mistakes.

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." @Francesco I don’t see the conflicts, as I said implementation of frame does not touch tempo. Modular approach of reth allows that.

  • Alex Forshtat

    Reacted to Sorry but reth shoul... with "👍"

  • DanielVF | Monad

    Replying to "some non-headliner..." Will need batch reverting frame ability for post-op frame checks, which I think you are planning on adding?

  • jvn

    I think a year is actually plenty of time to revise the EIP if needed and implement it properly. The benefits could be significant - bringing native account abstraction and even leaving room for a post-quantum pathway. Considering that, Making it as a headliner might actually be worthwhile. IMO

  • FLCL

    Maybe something can be done with tx gossip scores or so

  • lightclient

    Replying to "some non-headliners ..." there are a few ways it could be implemented. i personally imagined it would be done by only approving payment at end of tx

  • Lumi | Offchain Labs

    Reacted to "I think a year is ac..." with ➕

  • lightclient

    Reacted to "I think a year is ac..." with 👍

  • lightclient

    Reacted to "I think a year is ac..." with ➕

  • Shruti Gandhi

    Reacted to "I think a year is ac..." with ➕

  • Fredrik

    Replying to "some non-headliners ..." This is that it’s one of the most asked for features by end users as it basically protects users against drainers and other types of attacks, and is coming from many discussions with various parties during 1TS

  • Parthasarathy Ramanujam

    Reacted to "I think a year is ac..." with ➕

  • Emma

    I do not think it is fair to say we shouldn’t be considered in the decision making, when we are clearly supporting and working hard on Reth for Ethereum….

  • Iván | ethrex

    Reacted to "I think a year is ac..." with ➕

  • Parthasarathy Ramanujam

    Isn’t there a native tracer built (in geth) that validates a transactions against erc7562 rules?

  • Parthasarathy Ramanujam

    Wouldn’t that help with most of the complexities associated to mempool validation?

  • lightclient

    Replying to "Is there a native tr..." we would just run the evm in a specific mode

  • Parthasarathy Ramanujam

    Replying to "Isn’t there a native..." I blame auto-correct. I was supposed to type “Isn’t”

  • Parthasarathy Ramanujam

    Reacted to "we would just run th..." with 👍

  • Danno Ferrin - Tectonic.xyz

    Replying to "Sorry but reth shoul..." So one of the arguments is “Frame beacuse no alternateives have been proposed” and then when reth proposes an alternative they get penalized?

  • Francesco

    Replying to "Sorry but reth shoul..." I never said anything about decision making in general, this just happens to be a case when there’s a conflict of interest, in my opinion. You can disagree on that, fine, agree to disagree

  • Felix (Geth)

    Just to clarify, Fredrik is talking about the ability to add arbitrary post-conditions to any transaction. Notably this feature is not related with the mempool at all.

  • soispoke

    fwiw implementing encrypted mempools designs (e.g., LUCID) on top of frame txns is quite nice

  • Fredrik

    Reacted to "Just to clarify, Fre..." with 👍

  • Enrico Del Fante (tbenr)

    The security argument is very appealing

  • Nico Consigny

    Nethermind team is splitted

  • nixo

    if we settle on “no headliner” - can we also get a decision on whether or not it can come back as a non-headliner since that’s technically been against process since the headliner process was introduced? but seems reasonable that acd can overrule

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." We are sharing experience from something that we already have, so hope from here that synergy can be taken.

  • frangio

    Reacted to "if we settle on “..." with 👍

  • Alex Forshtat

    Replying to "Sorry but reth shoul..." @Danno Ferrin - Tectonic.xyz But Tempo transactions are not formally proposed for Hegota, are they?

  • Lumi | Offchain Labs

    Reacted to "if we settle on “no ..." with 👍

  • Łukasz Rozmej

    I personally don't know, I dont want to block it, but I still see the risk of adding it and then potentially removing as a headliner

  • Danno Ferrin - Tectonic.xyz

    Replying to "Sorry but reth shoul..." This hiding behind process is not a good look.

  • Ahmad Bitar | Nethermind

    Replying to "if we settle on “no ..." It frame cannot come back as a non headliner then i believe we should have it in

  • Barnabas

    Can we wait another 2w in deciding? I’m usually not into delaying decisions but its really on the edge.

  • Danno Ferrin - Tectonic.xyz

    Replying to "Sorry but reth shoul..." process should reflect consensus, not enforce it.

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." For example this is improvement ever tempo in terms in EIP: https://eips.ethereum.org/EIPS/eip-8175 that would be even better than tempo,

  • Derek Chiang | ZeroDev

    What would need to change to change Besu/Nethermind/Reth’s minds?

  • Trent

    Reacted to "Can we wait another ..." with 👍

  • Dragan Rakita

    Echoing that we all want to improve protocol, and think what is best for it.

  • Felix (Geth)

    can we promote it to headliner later?

  • lightclient

    Reacted to "can we promote it to..." with 🔥

  • Ben Adams

    Reacted to "can we promote it to..." with 🔥

  • Tamaghna Choudhuri

    Reacted to "can we promote it to..." with 😆

  • Felix (Geth)

    like what if it turns out really good

  • Dragan Rakita

    Replying to "Sorry but reth shoul..." I will start referring this as composable tx. This is not a headliner as it is smaller scope

  • Luca Donno | L2BEAT

    Reacted to "Can we wait another ..." with 👍

  • Dragan Rakita

    Reacted to "I do not think it is..." with 👍

  • Lumi | Offchain Labs

    Reacted to "can we promote it to..." with 😆

  • Alex Forshtat

    Reacted to I will start referri... with "👍"

  • Ansgar Dietrichs

    can we get a temperature check on delaying the decision? 👍 = delaying decision 👎 = make decision today

  • lightclient

    does anyone want to absolutely block it if we accept as headliner?

  • soispoke

    Reacted to "can we get a tempera..." with 👍

  • lightclient

    maybe another way to frame the Q

  • Lumi | Offchain Labs

    Reacted to "can we get a tempera..." with 👍

  • Ben Adams

    Replying to "does anyone want to ..." I don't think we'd block

  • Barnabas

    if majority of nethermind is for it, then thats the decider

  • Fredrik

    I think the security improvement alone is really valuable. People are losing hundreds of millions of USD each year, and this together with transaction assertions could remove or at the very least significantly reduce that

  • Nicolas Consigny

    Reacted to "I think the security..." with 👍

  • Parithosh Jayanthi

    Also note that we have a lot of ZK related priorities the next few forks. If we don’t do frame txs now, I don’t imagine us getting another chance for a while.

  • lightclient

    Reacted to "Also note that we ha..." with 👍

  • Lumi | Offchain Labs

    Reacted to "Also note that we ha..." with 👍

  • Lumi | Offchain Labs

    Reacted to "I think the security..." with 👍

  • Barnabas

    Reacted to "I think the security..." with 👍

  • Felix (Geth)

    we can work out some prototype rules within 2 weeks

  • Ameziane Hamlat

    Reacted to "can we get a tempera..." with 👍

  • felipe

    Reacted to "I think the securi..." with 👍

  • Barnabas

    Reacted to "Also note that we ha..." with 👍

  • Mega | Lambda

    Reacted to "maybe another way to..." with 😂

  • Luca Donno | L2BEAT

    Reacted to "can we get a tempera..." with 👍

  • Guillaume

    Replying to "Also note that we ha..." priorities change

  • Orca 0x

    Reacted to "we can work out some..." with ❤️

  • Luca Donno | L2BEAT

    Reacted to "we can work out some..." with ❤️

  • Łukasz Rozmej

    Replying to "we can work out some..." make sense to me, to try

  • Orca 0x

    Replying to "we can work out some..." rule clarity in 8141 itself is essential

  • Parthasarathy Ramanujam

    Reacted to "we can work out some..." with ❤️

  • frangio

    Reacted to "we can work out so..." with 👍

  • Łukasz Rozmej

    Reacted to "we can work out some..." with ❤️

  • Parithosh Jayanthi

    Reacted to "priorities change" with 😅

  • Łukasz Rozmej

    Reacted to "we can work out some..." with 👍

  • nixo

    i’m for delaying this decision - it seems a bit like support is broad but weak just because of a lack of familiarity / the newness of the EIP. i think it’s on the champions to shore up people’s opinions over the next two weeks

  • Emma

    Replying to "Sorry but reth shoul..." I do not see where the conflict of interest lies…. We are here representing Reth for the Ethereum community. My thoughts are that frame txs introduce more account abstraction galaxy braining by delegating complexity into frames. Developers don't want to work with defining "frames". Reduces complexity in the sense that we don't need a "bundler" (which imo is like 5% of the problem of current AA landscape), but then introduces a ton of complexity on devtooling layer (both contracts and app devtools like viem), and makes account orchestration flows super difficult to reason about. Generally think accounts don’t need to be galaxy brained abstracted for 95% of real world users. We should enshrine native features for the 95%, and escape hatch to account abstractions for the 5%. This proposal is good for the 5% and migrating to PQ: https://github.com/ethereum/EIPs/pull/11330

  • felix (eest)

    my main impression from the eth mag thread is that many people were sceptical at first but as the EIP got clarified they understood its value and now most support it

  • Guillaume

    Replying to "Also note that we ha..." allocating 3+ years just to zk is a bad idea - so we'll need to make room for other stuff anyway.

  • nixo

    Reacted to "priorities change" with 😅

  • Shruti Gandhi

    Reacted to "Also note that we ha..." with 👍

  • nixo

    Reacted to "priorities change" with 🌳

  • Parithosh Jayanthi

    Reacted to "priorities change" with 🌳

  • Emma

    Reacted to "I don't think we'd b..." with 👍

  • lightclient

    what do people want to see in 2 weeks to sway opinion?

  • Derek Chiang | ZeroDev

    Replying to "Sorry but reth shoul..." I think it’s unfair to discount Reth’s opinion because of perceived conflict of interests. That said, I’m also trusting that Reth will go along with the decision if the clear majority is for it

  • Barnabas

    frame-devnet-0 😂

  • lightclient

    Replying to "what do people want ..." we can definitely build a prototype and bring txpool rules into 8141 itself

  • Justin Traglia

    Reacted to "Sorry but reth shoul..." with 👍

  • Nicolas Consigny

    Replying to "what do people want ..." More txpool rules ?

  • Justin Traglia

    Reacted to "There’s a clear conf..." with 👍

  • Nicolas Consigny

    Replying to "what do people want ..." yes this would be good

  • Nicolas Consigny

    Reacted to "we can definitely bu..." with 👍

  • Orca 0x

    Reacted to "we can definitely bu..." with ❤️

  • Iván | ethrex

    Let us know how we can help here, we’ll be glad to do it

  • Chris H

    Reacted to "we can definitely bu…" with 👍

  • Nicolas Consigny

    Reacted to "Let us know where we..." with 🙏

  • lightclient

    Reacted to "Let us know where we..." with 👍

  • Luca Donno | L2BEAT

    Reacted to "Let us know how we c..." with 🔥

  • Toni Wahrstätter

    Reacted to "we can definitely bu..." with ❤️

  • Ben Adams

    Reacted to "we can definitely bu..." with ❤️

  • Ben Adams

    Reacted to "we can definitely bu..." with 👍

  • Barnabas

    Reacted to "Let us know how we c..." with 🔥

  • Łukasz Rozmej

    Replying to "what do people want ..." some base on realistic tx pool rules

Key decisions

  • SSE/Pure ETH rejected as Hegotá headliner

    headlinerRejected in favor of another headliner
  • Lucid rejected as Hegotá headliner

    headlinerRejected in favor of another headliner
  • Frame transactions headliner decision delayed to March 26; requires Besu, Nethermind, or Reth support to proceed

    headlinerDelayed due to lack of support from certain clients