If we trace Ethereum’s upgrades over the past several years, one theme clearly stands above the rest: scaling.

Dencun introduced blobs and dramatically reduced data costs for rollups. Pectra improved validator efficiency and staking mechanics. Fusaka deployed PeerDAS to reduce the burden of data distribution. At the protocol level, nearly every effort has focused on one goal: enabling Ethereum to process more data without pushing node requirements too high.

This combination has worked. Rollup data costs have fallen, the mainnet gas limit has risen steadily, and Ethereum no longer routinely confronts users with transaction fees of tens of dollars, as it did during the previous bull market.

But although the road is now wider, driving on it still feels awkward:

• Users still need to move assets across three or four L2s, with the constant risk of withdrawing to the wrong network.

• A transfer may be included in a block within seconds, yet bridges and exchanges can still make users wait more than ten minutes for confirmation.

• Professional builders construct nearly all blocks. A sensitive transaction could potentially be excluded under off-protocol policies.

• Even today, a newcomer who simply wants to transfer a few hundred dollars in USDC must first understand why the wallet needs ETH, what a nonce is, and how gas works.

On the surface, these problems appear to be user-experience friction. Underneath, however, they involve deeper protocol mechanisms such as confirmation rules, block construction, censorship resistance, and the account model.

These are precisely the issues Ethereum is beginning to address from Glamsterdam to Hegotá—from Q4 2026 into 2027.

1. Scaling Continues, but Ethereum Is Starting to Stitch L1 and L2 Back Together

Scaling is not slowing down.

Glamsterdam remains heavily focused on performance. Two of its most important components are ePBS (EIP-7732) and Block-Level Access Lists, or BALs (EIP-7928).

Put simply:

• ePBS brings the proposer–builder separation already widely used outside the protocol into Ethereum itself. It also restructures the timing of block construction and validation, creating more room for larger blocks to propagate safely in the future.

• BALs allow a block to provide an upfront map of the state it will access. Nodes can then prefetch the required data and potentially process non-conflicting operations in parallel, helping address storage I/O bottlenecks.

Beyond scaling, however, the biggest source of frustration for most users today is not insufficient TPS. It is that there are simply too many chains.

A user’s ETH may be on mainnet, the meme token they want to trade may be on Robinhood Chain, the USDC they use for payments may be on Arbitrum, and the USDC they want to deploy into a market dip may be on Base.

From the Ethereum Foundation’s perspective, these rollups are all part of the Ethereum ecosystem. For users, moving between them can feel more like exchanging currencies and applying for visas.

Cross-chain protocols are exploring a variety of ways to reconnect these fragmented pieces. At the protocol level, one particularly important mechanism is the Fast Confirmation Rule, or FCR.

Many users assume that once a transaction is included in a block, it is final. At the consensus layer, however, a newly produced block can still be affected by a small chain reorganization. Ethereum’s full, irreversible finality currently requires two epochs, or approximately 13 minutes.

This delay rarely matters for an ordinary transfer. For bridges, large settlements, and centralized exchanges, however, it is a serious constraint. To avoid reorganization risk, they often have little choice but to make users wait.

FCR offers a more efficient approach. Rather than waiting more than ten minutes for full finality, it uses the attestations validators already produce and evaluates their accumulated voting weight to determine whether a block has received sufficiently strong consensus support at an earlier stage.

Under normal network conditions, the Ethereum Foundation aims to make this form of strong confirmation available within approximately 15 to 30 seconds.

Strong confirmation is not the same as full finality. But for bridges, cross-chain messaging systems, and other infrastructure that currently must wait for finality, it could provide an earlier confirmation signal backed by a clearly defined security model.

FCR is also unusual in that it does not need to wait for a specific hard fork. It is closer to a confirmation rule that consensus clients and infrastructure providers can adopt progressively.

Once L2s, bridges, and wallets begin using this signal, many cross-layer delays caused by waiting for L1 finality could fall from more than ten minutes to tens of seconds.

In the future, moving an asset may involve two or more chains behind the scenes. From the user’s perspective, however, it could require only one confirmation before the funds arrive moments later.

2. A Deeper Question: Who Decides Whether a Transaction Gets Included On-chain?

As blocks grow larger and builders become increasingly specialized, Ethereum faces another difficult trade-off.

Professional builders use sophisticated infrastructure, computation, and order flow to optimize block construction. But as a result, control over what enters most blocks can become concentrated in the hands of a small number of powerful organizations.

That creates a serious risk: censorship.

A builder might refuse to include an otherwise valid transaction because of regulatory pressure, commercial competition, or hostility toward a particular privacy protocol. Even if the user controls the private key and offers sufficient gas, the transaction could remain stuck outside the chain. Further reading: “Writing Censorship Resistance Into the Protocol: Who Decides Whether an Ethereum Transaction Is Included in a Block?”

If a decentralized network cannot preserve permissionless access to transaction inclusion, greater throughput alone rests on a fragile foundation.

This is why FOCIL—Fork-Choice Enforced Inclusion Lists, defined in EIP-7805—has become a central component of the planned Hegotá upgrade.

Its basic logic is deliberately straightforward: builders can optimize blocks, but they cannot unilaterally decide whose valid transactions are allowed onchain.

For each slot, the protocol selects a committee of validators. Based on the pending transactions visible in their mempools, committee members construct and broadcast inclusion lists. Builders remain free to order transactions and capture MEV, but the blocks they produce must satisfy the inclusion-list requirements.

If a builder maliciously ignores those requirements, attesters will not vote for the block under the fork-choice rules, preventing it from becoming canonical.

Put differently, builders can compete on their ability to construct profitable and efficient blocks. They cannot decide on behalf of the entire network who gets to use Ethereum.

Once this mechanism is in place, it may also provide a foundation for another long-discussed but slow-moving part of Ethereum’s roadmap: privacy.

Privacy discussions have historically focused on zero-knowledge proofs, stealth addresses, and mixing pools. But if a builder can identify a transaction calling a privacy contract and simply refuse to include it, even the most sophisticated cryptography becomes ineffective.

Within Ethereum’s emerging privacy roadmap, FOCIL addresses precisely this point of vulnerability. Only when the protocol can protect the inclusion rights of valid transactions do higher-level privacy systems have room to function.

More ambitious privacy proposals remain under discussion. EIP-8182, for example, proposes protocol-supported private ETH and ERC-20 transfers through a native shielded pool.

The broader direction is becoming clear: privacy cannot remain a peripheral feature provided by an isolated third-party DApp. Over time, it must become part of Ethereum’s foundational infrastructure.

3. The Final Step: Native Account Abstraction and Wallets Designed for Humans

The architectural changes discussed above largely operate beneath the surface. The third development, however, could directly transform the everyday wallet experience.

Ethereum is finally preparing to make deeper changes to the Externally Owned Account (EOA) model it has used for more than a decade.

For an ordinary internet user, Ethereum’s traditional private-key account model can be remarkably unforgiving:

• Lose the private key, and account access may be gone permanently.

• Hold thousands of dollars in stablecoins but lack 0.001 ETH for gas, and the assets may be temporarily impossible to move.

• A simple DeFi action may require an approval followed by a swap, with multiple signatures needed to complete a single task.

• Transaction nonces must be processed in strict sequence. If one transaction becomes stuck, every transaction behind it may also stall.

The community has introduced several intermediate solutions over the past two upgrade cycles.

ERC-4337 brought account abstraction to the application layer through smart contract wallets without changing the core protocol. Pectra then introduced EIP-7702, allowing ordinary addresses to delegate functionality to smart contract code.

EIP-7702 is ultimately a bridge. One of the most important native account abstraction proposals now being considered for Hegotá is EIP-8141, formally known as Frame Transaction.

A traditional Ethereum transaction effectively binds three responsibilities together:

who authenticates the user, who pays for gas, and what the transaction does.

EIP-8141 aims to separate these responsibilities at the protocol level through different transaction frames.

Further reading: “Native Account Abstraction + the Quantum Threat: Why Was EIP-8141 Passed Over as the Headline Feature of Ethereum’s Hegotá Upgrade?”

In practical terms, the model can be understood in three parts:

• Validation: Accounts would no longer be permanently restricted to one fixed ECDSA signing path. More flexible authentication methods, including passkeys, could become possible. Combined with biometrics such as fingerprint authentication or Face ID on mobile devices, this could make key rotation and account recovery more intuitive.

• Payment: Gas sponsorship could become more native. An application could pay gas for a new user, or a transaction flow could use USDC to cover the cost, reducing reliance on separate offchain relayers.

• Execution: Atomic batching could allow actions such as approval and swapping to be completed as one operation. Either all steps succeed together or all of them revert.

EIP-8250, or Keyed Nonces for Frame Transactions, is also under discussion. If adopted, it could give accounts multiple independent nonce lanes, allowing transactions to proceed in parallel instead of forcing every action through a single sequential queue.

If these capabilities become native to the protocol, wallets such as imToken could undergo a fundamental transformation.

Today, wallets spend significant effort reminding users to hold enough ETH for gas, explaining why transactions are stuck, teaching them to record seed phrases, and helping them switch RPC networks across different chains.

In the future, if signature schemes, gas sponsorship, permission controls, and transaction routing all become programmable, wallets could finally take on their natural role: a quiet operating layer between users and the decentralized world.

Users would retain full control, just as they do today. But interacting with the wallet could feel as intuitive as scanning a payment code or unlocking a phone with a fingerprint.

Final Thoughts

Looking back at Ethereum’s recent upgrade path, the direction is remarkably clear.

Dencun introduced blobs. Pectra continued scaling while improving validator and account capabilities. Fusaka deployed PeerDAS to prepare Ethereum for greater data throughput. Glamsterdam will use structural changes such as ePBS and BALs to lay the groundwork for higher gas limits and parallel execution.

Scaling is far from complete. But it is no longer Ethereum’s only challenge.

Ethereum can now devote more attention to some of its most fundamental—and most difficult—problems. This is why the Ethereum Foundation reorganized its protocol work in 2026 around three straightforward goals:

Scale, Improve UX, and Harden the L1.

Ethereum has already shown the world that it can function as a global computer that never stops running.

The next step is making it genuinely seamless for ordinary people to use.