Ethereum Fusaka Upgrade Explained: What Changed, What It Did, and What Comes Next

Fusaka is live. Ethereum’s biggest data-scaling upgrade since Dencun activated on mainnet on December 3, 2025, and by early January 2026 the network had already tripled its blob capacity through two follow-up mini-forks. If you searched for a “Fusaka launch date,” that moment has passed — so this guide covers what the upgrade actually delivered, the numbers behind it, and how it changes what you build on.

The short version: Fusaka introduced PeerDAS, a smarter way for nodes to check that Layer 2 data is available without downloading all of it, plus a new mechanism to raise capacity in small, safe steps. The result is cheaper rollup transactions and a base layer prepared for far higher throughput. Here’s how each piece fits together, starting from the ground up.

What Is the Ethereum Fusaka Upgrade?

Fusaka is a hard fork — a coordinated, backward-incompatible change to Ethereum’s protocol that every node must adopt to stay on the canonical chain. It shipped as Ethereum’s second major upgrade of 2025, following Pectra in May, and continues the network’s long scaling arc from the Merge (2022) through Dencun (2024).

The name follows Ethereum’s convention of pairing two upgrades that ship together. “Fulu” refers to the consensus-layer changes, named after a star; “Osaka” covers the execution-layer changes, named after the city that hosted a recent Devcon. Combine them and you get — one upgrade, two layers moving in tandem.

What makes Fusaka distinct from user-facing upgrades is its focus. It re-engineers how the network handles the data that Layer 2 rollups post to Ethereum — the plumbing beneath the fees you actually pay. That backend focus is exactly why its impact took a few weeks to show up on-chain rather than landing all at once.

Hard fork: a protocol change that isn’t backward-compatible, requiring all node operators to update their software. Nodes running old versions get disconnected from the network at the fork block. See the Ethereum Foundation’s Fusaka overview for the full technical scope.

Why Ethereum Needed Fusaka: The Blob Bottleneck

To see why it mattered, you have to go back to Dencun in March 2024. That upgrade introduced blobs — temporary data containers where rollups like Arbitrum, Optimism, and Base post their transaction data cheaply, then have it discarded after roughly 18 days. Blobs cut Layer 2 fees dramatically, in many cases by 90% or more.

The problem was success. As rollup activity grew through 2024 and 2025, the ecosystem kept bumping against Ethereum’s blob ceiling. Before Fusaka, the network handled a target of 6 blobs per block with a maximum of 9 — and during peak usage, L2s were saturating that space, pushing fees back up. The cheap data lane was filling faster than it could grow.

The obvious fix — just raise the blob limit — carried a hidden cost. Under the old design, every full node had to download every blob to confirm the data was available. Doubling or tripling blob capacity would have doubled or tripled the bandwidth and storage burden on ordinary nodes, quietly pricing out home stakers and pushing the network toward centralization. Ethereum needed a way to scale data without making nodes heavier. That’s the puzzle PeerDAS solves.

How Fusaka Works: The Core Changes

Fusaka bundled roughly 12 Ethereum Improvement Proposals (EIPs). Most are quiet efficiency and safety tweaks, but three changes carry the weight of the upgrade. Here’s each one, from the headliner down.

PeerDAS (EIP-7594): Sampling Instead of Downloading

PeerDAS — Peer Data Availability Sampling — is Fusaka’s flagship. Instead of forcing every node to store every blob, it splits blob data into columns and distributes them across the network, so each full node custodies only about one-eighth of the total data.

The clever part is the guarantee. Any portion of the data can be reconstructed from any existing 50% of the whole, which drives the probability of missing or fraudulent data down to a cryptographically negligible level. Nodes verify availability by sampling small slices from their peers rather than downloading everything — which is why the upgrade’s mascot is a zebra, its stripes echoing PeerDAS’s column-based structure.

The bandwidth savings are substantial. For a home validator, PeerDAS cuts the blob data they need to download by roughly 85% — one CoinGecko analysis put it at a drop from around 750 MB of blob data per day to about 112 MB. That reduction is what makes scaling blob capacity safe: you can add far more data lanes without asking solo stakers to move into a data center.

Data availability sampling: a method of confirming that data exists and is retrievable by checking small random samples rather than downloading the full set. It underpins Ethereum’s long-term path toward full Danksharding. Details in EIP-7594.

Blob Parameter Only Forks (EIP-7892): A Dial, Not a Fork

The second key change is procedural but powerful. Historically, raising blob capacity meant waiting 12 to 18 months for the next full hard fork. EIP-7892 introduced Blob Parameter Only (BPO) forks — lightweight, config-only upgrades that adjust the blob target and maximum without touching anything else in the protocol.

Think of it as a dial rather than a switch. Alex Stokes of the Ethereum Foundation described the design on the EthStaker launch livestream: developers could have turned capacity up 8x instantly, but chose not to. As he put it on the stream, sampling is a very new technique and cranking the dial to maximum on day one would not be the wisest decision. BPO forks let the network step capacity up in measured increments, watching telemetry between each move.

The BPO model came directly out of the Layer 2 world — OP Labs engineers proposed it, and it shipped as EIP-7892. That origin matters: it’s a scaling mechanism designed by the teams whose rollups depend on the extra capacity.

The 60M Gas Limit and Safety Caps (EIP-7935 and friends)

Fusaka also raised the default block gas limit target to 60 million, up from 36 million — a coordinated client setting rather than a hard rule, letting the base layer fit roughly 20–30% more computation per block. Paired with that increase are several safety EIPs: a per-transaction gas cap of about 16.7 million gas (2²⁴) so no single transaction can hog a block, and a strict block-size limit to prevent oversized blocks from slowing propagation. Capacity up, abuse vectors down.

The Numbers: What Fusaka Delivered by January 2026

This is where the refresh matters most — the upgrade didn’t finish on day one. Fusaka rolled out as three sequential events over 35 days, each dependent on the last landing cleanly.

Event	Date	Blob target	Blob max
Fusaka mainnet	Dec 3, 2025, 21:49 UTC	6	9
BPO1	Dec 9, 2025	10	15
BPO2	Jan 7, 2026	14	21

Both BPO forks activated on schedule. BPO1 lifted the target from 6 to 10 blobs; BPO2 pushed it to 14, with the maximum reaching 21. Together, the two forks roughly tripled blob capacity within a month — the most meaningful expansion of Ethereum’s data availability since blobs were introduced.

The transitions were smooth. Network telemetry showed the participation rate holding near 99% through BPO1, with only a brief dip around the activation epoch, and finality never interrupted. Blob demand has since climbed steadily without approaching the new ceiling, which is exactly the “spare capacity” outcome developers were aiming for.

Reliability data does carry one caveat worth watching. Independent telemetry suggests the baseline block-miss rate sits near 0.5%, but climbs as blocks fill with blobs — reaching roughly 1.79% (about 3.5x baseline) at the 21-blob ceiling. That miss-rate curve is precisely why core developers are holding further increases (BPO3 and BPO4) pending review rather than pushing the dial higher on a fixed timetable.

For the L2 economics: a typical Layer 2 transaction that cost around $0.50 in late 2025 dropped to roughly $0.20–$0.30 in the weeks after Fusaka, with further room as capacity gets used. The combined L2 ecosystem currently processes on the order of 5,600 TPS, with developers projecting 24,000+ TPS as the BPO schedule progresses.

What Fusaka Means for Developers and Node Operators

Strip away the acronyms and the practical picture is straightforward. If you build on a rollup, your users’ data-posting costs fell and have more headroom to keep falling. If you run infrastructure, the resource math changed in your favor.

For node operators and home stakers, PeerDAS is the headline benefit. Because each node now custodies a fraction of blob data instead of all of it, disk usage and download bandwidth for blobs can drop by 50% or more compared to pre-Fusaka — even as total network capacity climbs. A solo staker running 32 ETH stays comfortably within home-hardware bandwidth ranges at BPO2 levels. Keeping solo staking viable while scaling is the whole point; it’s how Ethereum avoids “scale by centralization.”

For application developers, Fusaka also shipped smaller quality-of-life additions: native support for the secp256r1 signature curve (EIP-7951), which opens the door to signing transactions with smartphone biometrics like Face ID, and a new CLZ opcode for cheaper on-chain math. These won’t headline a marketing page, but they matter if you’re building wallets or gas-sensitive contracts.

One operational note if you run your own node: Fusaka required updates to both the execution-layer and consensus-layer clients, and validators needed to update their beacon node and validator client together. Anyone relying on managed infrastructure — for example, a dedicated Ethereum node — inherited Fusaka support without touching client software, which is one reason teams offload this. If you’re newer to how these two layers split responsibilities, our guide to running and connecting to blockchain nodes walks through the basics.

Where Fusaka Fits in Ethereum’s Roadmap

Fusaka isn’t an endpoint — it’s the data-availability chapter of a longer story. Placing it in sequence makes its role clear:

• The Merge (2022): moved Ethereum from proof-of-work to proof-of-stake.
• Shapella (2023): enabled validators to withdraw staked ETH.
• Dencun (2024): introduced blobs and the modern L2 fee era.
• Pectra (May 2025): refined validator mechanics and execution.
• Fusaka (Dec 2025): scaled data availability via PeerDAS and BPO forks.

PeerDAS is also the technical foundation for full Danksharding, Ethereum’s long-term data-scaling design, with core developers targeting far higher blob counts over time — plans point toward 48 blobs per block by mid-2026 and 128 under full Danksharding. Each BPO fork doubles as a live stress test validating whether the network can safely handle the next jump.

Enterprise Ethereum Alliance’s Paul Brody captured Fusaka’s forward-looking nature on the launch livestream, noting that upgrades like PeerDAS aren’t visible the next day but lay the groundwork for the road toward a trillion transactions a day. It’s infrastructure you feel later, not immediately.

What Comes After Fusaka: Glamsterdam

If you’re reading this in 2026 and wondering what’s next, the answer is Glamsterdam — Ethereum’s next major hard fork and the upgrade now dominating core-developer attention.

Where Fusaka scaled data, Glamsterdam targets execution efficiency and the validator economy. Its two headline proposals are EIP-7732 (Enshrined Proposer-Builder Separation, or ePBS), which moves block-building rules that currently rely on external relays like MEV-Boost directly into the protocol, and EIP-7928 (Block-Level Access Lists, or BALs), which enables parallel transaction execution and supports raising the gas limit from 60M toward 200M. A gas-repricing cluster rounds out the package.

On timing, be careful with any “date” you see — the target has moved. Glamsterdam was originally aimed at June 2026, but after the Soldøgn interop devnet concluded around May 2, 2026, the realistic window shifted to the second half of the year, most often cited as Q3 2026 (around end of August). No firm mainnet block has been locked. Ethereum Foundation engineer Parithosh Jayanthi has described the current phase as the last step before hardening and shipping to testnets, and called Glamsterdam “probably the largest fork we’ve had since the Merge.” The clearest leading indicators to watch are the Sepolia and Hoodi public testnet activations.

If you operate validator infrastructure, Glamsterdam carries a heavier lift than Fusaka: ePBS introduces a new Payload Timeliness Committee attestation duty, so you’ll need both clients updated and your setup audited well ahead of activation.

Conclusion

Fusaka did the unglamorous, essential work of scaling Ethereum’s data layer without compromising the decentralization that makes it worth using. PeerDAS let nodes sample data instead of downloading all of it, the BPO mechanism turned capacity increases into a safe, tunable dial, and by January 2026 the network had tripled blob capacity while keeping home stakers in the game.

The practical takeaways are few. Rollup data is cheaper and has more room to fall. Running a node got lighter, not heavier. And the next chapter — Glamsterdam — is already in final development, aiming at execution efficiency rather than data. Whether you’re deploying contracts, running a validator, or just tracking where Ethereum is headed, Fusaka is the upgrade that quietly reset the ceiling. For teams that want a consistent, upgrade-ready view of the chain without managing client releases themselves, reliable Ethereum node infrastructure from NOWNodes keeps that connection stable through every fork.

FAQ

What is the Ethereum Fusaka upgrade?

It is an Ethereum hard fork that activated on mainnet on December 3, 2025. Its headline feature is PeerDAS, which lets nodes verify Layer 2 blob data by sampling small slices instead of downloading everything, alongside a Blob Parameter Only (BPO) mechanism that raises blob capacity in safe steps. It scaled data availability for rollups without increasing node hardware requirements.

When did Fusaka go live?

It activated on December 3, 2025, at 21:49 UTC (epoch 411,392). Two follow-up Blob Parameter Only forks completed the rollout: BPO1 on December 9, 2025, and BPO2 on January 7, 2026. Together they tripled blob capacity within roughly a month.

What does Fusaka do for gas fees?

It mainly reduces the data-posting cost for Layer 2 rollups, which is the largest component of many L2 fees. A typical L2 transaction that cost around $0.50 in late 2025 fell to roughly $0.20–$0.30 after Fusaka. It does not directly slash Ethereum mainnet (L1) gas fees — that’s more the focus of the next upgrade, Glamsterdam.

Do I need to do anything with my ETH because of Fusaka?

No. Update doesn’t change your balance, wallet address, or how you hold ETH. If you use an exchange or wallet, there’s nothing to do. Anyone telling you to “upgrade” your ETH is attempting a scam. Only node operators and validators needed to update their client software.

How much does PeerDAS reduce node bandwidth?

PeerDAS cuts the blob data a validator must download by roughly 85%, because each node custodies only about one-eighth of blob data and samples the rest from peers. This is what allowed Ethereum to raise blob capacity without pushing home stakers off the network.

What is the difference between Fusaka and Glamsterdam?

Fusaka (December 2025) scaled Ethereum’s data availability through PeerDAS and BPO forks. Glamsterdam, Ethereum’s next major hard fork targeted for the second half of 2026, focuses instead on execution efficiency — introducing Enshrined Proposer-Builder Separation (ePBS) and Block-Level Access Lists (BALs) for parallel processing. Different problems, sequential upgrades.

How many blobs can Ethereum handle after Fusaka?

After BPO2 (January 7, 2026), Ethereum targets 14 blobs per block with a maximum of 21, up from a target of 6 and maximum of 9 before Fusaka. Core developers plan to continue raising this through future BPO forks, with a long-term goal of 128 blobs per block under full Danksharding.