Ethlabs is online. Week 12.

September 13, 2026 · published as an article on X

News from our interop sprint; our updated Hegotá view; getting faster Ethereum into users’ hands.

A recurring theme in our work is the distance between a protocol improvement and the experience it makes possible. A faster confirmation rule needs someone to serve it. More capable accounts need wallets that understand them. And a proposal for faster blocks needs a path through specifications, clients and the applications that have grown around twelve-second slots.

This week, we made progress along each of these paths. Let’s dive in!

#Interop sprint updates

Two weeks ago, we started a sprint on interoperability, to come out with a clearer sense of where to focus our attention. We already have ongoing work on fast Ethereum: the Fast Confirmation Rule, fast slots and fast finality, all of which reduce the time spent waiting for Ethereum and ultimately improve interoperability on the network. We’ll also be pushing now in two additional directions.

The first is reducing L2 → L1 latency, with @decentrek leading the charge. Last week’s conversations with L2s reinforced how much users care about moving between chains. The fast confirmation rule, faster slots and fast finality all have strong potential to reduce latency going from L1 to L2s.

The return journey to L1 brings a different set of constraints: posting data, constructing and verifying proofs, and, for optimistic systems, the challenge window. We are now looking at which improvements would matter most, and where Ethlabs can make a unique contribution.

The second is account interoperability, led by @ox_shaman. Accounts should help users coordinate activity across chains: manage related accounts across chains, batch several actions, sponsor gas on a chain where the user has no funds yet, and express conditions on what should happen before the next action proceeds, possibly asynchronously.

This connects directly to our ongoing account abstraction work. We're working to harmonise the experience of native account abstraction across chains, making accounts portable. This offers an ideal window to also work on driving interoperability from the accounts, and put the right pieces together for a more seamless Ethereum UX.

A few more “pre-projects” emerged from our sprint, including: preparing the ground for broadly available zk tech rooted in L1 zkEVM, such that all messages running on Ethereum transit with the highest and most verifiable standard of security; spending time on cross-chain token standards, decoupling the application layer from the transport layer (the value from the bridge); and making L1 a stronger asset for composability. These are not things we’ll push hard on for now, but we’ll keep cooking and update as we raise conviction there.

#Refining our Hegotá view

@casparschwa, @fradamt and @adietrichs delivered an update to our Hegotá view, along with a changelog. The priorities remain stronger censorship resistance, a faster Ethereum, continued performance engineering, and native account abstraction, as they were in our first publication a couple weeks ago.

Performance work gives us choices. The headroom obtained from better clients and protocol changes can support more capacity, shorter slots, lower node requirements, or a combination of these. We want Hegotá to continue making that headroom available, while delivering improvements people can feel when using Ethereum.

The updated view also makes our assumptions and remaining questions more explicit. Supporting an EIP means helping to establish its purpose, implementation cost and path to adoption. We will keep refining our positions as client and testing teams do that work.

#Faster Ethereum updates

Some quick updates on fast slots, fast confirmation rule, and fast finality.

Our case for faster L1 slots remains that Hegotá is the right time to do a first reduction of the slot time, and that this first reduction also does the work needed to make later reductions easier. We are advocating a first move from 12 seconds to 10 in Hegotá. Find out why in this episode of Credible Commitments with @apriori0x.

Meanwhile, RPC providers are becoming central to adoption of the fast confirmation rule (FCR). As a reminder, the fast confirmation rule allows deposits from L1 to L2s, centralised exchanges and other bridges to confirm in tens of seconds instead of many minutes, speeding up liquidity flows.

Many applications and L2s get their view of Ethereum through an RPC endpoint. Their ability to use faster confirmations therefore depends on what that endpoint exposes. @_julianma and @decentrek have been working with RPC and bridge teams on this next step. In particular, some applications already rely on the “safe” block tag for justification. Providers need a clear migration path that preserves those users’ expectations while making FCR available to new adopters.

All of this work is made possible by Ethereum consensus clients pushing forward with FCR implementation and testing. This week, @prylabs joined the club!

Last but not least, @fradamt has been making progress on the formal verification of fast finality with decoupled consensus. As a recap’, this design moves finality voting out of the block production process, so we can work on the two timelines independently: faster finality, and faster slots!

The latest milestone concerns recovery: after the network returns to synchrony, the confirmation mechanisms recover safety and the finalisation and stabilisation gadgets agree with the canonical chain, under the model’s assumptions. The ability for Ethereum to weather instability is why it remains the safest chain to build on, with a defence-in-depth approach to maintaining its uptime.

The latest results were also the opportunity for Francesco to leave us with this humblebrag. He got lightly roasted in the comments for it. Yet he’s still here in the Slack asking us who’s got a reset left.

#Bonus: @binji_x on The Defiant about tokenised stocks

#On to week 13

Next week, we’re preparing the release of a survey from app devs on faster slots, and planning to establish our own view on both finality and blob targets: when to get where, and how to get there.

We’re continuing to work on the integration of two native account abstraction proposals, 8141 ("frames", now scheduled for inclusion on L1) and 8130 ("keystore", spearheaded by the Base protocol), and working towards a plan to unify wallet support for this new era of accounts on Ethereum.

---

ICYMI, here is last week’s update:

LFG

Read the original on X →