A few months ago, we announced a renewed focus of Protocol on three strategic initiatives: Scale L1, Scale blobs, Improve UX. Following previous updates on Scale L1 and Scale blobs, this note relates to our “Improve UX” track, and its mission:

Seamless, secure and permissionless experience across the Ethereum ecosystem, for individuals and institutions.

We see interoperability, and related projects presented in this note, as the highest leverage opportunity within the broader UX domain over the next 6-12 months, in our position as a public, core Ethereum R&D group.

The near-term strategy focuses on areas we believe will continue to be fundamental components of interop: Intent-based architecture and general message-passing. For both, our aim is to focus on clear, measurable protocol metrics to drive down latency and cost, while increasing security and trustlessness. These metrics include: Signatures per operation, time-to-inclusion, time-to-fast-confirmation, time-to-finality, and time-to-L2-settlement.

We divide our work in three streams:

1. Initialisation: Make intents more modular and lightweight, and strengthen shared standards for seamless and secure movement of assets across all chains.
2. Acceleration: Drive latency and costs down, accelerate efforts for faster inclusion, confirmation, finality, and settlement.
3. Finalisation: Integrate frontier consensus (fast finality) and cryptography (SNARKs with real-time proving) to unlock fast, permissionless crosschain messaging.

Why focus on interop?

The Ethereum ecosystem is composed of our L1 mainnet and the many L2s that permissionlessly extend Ethereum beyond the L1’s boundaries. These extensions provide critical entry points and scaling opportunities for Ethereum, yet also bring their own challenges, chief among them the pressures of fragmentation on the Ethereum experience and its economy.

There are many potential definitions of what it means to “solve interop” and the extent to which interop is already solved. While much of the infra and tech is ready (or soon will be), there are several steps remaining to actually get these solutions into the hands of all users and inject it seamlessly into their daily UX.

At its simplified core, the key ingredients to accelerate interop boil down to unlocking fast crosschain message-passing and standardisation. Currently, message-passing is partially bottlenecked by slow settlement times. While work continues to remove these bottlenecks, we have infrastructure we can leverage today to solve the most common user flows and provide a unified experience across the Ethereum ecosystem.

Still, interop is not the only UX issue facing Ethereum users. At the end of this note, we highlight distinct EF initiatives dealing with different aspects of user-centric development, with a stronger accent on security and privacy. Beyond, many more opportunities to improve Ethereum UX will be sought and delivered by projects in our ecosystem. We look forward to celebrating their achievements and continuing to collaborate in order to strengthen the core properties of Ethereum.

Stream 1: Initialisation

Intents are one mechanism to improve UX for crosschain interactions, abstracting away the complexities of crosschain mechanics and distilling the outcome of an action. We define intents as a high-level expression of what a user wants to achieve onchain, without prescribing the exact low-level transactions that should be executed. Intents are declarative (“I want this outcome, I’m flexible about how it’s achieved”), whereas transactions are prescriptive (“call this contract with these parameters”).

The intent layer sits between order-flow interfaces (wallets) and deeper interoperability infrastructure (bridges, either canonical or private). As such, it is a strategic point to support, leveraging both the wallets’ expertise to provide the best UX and the bridges’ ability to settle the many assets deployed across Ethereum.

Yet intent protocols can often introduce trust assumptions on solver intermediaries, which can create censorship vectors and privacy issues. Other approaches, like crosschain messaging bridges or the Ethereum Interoperability Layer (EIL), also advance interop without solver dependencies. Taken together, these efforts broaden the design space for interoperability.

Project #1: Open Intents Framework

Takeaway: Laying down the foundation of neutral infrastructure supporting intents-based crosschain protocols.

The Open Intents Framework (OIF) provides modular infrastructure for each of the intent layers: Origination, fulfillment, settlement and rebalancing. It is an extensible framework laying the groundwork for further refinements, towards more secure, cheaper and faster settlement of user interactions across chains. The Open Intents Framework is a collaborative effort including core contributors from the Ethereum Foundation plus Across, Arbitrum, Hyperlane, LI.FI, OpenZeppelin, Taiko, Wonderland, and many others – a meaningful step forward for a unified yet differentiated approach to interoperability.

The OIF was built from the ground up to be as lightweight and customisable as possible, in order to accommodate different requirements and use cases across Ethereum’s ecosystem of L2s. This modularity and customization allows for easy swapping of each piece of the intents stack, to make it easy to switch out mechanisms which may have weaker trust assumptions or security guarantees. The OIF is committed to improve settlement guarantees including security, censorship resistance and privacy.

Production-ready smart contract implementations of the Open Intents Framework are live today with architecture diagrams and developer documentation. Through Q3 2025, contributing teams are finalising smart contract foundations and standards, completing auditing, and adding a few more validation mechanisms. In Q4 2025, the OIF will have completed the open-source solver and crosschain validation module. Teams will have access to the full reference solver implementation with configurable chain subscriptions, automated rebalancing capabilities, and modular validation supporting major crosschain verification protocols. New chains will be able to deploy production solvers immediately upon launch, eliminating the traditional months-long integration cycles.

Project #2: Ethereum Interoperability Layer

Takeaway: A trustless, censorship-resistant transport layer, making cross-L2 transactions feel like single-chain transactions.

The Ethereum Interoperability Layer (EIL) focuses on making Ethereum feel like one chain again, without compromising on CROPS values (censorship-resistance, open-source, privacy and security).

EIL is led by the Chain and Account Abstraction team, creators of the ERC-4337 protocol. EIL is a trustless cross-L2 interop layer, enabling seamless multichain transactions while keeping the user in control, preserving privacy and Ethereum-level censorship resistance. While intents are a declarative abstraction (“I want this outcome”), the Ethereum Interoperability Layer focuses on prescriptive execution via transactions (“here are the exact calls to make”) without trusting intermediaries.

A public design document will be released in October, with more details provided at Devconnect.

Project #3: Interop standards

Takeaway: Reducing user and developer friction across the stack with common protocols for crosschain operations.

Finally, a large set of standards will support the expansion of OIF and EIL, establishing unified design principles from the user to interop backends. These standards include Interoperable addresses (ERC-7828 and ERC-7930), asset consolidation (ERC-7811) and multi-calls (ERC-5792) for improved wallet and app UX, as well as neutral message-passing infrastructure, such as an intent standard (ERC-7683) and a common messaging interface (ERC-7786).

To date, ERC-7683 has been reviewed and revised by a group of contributors from Across, Uniswap, LI.FI, and OpenZeppelin. The main change is a higher-level interface redesign to support multiple intent origination flow, specifically for new flows such as Resource Locks and direct-to-filler transfers. In the spirit of flexibility and modularity, the revised standard will also include different auction mechanisms (e.g., Dutch, first-come first-serve) and allow for compatibility with other open-source initiatives like multi-chain inputs and interoperable addresses.

Stream 2: Acceleration

While Stream 1 builds basic services required for a neutral, user-centric and secure interoperability stack, Stream 2 aims to raise the speed limits on every node and link of the network. We focus on four key metrics detailed in the sections below: L1 time-to-inclusion, L1 time-to-strong-confirmation, L1 time-to-finality and L2 time-to-settlement.

Project #4: Fast L1 Confirmation Rule

Takeaway: Receive fast and strong L1 confirmations in 15-30 seconds instead of waiting 13-19 minutes for full finality.

Faster confirmation times are consistently cited as one of the biggest requirements for better interop across the Ethereum ecosystem. The structure of Ethereum’s Proof-of-Stake mechanism has attesters voting on the current state of the chain every slot, with full finality trailing by many slots. However, there is already a way to get faster confirmation with provable safety, but this is not well-known and usable at the moment.

Brief overview of the fast confirmation rule: Utilises the accumulated votes of attesters to provide a lower (but still strong) degree of confirmation at a much earlier point in time, while full finality is later obtained (the same exact way it is today). Under well-specified models of an adversary, a faster confirmation rule offers provable safety and represents an attractive option for mechanisms relying otherwise on full finality. We will make this fast confirmation rule usable by implementing it in all consensus clients and work to integrate its endpoint with projects interested in decreasing latency for their users.

Roberto Saltini and Mikhail Kalinin (Consensys) currently lead the specification of the fast confirmation rule and its proof of correctness. The TxRx team (Consensys) is implementing the rule in Teku, while Terence Tsao (Offchain Labs) has provided an early implementation for Prysm and Harsh Pratap Singh (EPF Fellow) is working on a Lighthouse implementation. With further simplifications expected to the specs, and a simpler path to implementation, we target Q1 2026 for availability of the fast confirmation rule in all consensus layer clients, and will work with partner projects for integration.

Project #5: Shorter L1 slots

Takeaway: Performing the research and engineering groundwork for reducing L1 slot times asap.

Significant UX improvements are obtained from shorter L1 slots, and we aim to initially target 2x shorter slots, from 12 seconds to 6 seconds. Halving the slot time not only halves time-to-L1-inclusion for L1 users, but additionally halves the time-to-strong-confirmation and the time-to-finality for consumers of these confirmation rules. This allows faster settlement, less capital in flight, and reduced fees and latency for users of interoperability protocols, as well as a greater incentive to use secure L1 settlement.

The project requires multiple workstreams: Robust data analysis for network performance and centralisation pressures (currently involving Maria Inês Silva, Sam Calder-Masson and Toni Wahrstätter), specifications of consensus and execution layer changes (involving Dankrad Feist, Justin Traglia and Milos Stankovic) and client implementations (early work from Milos Stankovic and Jihoon Song). Much of this work is independent from slot restructuring efforts such as moving to EIP-7732, enshrined Proposer–Builder Separation.

Project #6: Shorter L2 settlement

Takeaway: Reducing latency to move assets out of rollups decreases rebalancing costs and increases service quality of intents.

Optimistic rollups settle in the order of 7 days, once a long enough challenge window has remained open to contest the published state of the rollup. Shorter withdrawal windows allows for faster movement of assets from the rollup, and lowers rebalancing costs for solvers, i.e., lowers cost for users of intent protocols. It is a key lever for intents to settle greater volumes at cheaper fees. Much progress here is already underway thanks to the efforts of many across L2 and ZKEVM teams. We will work to support optimistic rollups interested in implementing ZK-based real-time proving, and/or moving to a secure 2-out-of-3 faster settlement mechanism.

Stream 3: Finalisation

The final frontier of interoperability on Ethereum is attained with two pieces of technology: Real-time proving and fast finality. Our aim will be to accelerate research and prototype initiatives to bring forward the timelines of each. To highlight the open-ended nature of this stream, we call projects here “Explorations”.

Exploration #1: Interoperability snarkification

All Protocol activities must reckon with the acceleration of SNARKs towards broad availability. For instance, the “Scale L1” track plans early work towards the progressive integration of this technology in the core of the Ethereum protocol. Likewise, it is not possible today to ignore the snarkification of everything, in particular as it relates to interoperability solutions.

With a robust intents-based approach to crosschain UX, the objective is to continue accelerating and solidifying the backends of these systems, to the point of lowest friction. Fast settlement allows for fast liquidity rebalancing, cutting costs for intent users. And beyond reduced costs and latency, we believe that snarkification has the potential to redraw the map of asset issuance, bridge primitives and crosschain programmability, enabling among other things synchronous composability with L1. Getting ahead of this revolution puts us in control to steer our network towards the futures that we desire.

With some SNARK-based versions of the faster L2 settlement mechanism described in Project #6, optimistic rollups have the potential to unlock a “fast root” against which their state can be assumed to be settled. Yet it is also possible to permissionlessly obtain this fast root, and “zkSettle” against it. In particular, this form of settlement may be introduced as a mechanism available through the Open Intents Framework (Project #1), ensuring the most robust form of intent settlement and maximal user protection.

Exploration #2: Faster L1 finality

We propose exploring all paths to bring finality forward from today’s 13-19 minutes to the order of seconds. First, shorter slots as described in Project #5 will halve the finality time, bringing us to 7-10 minutes. Second, beacon chain changes could accelerate it further, down to 1-2 minutes. Finally, replacing our current consensus protocol, Gasper, with a leaner and faster protocol, will yield an extra order of magnitude improvement, with target finality obtained in under 10 seconds.

The EF Protocol Consensus team is working on several projects illuminating the decision tree for a robust, performant and decentralised consensus protocol. 3-slot-finality (3SF) is a well-understood protocol obtaining strong safety with dynamic availability, a combination unique to protocols such as Ethereum’s. Explorations in newer classes of protocols such as Kudzu, Hydrangea or Alpenglow reveal opportunities for improvements on 3SF with lower latency and higher throughput, but must be designed for Ethereum’s unique properties.

Improving UX has grown to become a multi-faceted effort, with several distinct streams of work tackling issues from interoperability, security and privacy. With this note, we’re clarifying our own interoperability work, and invite you to find more details on Trillion Dollar Security and the Kohaku privacy wallet below.

Trillion Dollar Security

Led by Fredrik Svantes and Josh Stark, the Trillion Dollar Security (1TS) initiative is an ecosystem-wide effort to upgrade Ethereum’s security to help bring the world onchain. Phase 2 of 1TS tackles UX, including better models of clear signing, key management and wallet security and privacy standards.

Kohaku

Led by Nicolas Consigny and Vitalik Buterin, the Kohaku project develops the necessary technology to power wallets that are private across their entire stack. The project is developed in collaboration between the EF and various external teams. Kohaku’s core goals are (i) an SDK that exposes strong privacy/security primitives and (ii) a power‑user wallet that ships on top of that SDK. In a first phase the project will focus on the browser extension that targets advanced users introducing privacy and security features. The extension is designed to preserve privacy while reducing trust assumptions and eliminating unnecessary external dependencies. The project will ship with Helios lightclient, a privacy‑service abstraction, support for private addresses, native private balances & private sends.

Following up from Protocol Update 001, we’d like to introduce our approach to blob scaling. The L1 serves as a robust foundation for L2 systems to scale Ethereum, and a necessary component of secure L2 solutions is data availability provided by the L1. Data availability ensures that updates L2s make back to the L1 can be verified by anyone. Blobs are the unit of data availability in the protocol today, so scaling the blob count per block is a key requirement to usher in a wave of L2 adoption for use cases like real-time payments, DeFi, social media, gaming, and AI/agentic applications.

Our work is structured as a series of incremental changes to Ethereum’s blob architecture. To accelerate our rate of scaling, we are expanding from a “fork-centric” philosophy to also ship incremental optimizations in non-breaking ways as they become ready. Thus, we have the following projects tied to both network upgrades, but also the periods in between (“interfork”).

TL;DR

• Fusaka introduces PeerDAS, a new data architecture that allows blob scaling beyond today’s throughput levels from 6 blobs/block up to 48 blobs/block
• Blob Parameter Only (BPO) forks gradually increase mainnet blob count, bolstered by incremental peer-to-peer bandwidth optimizations
• Advanced networking techniques planned for Glamsterdam iterate on the PeerDAS design to scale even further
• Mempool sharding preserves Ethereum’s values as data continues to scale
• Research into the next generation of DAS unlocks an evolution in secure DA scaling

PeerDAS in Fusaka

The first milestone is the delivery of PeerDAS in the upcoming Fusaka network upgrade. PeerDAS introduces data availability sampling (DAS), where an individual node only downloads a subset of the blob data in a given block. Together with randomized sampling per node, computational load is bounded, even as the total blob count increases. As nodes no longer need to download all the blobs in a block, we can raise the blob count without a commensurate increase in node requirements.

Fusaka is expected later this year with implementations in all Ethereum clients. Extensive testing has been performed on development networks (“devnets”) including non-finality scenarios and adversarial “data withholding” conditions. At this point in the R&D process, we continue to harden existing devnets and plan deployment to testnets and mainnet. Barnabas Busa is leading the charge here to ensure smooth progression through the final stages of the upgrade pipeline.

PeerDAS v1.x

We have two prongs of non-consensus changes in our strategy to progressively scale blobs in between the Fusaka and Glamsterdam upgrades: BPOs and bandwidth optimizations. These are additive as better bandwidth utilization lets us leverage resources towards higher throughput.

BPO

PeerDAS introduced in Fusaka sets the stage for a theoretical increase of 8x from the throughput of Ethereum today (i.e. ~64 KB/s to ~512 KB/s). Rather than immediately jump to this theoretical max at the time of Fusaka deployment, core developers have elected for a more gradual increase via “blob parameter only” hard forks. This mechanism lets core developers program automatic increases in blob capacity over time, keeping us on a continuous growth trajectory. Once programmed, BPOs don’t require any manual intervention to activate. In between steps, we’ll monitor the network and react to scaling bottlenecks that may only present themselves on mainnet, paving the way for the next increase. Barnabas Busa along with others on the EF PandaOps team work closely with the client teams to distill the correct schedule to achieve the 8x scaling from today.

Bandwidth optimizations

There’s a lot we can do to more efficiently use bandwidth on the network. Raúl Kripalani along with Marco Munizaga are leading efforts on this network engineering work. A particularly promising optimization is the introduction of “cell-level messaging” which allows nodes to more intelligently query for parts of the samples introduced in PeerDAS. This change reduces redundant communication on the network, and the bandwidth savings can, in turn, be dedicated to the safe provisioning of even more blob capacity. No consensus or execution protocol changes are needed to unlock this milestone, so they can be shipped interfork before Glamsterdam next year.

PeerDAS v2

This project refers to the next generation of the PeerDAS design that affords even more scale while capitalizing on the bandwidth savings realized from pipelining introduced by EIP-7732 (scheduled for inclusion in Glamsterdam). There are further refinements to cell-level messaging and data reconstruction techniques that let nodes more flexibly sample individual parts of blobs so that the core idea of DAS can be expressed in full. These gains, along with the pipelining benefits that allow for more efficient utilization of the time between blocks, set us up to scale beyond the limits of imminent PeerDAS designs. There are many moving pieces, and exact numbers need to be calibrated to both performance of implementations and mainnet analysis as the blob count is actually scaled in a production setting, but this work should give us the final multiples on DA throughput before needing to seek alternative designs.

This batch of updates will go into the Glamsterdam upgrade expected in the middle of 2026. Alex Stokes and Raúl Kripalani are coordinating the R&D here to ensure we can keep scaling blob throughput.

Blobpool scaling

While the benefits of scaling are clear, we must do so while preserving Ethereum’s core values. One of these directly relevant to blob scaling is censorship resistance. The mempool serves as a decentralized network for blob inclusion and directly provides censorship resistance in the face of a centralized builder network producing most blocks on Ethereum. While instances of censorship have improved over time, it is tantamount to the scaling strategy to also ensure the blob mempool scales with it.

Csaba Kiraly is leading work here so we can maintain this critical resource. Current implementations support near-term blob throughput with vigorous research into the best ways to scale the mempool as we get to higher levels unlocked with Fusaka and beyond.

Future of DA

Beyond future iterations of PeerDAS, we have a variety of research directions to keep scaling DA while retaining the security properties of Ethereum that make it unique. Proposals generally fall under the moniker FullDAS with several flavors under active investigation. A key component of these proposals all involve innovations in peer-to-peer networking that allow for a highly diverse set of participants to shard an increasing number of samples while remaining fault tolerant to adversarial actors. Work such as Robust Distributed Arrays formalizes this notion. Other considerations include low-latency inclusion, censorship resistance, and evolutions of the blob fee market to make it easier to get blobs onchain.

Research here is stewarded by Francesco D’Amato and is very active – reach out if you’d like to collaborate!

In June, we introduced Protocol, reorganizing the Ethereum Foundation’s research & development teams to better align on our current strategic goals, Scale L1, Scale Blobs, and Improve UX without compromising on our commitment to Ethereum’s security and hardness.

Over the coming weeks, we’ll publish updates on each work stream, covering their ongoing progress, new initiatives, open questions and opportunities for collaboration. We start today with Scale L1 — expect follow-ups about Scale Blobs and Improve UX soon!

TL;DR

• Marius van der Wijden joined Ansgar Dietrichs and Tim Beiko to co-lead Scale L1
• Mainnet’s gas limit increased to 45M post-Berlinterop, a first step on the road to 100M gas and beyond 
• All major execution layer clients shipped Pre-Merge History Expiry, significantly reducing node disk usage
• Block-Level Access Lists (BALs) are being considered as a headliner for Glamsterdam
• Compute & state benchmarking initiatives are underway to better manage EVM resource pricing and performance bottlenecks
• The path to zkEVM real-time proving is becoming more concrete, with the prototyping of a ZK-based attester client underway
• We are still hiring a Performance Engineering Lead: applications close Aug 10

Geth-ing Serious About L1 Scaling

Scaling Ethereum requires reconciling ambitious designs with engineering pragmatism. To help us achieve this, we’ve appointed Marius van der Wijden as co-lead for Scale L1 alongside Ansgar Dietrichs and Tim Beiko.

Marius’s extensive engineering experience on Geth combined with his commitment to protocol security make him a perfect fit to align our scaling strategy with Ethereum’s constraints.

Together, Ansgar, Marius and Tim have defined a set of key initiatives that will enable us to Scale L1 as quickly as possible. 

Towards a 100M Mainnet Gas Limit

Our immediate goal is safely scaling Ethereum’s mainnet gas limit to 100M per block. Parithosh Jayanthi, closely supported by Nethermind’s PerfNet team, is leading our work getting through each incremental increase.

At the recent Berlinterop event, client teams significantly improved their worst-case performance benchmarks, enabling the recent increase to 45M gas — a first step on the path toward 100M gas and beyond!

Additionally, client hardening has become an integral part of the 100M Gas initiative. The Pectra upgrade rollout highlighted several issues caused by network instability. It is paramount to ensure clients remain robust as throughput increases, even if the network temporarily loses finality.

History Expiry

The History Expiry project, led by Matt Garnett, reduces Ethereum nodes’ historical data footprint. The recent deployment of Partial History Expiry removed pre-Merge historical data, saving full nodes approximately 300–500 GB of disk space. This ensures they can run comfortably with a 2TB disk.

Building on this, we’re now developing Rolling History Expiry, which will continuously prune historical data beyond a fixed retention period. This will keep nodes’ storage needs manageable, even as Ethereum scales.

Block-Level Access Lists

Block-Level Access Lists (BALs), championed by Toni Wahrstaetter, are emerging as a leading candidate for inclusion in the Glamsterdam upgrade. BALs provide several critical benefits:

• Enable parallel transaction execution within blocks.
• Facilitate parallel computation of state roots, significantly speeding up block processing.
• Allow preloading of required state at the start of block execution, optimizing disk access patterns.
• Improve overall node sync efficiency, benefiting new and archival nodes.

These improvements collectively enhance Ethereum’s capacity to reliably handle higher gas limits and faster block processing.

Benchmarking & Pricing

An ongoing challenge in scaling Ethereum is aligning the gas costs of EVM operations with their computational overhead. The performance of worst-case edge cases currently limits network throughput.

By improving benchmarking infrastructure and repricing operations that can’t be optimized by clients, we can make block execution times more consistent. If we close the gap between the worst and average case blocks, we can then raise the gas limit commensurately.

Ansgar Dietrichs leads efforts focused on targeted benchmarking and engineering interventions, informed directly by PerfNet’s comprehensive benchmarking, to identify and resolve compute-heavy bottlenecks. Significant progress has already been made post-Berlinterop, particularly in managing worst-case compute scenarios.

In parallel, Carlos Pérez spearheads Bloatnet: an initiative aimed at benchmarking and optimizing state performance. This involves testing node performance under conditions with state sizes double the current mainnet and gas limits reaching 100–150M, to directly inform both repricings and client optimizations.

Both of these efforts will inform Glamsterdam EIP proposals to homogenize resource costs across operations, enabling further L1 scaling.

zkEVM Attester Client

Today, Ethereum nodes execute all transactions in a block when receiving it. This is computationally expensive. To reduce this computational cost, Ethereum clients could instead verify a zk proof of the block’s execution. To enable this, proofs of the block must be produced in real time, which we are getting closer and closer to.

Kevaundray Wedderburn is leading work on a zkEVM attester client that assumes we have real time proofs and uses them to fulfill its validator duties.

Once the prototype is ready for mainnet, it will roll out as an optional verification mechanism. We expect a small group of nodes to adopt this over the next year, allowing us to build confidence in its robustness and security.

After this, Ethereum nodes can gradually transition to zk-based validation, with it eventually becoming the default. At that point, L1’s gas limit could increase substantially — even go beast mode!

RPC Performance & Hiring

As throughput increases, different node types (execution, consensus, RPC) face distinct challenges. RPC nodes specifically encounter heightened pressure as they serve extensive historical and real-time state requests.

Internally, the EF’s Geth and PandaOps teams are actively researching optimal configurations for different node types. We expect the importance of this to increase in the coming years and want to grow our expertise in this domain.

To that end, we’re actively hiring for a Performance Engineering Lead. Applications close August 10. If you’re as excited as us about scaling the L1, we’d love to hear from you!