AA collab, faster Ethereum, learning from L2s. Ethlabs week 11.
If you ever want more drama in your life, consider working on AA. Three weeks ago, Base began officially championing EIP-8130 for Ethereum’s native AA design, in contention with Frame Transactions (EIP-8141), a proposal favored by L1 researchers and core devs. The debate heated up and became acrimonious at times, with some accusing the L1 for being unresponsive to L2s’ needs, while others accusing Base for hijacking L1’s governance process.
At Ethlabs, we believe in two things:
- Ethereum is at its strongest when L1 and L2s work together.
- People are fundamentally kind and reasonable, and if we create dialogs between them, they can usually work out their differences and align on the best solution.
That’s why we organized a working group between the authors and supporters of 8130 and 8141 in order to unify the two proposals, so the EVM ecosystem doesn’t fragment into two incompatible and competing AA standards, which would result in inconsistent if not broken UX across EVM chains.
I’m happy to report that the authors of 8130 and 8141 are now best friends and AA is officially solved. Actually not really, but still it’s true that we have made a lot of progress towards finding a unified solution. More on this later.
On a different note — at Ethlabs we’ve been making great progress with our “Fast Ethereum” workstreams, which include:
- Fast Confirmation Rule (FCR), a secure algorithm that allows bridges and L2s to confirm L1 transactions in 12-24 seconds, 30x faster than finality.
- Fast Slots (EIP-8198), which will lower Ethereum block times from 12s to 10s immediately, while putting us on a trajectory to lowering it even further over time.
- Fast Finality, which is the result of a complete rework of Ethereum’s consensus mechanism, allowing finality to be reached in as few as 1-2 slots.
On top of all these, we’ve also become more intentional in our developer outreach. This week we interviewed two leading app-rollups and learned about their pain points, which gave us a ton of ideas for what to work on next.
Let’s dive into it.
#8130 & 8141 collab
Our main goal with this collab is to find a solution that resolves the tension between:
- L1’s need for a flexible AA scheme that can satisfy future use cases (e.g. PQ sig aggregation, privacy protocols, transaction assertions)
- L2’s need for an AA scheme that can scale to very high TPS
To achieve generality, Frames (8141) uses EVM execution to validate transactions, which is at odds with how L2s want to use native code to quickly validate transactions, just like how they use native code to validate k1 signatures for regular transactions today.
From the collab in the past two weeks, we’ve come up with a number of technical solutions for resolving this tension, including:
- Extending 7702-style delegations so that an account can explicitly delegate to code for validation, so an L2 sequencer can look at the delegation and replace the EVM code with equivalent native code.
- L2s can mandate a specific account proxy bytecode, so that they can look at a frame and know for sure what validation logic it’s going to run, again replacing the EVM code with the equivalent native code.
- L2s can simply re-interpret validation frames to mean something different entirely, such as a call to a 8130 keystore contract, which is deterministic and can be replaced with native code.
Now, it’s up to the stakeholders to decide which of these solutions, if any, satisfies their needs, and possibly come up with new solutions altogether. Base actually has an exciting update in that regard which we won’t frontrun here, but stay tuned this week!
#FCR going to production
A few weeks ago we hinted that a major bridging provider is going to roll out FCR support soon. We are happy to report that they are making great progress and are on track to an end-of-September release. We want to specifically shout out @prylabs and @Teku_Consensys for working around the clock to release FCR to support this bridging company. It’s beautiful when L1 clients and industry players work together!
On top of this, we also pitched FCR to a number of leading app-L2s (more on this later), who are excited to use FCR to lower the time for depositing from L1 to L2s. However, since these L2s mostly depend on external RPC providers to monitor L1 deposits, their adoption of FCR is blocked by the adoption of FCR from those RPC providers. As a result, @_julianma and @ox_shaman started talking to all the leading RPC providers to help them roll out FCR support asap, which will allow all RPC users to quickly confirm L1 transactions (again, 30x faster than finality!)
#More projects supporting Quick Slots
As clients debate which EIPs to prioritize for Hegotá, Quick Slots aka EIP-8198 (championed by our own @barnabemonnot) is quickly gaining traction as one of the top EIPs, as more projects recognize the UX importance of lowering Ethereum’s block time. A number of client devs have signaled to us that they will be strongly supporting Quick Slots, and Flashbots/BuilderNet publicly endorsed Quick Slots:
The BuilderNet team supports faster slots on Ethereum. Read more: https://t.co/4aTmMsUegM https://t.co/vcymVR1tWC
— Hasu⚡️🤖 (@hasufl) September 3, 2026
Overall, we are very optimistic that Quick Slots will happen in Hegotá, putting Ethereum on track to lowering block times further and further in the years to come.
#Learning from L2s
In case it’s not obvious, we LOVE L2s at Ethlabs. We think L2s are critical to the network effects of the Ethereum ecosystem and serve as the strongest distribution channels for ETH. Helping L2s succeed is therefore one of our very top priorities.
This week, we reached out and talked to two major app-L2s — @Lighter_xyz and @DeriveXYZ — to learn more about their pain points. Both projects signaled L1<>L2 interop as their top concern — how can users move tokens faster and more seamlessly between L1 and L2?
From these convos, we learned that FCR is a godsend for L2s, promising to lower L1 → L2 deposits from minutes to 12-24 seconds. On the other hand, L2 → L1 messaging is much harder to speed up, since optimistic rollups are constrained by the challenge window, while zk rollups are constrained by proving time. We won’t be talking in specifics here as some of the info is not public, but the projects gave us some very specific directions to look into for improving L2 → L1 messaging speed.
At Ethlabs, we are always excited to work with builders directly. If you are building an L2 and want someone to champion your needs to L1 core devs, please reach out and we will help!
#Looking ahead
Looking to the weeks ahead, we will be trying hard to push the 8130<>8141 collab to a successful conclusion, so users across EVM chains can enjoy greater UX on top of a unified AA foundation. We are also continuing our focus on making Ethereum faster, by rolling out FCR to more industry players, pushing for Quick Slots to be shipped in Hegotá, and improving Ethereum’s consensus algorithm to achieve faster finality.
We are also mindful that the relationship between L1 and L2s is being actively defined right now, given the success of new L2s such as the Robinhood chain. We will keep pushing for L1 developments that help L2s succeed, such as faster finality and blob scaling. Publicly, we will also be speaking up more on why we believe L2s are critical to the success of L1 and ETH.
Above it all, we will never lose sight of the people that actually matter — builders and users. We will continue to prioritize our workstreams based on what we learned from convos with people in the trenches, so our work can impact them in the here and now. If there’s something you want from Ethereum as a builder or a user, please reach out to us — we are always here to talk!