Ethlabs is online. Week 10.

August 31, 2026 · published as an article on X

Account Abstraction on L1; Motivations and principles of fast Ethereum; Fast finality formalisation milestone.

We’re all back from upstate NY and locked in until our next travels, which include Token 2049 in Singapore (Oct.), a core protocol workshop in the UK (Oct.), and Devcon in India (Nov.)

Speaking of Devcon, I had a chance to chat with a few builders based or orbiting around Mumbai this week, after sharing this prompt on X. The 5 or so calls that took place gave me some nice insights into the local crypto scene and more largely in the country, with some privacy- and institutional-minded builders. I look forward to meeting more of them in Mumbai, and until then I am still happy to connect with anyone there who could tell me more in advance!

Alright, beyond this, this was a busy week for us, with intense discussions on the future of account abstraction on the L1.

#A platform for abstracting accounts

One thesis we’ve developed for Ethlabs is being the team that refines core protocol affordances into product-ready interfaces, interfaces helping Ethereum put its best foot forward for UX and adoption. This week’s work is in that direction, and a strong test for this thesis.

To set the stage, account abstraction refers to a universe of proposals meant to open up the possibilities of what an account can be and can do. The simplest account in Ethereum is “externally owned”: there is a private key corresponding to the account, and a valid signature from this private key authenticates a transaction sent from this account, which then pays for its inclusion.

With account abstraction, every step of the sentence above can be generalised:

• An account can define its own authentication, e.g., choose its own signature scheme, including passkeys or post-quantum schemes.
• An account can define when its transactions are invalid, e.g., for enforcing policies like “spend no more than 1000 USDC per day”.
• An account’s fee for inclusion may be sponsored by a third-party, removing the pesky cold-start problem of unfunded accounts wanting to initially transact, or the fee may be paid in ERC20 tokens like stablecoins (which are swapped under the hood for ETH via “paymasters”).

There is a long history of proposals and upgrades moving Ethereum accounts closer to a fully protocol-legible abstraction, and this week the two that have made the news are EIP-8141: Frame transaction, forerunner of any other proposal to become the definitive L1 “native AA” version, and EIP-8130: Account abstraction by account configuration, proposed by @_chunter from Base, and adapted to the needs of Base.

From a 10,000m view, EIP-8130 looks more like a turnkey solution for accounts, that gives wallets an easy-to-integrate solution, by configuring strong defaults and restricting functionality. Meanwhile, EIP-8141 is really more like a platform for accounts, giving the raw ingredients required to make the Ethereum protocol extensible without intervention, when it comes to developing new accounts, e.g., new signature schemes, new sponsorship methods etc.

On our side, Derek @decentrek, who is a co-author of EIP-8141, has led conversations seeking to learn from EIP-8130 to improve EIP-8141’s affordances.

While it is, from my perspective, in the L1’s core ethos to rarely enshrine more than the basic building blocks, developing strong building blocks has a multiplier effect for all products that will rely on these primitives. With respect to EIP-8141, there is a nice collection of those building blocks for privacy protocols particularly, proposed as separate EIPs for Hegotá inclusion. Our view on those is here.

Modular building blocks also helps defragment the ecosystem, with account portability even if the rails aren’t the same on Mainnet and on Base: the cargo can still shift from one train to the other. Ethlabs believes in the positive network effects brought on by L2s, and ensuring good compatibility between economic activity on L1 and on L2s is key to these network effects. This means it is worth going the extra mile for deeper integration between L1 and L2s.

Discussions progressed with two separate calls last week, one breakout for frame transactions and this week’s ACDE. The latter had a particularly unexpected twist in the last 5 minutes of the call, where EIP-8141 was “Scheduled for Inclusion” to Hegotá, the strongest signal of approval by Ethereum core developers. Does this mean the hope for integrating some of EIP-8130’s ideas in EIP-8141 is over? Not really. There’s some technicalities here, and besides, EIP-8141 still has opportunities to learn more from EIP-8130. Once again, @decentrek has the lowdown:

See you tomorrow for another frame transactions breakout.

#Fast Ethereum

On Wednesday I posted a longer tweet presenting some of the motivations and principles behind “fast Ethereum”.

No point rehashing what’s already in there, if not to highlight the ongoing advocacy for faster blocks in Hegotá. We are working under the assumptions that:

• Hegotá is the last window before long to get started with block time reductions,
• Getting started is the hard part, with a one-time cost to pay for making the chain able to transition from the current block time to a lower one.

This is why we are proposing to do the work of making the chain able to transition to lower block times, along with a first, 2-second reduction from 12 seconds to 10 seconds in Hegotá. This week, we’re talking with apps, infra and user groups benefiting from the reduction.

#Fast finality

Related to a faster Ethereum, Francesco @fradamt shipped a big update to the current formalisation of decoupled consensus, the favoured model for faster finality on Ethereum.

As a recap’, decoupled consensus move getting to finality out of the block production process. This means optimising for faster finality and optimising for faster blocks are no longer in tension, and can be optimised independently. The hope is to move forward with decoupled consensus in I*, the fork following Hegotá. This would already slash finality times by many multiples, hopefully moving it to a few minutes instead of the current 15 minutes average.

Francesco shared pseudocode for all independent components of decoupled consensus, and their assembly into the whole consensus protocol. Decoupled consensus is intricately built from these components, including an available chain where blocks are appended, a finality gadget finalising this available chain, and a stabilisation gadget meant to kick in when the validator set doesn’t come to an agreement for whatever reason, ensuring the chain stays resilient even while not finalising.

The finality gadget component has been quite stable for a long time, with accountable safety formally verified multiple times independently. For the complete protocol, formal verification work is ongoing, and has already been quite fruitful, producing findings that have led to small protocol adjustments. In general, formal verification has over the last few months evolved into an active component of the feedback loops of protocol development, rather than merely an expensive final verification step.

Meanwhile, the write-up is under review by researchers and engineers from multiple organisations: EF Protocol, Consensys TX/RX and the Prysm consensus client team among others. This is the type of distributed work that Ethereum excels at!

#On to week 11

This week, we’re sprinting on interop in our team, with a few internal sessions to scope out our next steps. We’ll also continue to mediate AA discussions, and do outreach to prospective users of the fast confirmation rule.

---

ICYMI, here is last week’s update:

P.S.: We are still looking for the owner of the Ethereum logo sign we spotted in front of that random supermarket!

Read the original on X →