Ethlabs is online. Week 14.

September 27, 2026 · published as an article on X

A faster Ethereum: Quick Slots specs merged and a decoupled consensus proposal formally verified; one account for all of Ethereum; how far can we scale blobs?

Last week we wrote about closing the distance between a protocol improvement and the teams who depend on it.

This week, making Ethereum faster hit milestones on two timescales: Quick Slots (EIP-8198) was merged as a feature into the Ethereum consensus specs, and a proposal for decoupled consensus was formally verified, bringing 4–8x faster finality one step closer.

We also announced a coordination effort on a unified account standard, and kept charting how far blobs can scale. Let's dive in!

#Faster Ethereum

#Quick Slots specs merged

Last week we published our ecosystem survey on EIP-8198 (Quick Slots), gathering 20+ teams on why shorter slots matter to them. That case is what drives our push to lay the groundwork for faster slots in Hegotá.

This week, Quick Slots was merged as a feature spec in the Ethereum consensus specs. Merged specs signal the feature is stable enough to evaluate alongside other proposals, and give client teams a stable base to prototype against.

This doesn't mean faster slots are in Hegotá yet. Quick Slots was Proposed for Inclusion on August 6th; on October 1st, ACD will likely discuss moving it to Considered for Inclusion, with Scheduled for Inclusion as the final step. Check back next week for what's hopefully going to be good news on this front!

#Decoupled consensus, formally verified

Faster finality needs a new consensus protocol, one that decouples block production and finality voting, so that both can be as fast as possible. One constraint makes this quite a bit harder than usual: Ethereum aspires to continue having 100% uptime, to be always available and especially to be available when nothing else is.

Constructing a protocol for this goal is no easy feat, let alone a provably secure one, as correctness involves a lot more than the standard safety and liveness. This week, we're finally there! I published a decoupled consensus proposal with all of these properties machine-checked in Lean, intended to serve as the base for a full spec.

This work also gave us a glimpse of the future of protocol design. The Lean model was an integral part of the design loop, and turned out to be a superpower for agents: working against it, they could pinpoint exactly where arguments broke and propose verifiable fixes, greatly accelerating the work over the last month. Now, work to simplify and improve the protocol is following the same blueprint.

#Fast confirmation, ready for adoption

Fast confirmations are the nearer-term win, and this week the fast confirmation rule (FCR) itself was formally verified: a Lean proof that, under the rule's assumptions, a fast-confirmed block stays in every honest node's chain from the next slot on, built on a model of the Gloas consensus specs and cross-checked against the spec. Together with the EF bug bounty now covering the spec and client implementations, and our advice to fast-confirm only when two different clients agree, that is the security story @_julianma laid out this week.

Julian has also kept chasing down every blocker on the path to FCR adoption, working between both sides: the RPC providers that most apps and L2s read Ethereum through, and the bridges, L2s and exchanges that want faster confirmations.

#One account for all of Ethereum

Frame transactions (EIP-8141), recently scheduled for Hegotá, make Ethereum accounts programmable in a very general way. That generality cuts both ways: if every wallet builds its own account on top, we could repeat what happened with ERC-4337 and EIP-7702, where everything that was standardized (bundlers and paymasters) got great tooling and interoperability, while everything left modular (the accounts themselves and their features) struggled to get adopted. Features that only work in some wallets, apps that can't rely on them, and accounts you can't take with you.

We think the answer is a unified account standard for all of Ethereum, built on top of Frames. This week @ox_shaman announced that Ethlabs will be launching a coordination effort around it, working closely with the EF. We have views of our own, but wallets are ultimately the interface to users, so the standard has to be built with them rather than prescribed. If you build wallets, signers or account tooling, his DMs are open.

#How far can we scale blobs?

We continued the effort we kicked off last week to better understand blob demand and supply, as the starting point for making progress on the data layer roadmap.

On the demand side, @decentrek's L2 survey has started to collect some inputs, with many chats to follow next week. On the supply side, I have been working with @casparschwa on a blob-scaling report, seeking to understand how much throughput could in principle be supported after the Glamsterdam fork, as well as what avenues are available to continue scaling afterwards.

With the many improvements soon to be live in Glamsterdam (a lot more propagation time, cell-level messaging and sparse blob pool), preliminary results seem to support reaching 128 blobs. More on both questions soon!

#On to week 15

Next week: ACD on October 1st, where we'll push to move Quick Slots to Considered for Inclusion; refining the decoupled consensus protocol and making progress towards turning it into a full spec; continuing the work towards a unified account standard; publishing the blob-scaling report and running L2 DA calls; last but not least, some exciting news about FCR!

---

ICYMI, here is last week’s update:

Read the original on X →