Ethereum's Fusaka Upgrade Roadmap: Which EIPs Will Actually Change How You Use the Chain?
For every Ethereum mainnet hard fork I write a plain-English explainer for normal humans. Constantinople, Berlin, London, Merge, Shanghai, Dencun, Pectra. I have not missed one. The next is Fusaka (Fulu + Osaka, named after one execution-layer and one consensus-layer city). Current EF timeline says testnet in Q3 2026 and mainnet activation between late 2026 and Q1 2027.
Fusaka does not have a single headline EIP the way Pectra had 7702. It is more of a “finish the things we started” integration upgrade. Data availability, EVM bytecode format, state management, permission model. Every track advances one notch.
This post walks through the seven most consequential EIPs in priority order. By the end you should be able to explain Fusaka over dinner.
If you have not read my pectra upgrade explained post yet, skim that first. I assume you know what Pectra shipped.
EIP-7594: PeerDAS, blob capacity goes up again
This one ranks first because it directly cuts L2 costs.
Context: Pectra raised blob count per block from 6 to 9. Fusaka uses PeerDAS (Peer Data Availability Sampling) to target 48 blobs per block, theoretically cutting L2 data costs by around 80%.
Mechanism: Today every node downloads every blob, capping the count. PeerDAS lets each node download a small slice and verify total availability through P2P sampling.
Impact on users: Arbitrum, Optimism, Base per-tx costs could drop from $0.03 to roughly $0.005. Combined with the Interop Layer, L2 UX closes the gap with Web2 further.
Risk: If the sampling math is off, you can get edge cases where data looks available but is actually missing. EF spent two years on formal proofs here.
EIP-7787: the EIP-7702 permission model upgrade
In my eip-7702 one year review I complained about the rate of phishing delegations.
Fusaka introduces EIP-7787 which adds function-level scoping to 7702:
- Authorize a contract to call only your transfer function, not approve.
- Add per-call caps and time windows.
- Bundle multiple fine-grained authorizations into one signature.
This is the EIP that actually makes 7702 safe enough for mainstream use. I call it “7702 v2.”
EIP-3540 / 3670 / 7480: EOF (EVM Object Format)
EOF restructures EVM bytecode from a “blob of bytes” into a “container with sections.”
Benefits:
- Bytecode becomes statically analyzable at deploy time, catching obvious bugs early.
- Clear function boundaries enable more precise gas accounting.
- A foundation for future EVM upgrades (Verkle, SSA, etc).
For developers: Solidity 0.9 emits EOF by default. Deployment cost drops about 10% and runtime gas slightly improves.
For users: fewer contract bugs. Given how many entries in most common smart contract vulnerabilities 2026 are bytecode-level, this is not a small win.
EIP-7873: state expiry phase one
Ethereum has a long-standing problem. Full-node state crossed 750 GB by late 2025 and grows 100+ GB per year. Without action, in five years no one will run a full node at home.
EIP-7873 introduces the first phase of state expiry:
- Long-untouched state (e.g. contract storage idle five years) becomes “archived.”
- Nodes keep only recently active state (“live state”) and fetch archived state from external DA when needed.
- Accessing archived state requires a “resurrection proof.”
Invisible to most users. Critical for home node operators. Together with client diversity, this determines Ethereum’s decentralization runway for the next half decade.
EIP-7805: Inclusion Lists, harder censorship
Censorship resistance is core to Ethereum’s value proposition. After Pectra, the MEV-Boost setup concentrated block production among a handful of relays, which has been heavily criticized.
EIP-7805 introduces Inclusion Lists:
- A previous slot’s randomly selected validator publishes a list of “must-include” transactions.
- The builder picks transaction order, but cannot fully exclude transactions on the list.
This pushes censorship resistance from policy into protocol. In an OFAC-list era this matters more than it looks.
EIP-7732: ePBS (enshrined proposer-builder separation)
MEV-Boost is an out-of-protocol bolt-on. Flashbots and other relays effectively became critical infrastructure. The community has long wanted PBS in the protocol itself.
ePBS separates proposer and builder roles natively:
- Proposers only decide who builds the next block.
- Builders package transactions and pay the proposer.
- Relays are no longer required.
Large implications for the MEV economy. Flashbots’s role likely shrinks.
EIP-7251 follow-up: validator consolidation, next step
Pectra’s EIP-7251 raised the max effective stake per validator from 32 to 2048 ETH. Fusaka adds automatic rebalancing, letting many small validators merge or split in-protocol without manual ops.
Solo stakers barely notice. Lido, Coinbase, and large operators see ops cost drop a further 20-30%.
Timeline and what I personally watch
| Phase | When | Status |
|---|---|---|
| Devnet 1 | Q4 2025 | done |
| Devnet 2-4 | Q1-Q2 2026 | ongoing |
| Public testnet (Holesky successor) | Q3 2026 | planned |
| Mainnet activation | Q4 2026 - Q1 2027 | tentative |
The three I watch most:
- EIP-7594 (PeerDAS) decides whether L2 costs drop another notch.
- EIP-7787 (7702 v2) decides whether smart accounts truly go mainstream.
- EIP-7873 (state expiry) decides whether home nodes survive.
The others matter, but these three directly shape your next year of Ethereum usage.
What comes after Fusaka
Per Vitalik’s EthCC remarks, the next hard fork is tentatively Osaka-Glamsterdam, focused on Verkle trees, switching state from Merkle Patricia Trie to Verkle Trie and shrinking node proofs roughly 10x. That is the final piece for stateless clients.
We can write that one in 2027. Today, remember: Fusaka completes Pectra and paves the road to Verkle.
Two reminders about the Fusaka roadmap
People often ask whether Ethereum’s roadmap is too slow. My answer is the same every time. For a system holding $400B+ in assets and running 100+ production apps, slow is not a vice. Every upgrade ships with formal proofs and rollback paths. That is the pace financial infrastructure should keep.
Fusaka will not make you say “wow.” It will make your next L2 transfer feel boring and cheap, your next dApp approval feel safer thanks to scoped permissions, and your home node keep running without filling its disk.
Stack these together and Ethereum quietly becomes a better fit for the next generation of users. That is the entire point of Fusaka.