What is the Fusaka upgrade?

Fusaka (Fulu + Osaka) is the Ethereum hardfork following Pectra. Its headline features are PeerDAS (EIP-7594), which introduces data availability sampling to scale blob throughput, and EOF (the EVM Object Format), which modernizes contract bytecode with versioning and cleaner validation rules.

What is PeerDAS and why does it matter?

PeerDAS is peer-to-peer data availability sampling. Instead of every node downloading every blob, nodes sample a small number of columns and gossip them. This lets Ethereum safely raise the blob target from 3 to a multiple of it without increasing bandwidth requirements on home stakers, unlocking cheaper L2 data posting.

How does Fusaka affect L2 fees?

By expanding blob capacity, Fusaka should drive sustained blob base fees back toward the floor, cutting L2 data-posting costs. Optimism, Base, Arbitrum, and Linea can pass those savings through to users as lower swap, bridge, and interaction fees — especially during demand spikes that currently saturate the blob market.

EOF (EVM Object Format) is a bundle of EIPs that introduces versioned, validated contract bytecode. It removes JUMPDEST analysis, adds explicit code sections, and enables future EVM improvements without breaking legacy contracts. For developers it means cleaner tooling; for the chain it means a safer path to EVM evolution.

When does Fusaka activate?

As of April 2026, Fusaka is in devnet testing with mainnet activation targeted for late 2026. The exact slot will be finalized after the final testnet forks on Holesky and Sepolia successors complete without incident.

Ethereum Fusaka & PeerDAS: The 2026 Upgrade Guide

Pectra gave wallets a new superpower. Fusaka does the same for data. Here's how PeerDAS, EOF, and the rest of the fork reshape Ethereum's scaling story in late 2026.

TL;DR

Fusaka is the next Ethereum hardfork after Pectra. Its two marquee features are PeerDAS (EIP-7594), which scales blob throughput via data availability sampling, and EOF, which modernizes EVM bytecode. The practical outcome: cheaper L2 fees, healthier rollup economics, and a foundation for full Danksharding.

1. Where Fusaka Sits on the Roadmap

Ethereum's post-Merge roadmap has settled into a steady rhythm: roughly one execution-plus-consensus hardfork per year. Dencun (2024) gave us blobs. Pectra (2025) gave us smart EOAs via EIP-7702 and raised the validator MaxEB. Fusaka — Fulu on the consensus layer, Osaka on execution — is the 2026 entry, and its center of gravity is data availability.

The reason is simple arithmetic. Blob demand grew faster than blob supply. Throughout 2025, blob base fees repeatedly spiked whenever a meme season or a major L2 bridge event drove simultaneous posting from Base, Arbitrum, Optimism, and Linea. The cap of six blobs per block (target three) became the new rollup bottleneck. Fusaka's job is to break that ceiling without asking home stakers to download more data.

2. PeerDAS in Plain English

PeerDAS (EIP-7594) is the first production deployment of data availability sampling on Ethereum. The core insight: if a blob is erasure-coded across many columns, a validator can verify that the blob was published by downloading only a small random subset of those columns. As long as enough validators each sample a different subset and can reconstruct the full data if needed, the network is safe even though no single node ever sees the whole thing.

That's a huge deal for Ethereum because it decouples per-node bandwidth from total blob throughput. In Dencun and Pectra, every node had to download every blob, which is why the blob target sits where it does. With PeerDAS, the network can raise the blob target meaningfully — early parameterization proposals target 48 blobs per block with a cap of 72 — while keeping the per-validator download budget essentially flat.

What PeerDAS is not

Not full Danksharding. PeerDAS is the staging area. Full Danksharding adds proposer-builder separation assumptions and further sampling efficiencies.
Not a change to rollup proofs. Optimistic and ZK rollups post the same blob data they already do; only the gossip and sampling layer changes.
Not a guarantee of cheaper fees forever. If L2 demand scales with supply, blob fees will reprice upward. PeerDAS raises the ceiling, it doesn't cap demand.

3. EOF: The EVM Gets a Version Number

The second headline feature, EOF (EVM Object Format), is unglamorous but long overdue. Today's EVM bytecode has no header, no version, no explicit code vs data separation. JUMPDEST analysis has to run on every contract call. Tooling has to guess which bytes are reachable code and which are inline metadata. EOF fixes all of that.

Under EOF, contracts are deployed with a container format: a magic prefix (0xEF00), a version, and a sequence of labeled sections — code, data, and function types. The validator runs once at deploy time. From then on, the EVM can skip JUMPDEST analysis, use cheaper function calls (CALLF/RETF), and — crucially — evolve safely, because legacy bytecode and EOF bytecode are distinguishable from byte zero.

Solidity and Vyper ship EOF targets out of the box in 2026. Most framework upgrades will be silent. The practical impact for builders: slightly cheaper deployments, cleaner ABI decoding in tools, and a clean slate for future EIPs that would have been too risky on legacy bytecode.

4. What Else Is In the Fork

EIP-7594 PeerDAS — data availability sampling on the consensus layer.
EOF bundle — EIP-3540, 3670, 4200, 4750, 5450, 7480 and friends.
Blob target bump — paired with PeerDAS, the target and cap rise together.
Precompile cleanups — metered pairing, MODEXP gas corrections, and BLS12-381 curve operations to accelerate ZK verification.
History expiry scaffolding — laying the groundwork for EIP-4444, so execution clients can eventually prune pre-Merge history.

5. What It Means for L2s and Rollups

For rollup teams, Fusaka is the most important upgrade since Dencun. Blob posting is the single largest cost line for every major L2. If Fusaka lands on schedule with a 48-blob target, median blob base fees should fall sharply outside peak windows, and the worst peak-fee events should become much rarer. Based rollups and shared sequencing experiments that depend on tight blob inclusion guarantees get a friendlier environment too.

The competitive picture shifts. Alt-DA solutions like Celestia, EigenDA, and Avail have thrived partly because Ethereum blobspace was scarce. PeerDAS narrows that gap. Expect L2s to reassess the Ethereum-DA vs alt-DA trade-off once real Fusaka throughput data is available on mainnet.

6. Builder Checklist Before Activation

Test your contracts against an EOF-enabled Solidity/Vyper release. Upgrade build pipelines early.
If you operate an L2, model your sequencer economics under a 48-blob target and plan a fee-reduction announcement.
If you run a validator, check your client release notes. PeerDAS adds a sampling column schedule that clients manage automatically.
If you build indexing or analytics, update your blob decoders — sampled column layouts differ from today's full-blob downloads.
Audit any contract that relies on JUMPDEST introspection or raw bytecode patching. EOF breaks those assumptions.
Watch the devnet cadence. Most Fusaka breakage is caught on devnets first — subscribe to AllCoreDevs and client team release notes.

7. Risks and Open Questions

No upgrade this ambitious ships without tail risk. The three to watch: PeerDAS gossip liveness under adversarial conditions (will the column subnets stay healthy if a large fraction of validators misbehave?), EOF tooling coverage (every debugger, profiler, and fuzzer needs to understand the new container), and the blob fee market dynamics after the target rises — historically, sudden capacity increases have created temporary oversupply before demand catches up, which affects ETH burn and L1 revenue projections.

None of these are showstoppers, but they're why Fusaka is taking longer than a minimal fork would. The client teams have explicitly optioned for more devnet cycles rather than rushing to mainnet.