Ethereum’s roadmap is starting to shift from raw scaling to the mechanics that shape day-to-day use, according to a Foresight article written by imToken. The piece frames the next stage, from Glamsterdam to Hegotá and from Q4 2026 into 2027, as a period in which Ethereum begins to deal more directly with confirmation rules, block construction, censorship resistance and the account model itself.
Scaling remains in place, but scaling is no longer the only issue
The article says Ethereum’s recent upgrade path has had a clear through line: scaling. Dencun introduced blobs and sharply cut data costs for rollups. Pectra adjusted validator efficiency and staking mechanics. Fusaka is expected to bring PeerDAS to reduce the burden of data distribution. In the author’s view, the protocol has spent most of its effort on one goal: letting Ethereum handle more data without pushing node requirements too high.
That effort has produced visible results, the piece says. Rollup data costs have fallen, the mainnet gas limit has been rising, and Ethereum no longer looks as inaccessible as it did in the previous bull market, when fees could reach levels that kept ordinary users away.
Yet a wider road does not automatically make driving easier. The article lists several frictions that still define the user experience: moving assets across three or four Layer 2 networks and risking a transfer to the wrong chain, waiting more than 10 minutes for bridges and exchanges to recognize a transaction that was already included in a block within seconds, relying on a block-building market that is increasingly dominated by specialized builders, and forcing new users to understand why a wallet needs ETH for gas before they can send a few hundred yuan worth of USDC, along with concepts such as nonce and gas.
In the article’s telling, these do not just sit at the interface layer. They trace back to protocol-level questions around confirmation, block construction, censorship resistance and the account model.
Glamsterdam keeps the performance agenda moving
The article says Ethereum is not stepping away from scaling. Glamsterdam still carries a strong performance focus, and two of the changes it highlights are ePBS under EIP-7732 and Block-level Access Lists, or BAL, under EIP-7928.
As described in the piece, ePBS would formalize the proposer-builder split that already exists largely outside the protocol today, while also restructuring the timing window for block production and validation in a way that leaves more room for larger blocks in the future. BAL would put an access list at the start of a block so nodes can prefetch data and potentially process parts of the workload in parallel, targeting storage I/O bottlenecks.
Still, the article argues that many users are not primarily asking for more TPS. Their more immediate problem is fragmentation across too many chains.
It gives a simple example: ETH may sit on mainnet, a meme trade may happen on Robinhood Chain, USDC used for payments and settlement may be on Arbitrum, while other USDC positioned for a dip buy may be on Base. From the Ethereum Foundation’s perspective, those rollups are all part of one Ethereum map. For users, the article says, it feels more like moving money across borders and dealing with visa paperwork.
FCR aims to cut confirmation wait times from roughly 13 minutes to 15 to 30 seconds
To reconnect Layer 1 and Layer 2 into something that feels more unified, the article points to Fast Confirmation Rule, or FCR, as a protocol-level mechanism worth watching.
It notes that many people treat inclusion in a block as sufficient confirmation, but at the consensus level a fresh block can still be exposed to small reorgs. Full irreversibility, or finality, takes two epochs on Ethereum and lasts about 13 minutes.
That may be tolerable for ordinary transfers, but it is a serious delay for bridges, large liquidations and centralized exchanges, which often make users wait because they do not want to absorb reorg risk.
FCR approaches the problem by not waiting for full finality. Instead, it uses attestation data that validators already continue to produce and weighs the voting power that has accumulated around a block to determine earlier whether that block already has sufficiently strong consensus support.
The article says the Ethereum Foundation’s target is for FCR to provide this kind of strong confirmation in about 15 to 30 seconds when the network is syncing normally. It makes clear that this is not the same as full finality, but it could still provide bridges, cross-chain messaging systems and other infrastructure with an earlier confirmation signal backed by a defined security model.
Another point the article stresses is that FCR does not need to wait for a specific hard fork. It is described more as a confirmation rule that consensus clients and infrastructure providers can adopt step by step.
If Layer 2 networks, bridges and wallets begin to rely on that signal, the article argues, a large portion of the cross-layer delay currently tied to waiting for Layer 1 finality could fall from more than 10 minutes to tens of seconds. From the user’s side, asset movement may eventually look like one tap, even if the backend routes value across two or more chains.
Hegotá puts transaction inclusion and censorship resistance closer to the center
The piece then turns to a more basic issue: who gets to decide whether a transaction can make it on chain.
It argues that as blocks get larger and builders become more specialized, block construction becomes highly efficient but also more concentrated in the hands of a small number of large operators. That concentration creates censorship risk.
In the article’s example, if some builders choose to ignore legal transactions in the mempool because of compliance pressure, business incentives or hostility toward certain privacy protocols, a user may still find that a transaction stays outside the chain despite controlling the private key and paying enough gas.
That is why Hegotá gives such a prominent role to FOCIL, or Fork-choice Enforced Inclusion Lists, under EIP-7805, according to the article.
The mechanism is straightforward. In each slot, the protocol randomly selects a group of ordinary independent validators and asks them to place the legal pending transactions they see in the mempool into an inclusion list. Builders can still arrange transaction ordering freely and pursue MEV, but the block they submit must contain the transactions on that list.
If a builder ignores the list maliciously, validators across the network would reject that block through the fork-choice rule. The article summarizes the principle bluntly: builders can profit from their skill, but they should not decide on behalf of the whole network who is allowed to use Ethereum.
Privacy proposals depend on protected transaction access
The same framework also matters for privacy, the article says. For years, discussion around Ethereum privacy has centered on zero-knowledge proofs, stealth addresses and mixers. But if a builder can identify a call to a privacy-related contract and refuse to include it, higher-layer privacy design can be neutralized before it has a chance to work.
Viewed this way, FOCIL addresses the point where privacy efforts are most vulnerable: the ability of a legal transaction to gain protocol-level access to block space. The article argues that upper-layer privacy exploration has a viable path only if that access right is protected at the protocol level.
It also mentions EIP-8182, an attempt to introduce a native shielded pool at the protocol level, as a more aggressive privacy proposal that remains in the Proposed stage. Even so, the article says the direction is becoming easier to read. Privacy should not remain a marginal feature delivered only by third-party dApps; it needs to move closer to becoming part of Ethereum’s base infrastructure.
Native account abstraction is framed as the final step for wallet usability
The third major issue in the article is the account model. Ethereum, it says, has finally decided to make a much bigger move against the externally owned account model that has defined the network for more than a decade.
The criticism is direct. The current private-key signing model is hard on mainstream internet users. Lose a private key and recovery may be impossible. Hold large stablecoin balances but lack 0.001 ETH for gas, and funds can become temporarily unusable. A DeFi trade may require an approve action and then a swap, with multiple signatures for one objective. Nonces have to line up in strict order, so one blocked transaction can hold up everything behind it.
The article notes that the community has tried intermediate fixes. ERC-4337 used smart contract wallets outside the protocol as a workaround. Pectra also introduced EIP-7702, which lets a regular address temporarily attach contract logic and gain some flexibility.
But it describes EIP-7702 as a temporary bridge rather than the final answer. In Hegotá, the bigger item is EIP-8141, native account abstraction through Frame Transactions.
The article breaks a transaction into three functions that Ethereum has historically tied together: proving identity, paying gas and executing the requested action. EIP-8141 would separate those at the protocol level into different frames.
- Verification frame: no longer fixed to ECDSA signatures, with room for more flexible methods such as passkeys and, in combination with phone biometrics like fingerprints and Face ID, a more natural path for key rotation and account recovery.
- Payment frame: native gas sponsorship, allowing an application to pay gas for a new user directly or letting fees come out of USDC specified in the payment frame.
- Execution frame: native atomic batching, so approval and swap can happen together, with success applied together and failure rolled back together.
The article adds that EIP-8250, or Keyed Nonces, is also under discussion and could eventually give accounts multiple parallel nonce lanes.
If these capabilities settle into the protocol itself, the piece says, wallets such as imToken would be freed from much of the work they now spend on teaching users to keep gas on hand, explaining why transactions are stuck, walking people through mnemonic backup, and switching RPC endpoints across chains.
In that model, once signing methods, gas sponsorship, permission control and transaction routing become programmable, wallets can return to what the article sees as their proper role: a quiet operating system between users and the decentralized world. Control remains with the user, but the intended feel is closer to scanning a code in Alipay or unlocking a phone with a fingerprint.
Three goals for the next phase
In closing, the article lines up the recent and upcoming upgrades this way: Dencun handled blobs, Pectra continued scaling while improving validator and account capabilities, Fusaka uses PeerDAS to prepare for higher data throughput, and Glamsterdam is expected to use structural changes such as ePBS and BAL to support a higher gas limit and parallel execution.
Scaling, the article says, is still unfinished. It is simply no longer the only question. When the Ethereum Foundation reorganized protocol research priorities in 2026, it summarized the next phase with three goals: Scale, Improve UX, and Harden the L1.
The piece ends on that note. Ethereum has already shown that it can function as a world computer that does not shut down. The next task is making it smooth enough for ordinary users to actually use.
