Fusaka Upgrade Explained: Why People Still Search for It Fusaka upgrade explained in one line: Ethereum introduced PeerDAS so nodes could verify blob data by sampling assigned portions instea
Fusaka upgrade explained in one line: Ethereum introduced PeerDAS so nodes could verify blob data by sampling assigned portions instead of downloading every blob in full, helping the network support greater Layer 2 data capacity. The upgrade went live on December 3, 2025.
Some guides still treat Fusaka as upcoming. They are out of date. The change is already on mainnet, and its effects arrived in stages.
This guide covers what changed, what did not, and where the next upgrade stands. You will see how PeerDAS works, why blob capacity matters for L2 fees, and what the gas limit change means. Here is the Fusaka upgrade explained without engineering jargon.
Fusaka is a hard fork. That is a coordinated software change every node must adopt on the same block. The name joins two parts: Osaka, the execution layer upgrade named after a Devcon city, and Fulu, the consensus layer upgrade named after a star.
It activated at 21:49:11 UTC on December 3, 2025. Its headline feature is PeerDAS. Two small follow-up forks then raised blob limits, and client software moved to a 60 million default gas limit.
This Fusaka upgrade explained table covers the key facts at a glance.
Item
Detail
Activation
December 3, 2025, 21:49:11 UTC (epoch 411392)
Headline feature
PeerDAS (EIP-7594)
Blob target and maximum at activation
6 and 9 per block (unchanged)
Blob target and maximum after BPO2 (Jan 7, 2026)
14 and 21 per block
Client default gas limit
60 million (EIP-7935)
Action for ETH holders
None
Any Fusaka upgrade explained guide has to start with PeerDAS, and PeerDAS starts with a problem. Layer 2 networks, also called rollups, post their transaction data to Ethereum in "blobs." Before Fusaka, every full node had to store every blob. More blobs meant more disk space and more bandwidth for everyone.
PeerDAS fixes that with data availability sampling. Think of a group of friends sharing a huge library book. Each friend keeps a few chapters. The book also carries extra copies of key pages, so a lost chapter can be restored from what the others hold.
The Fusaka upgrade explained at the data level is about columns. Blob data is cut into pieces called columns. Those columns are spread across 128 subnets, and each node follows only some of them.
A regular full node subscribes to four of the 128 column subnets. Because PeerDAS uses extended data with redundancy, this corresponds to custody of roughly one-eighth of the original blob data. The node can check data availability without downloading every column.
The Fusaka upgrade explained through redundancy is the key idea here. Erasure coding adds redundant data to each blob. This means the original data can be reconstructed when at least 50% of the extended data is available. Nodes do not all need to store every piece: they sample assigned columns, while the network's distribution and recovery mechanisms help ensure that missing data can be detected and restored.
Validators are the nodes that stake ETH and confirm blocks. Ethereum's published estimates vary by node type and the validator balance connected to the node. These are indicative requirements, not universal hardware specifications. The Fusaka upgrade explained for validators comes down to this table.
Node type
What it subscribes to
Illustrative data requirement
Regular full node
4 of 128 subnets (roughly 1/8 of original blob data)
Blob disk use and download down roughly 80%
Solo staker
At least 8 subnets, more as balance grows
Disk and download down roughly 50%
Larger validator (around 800 ETH)
About 25 columns
Download up around 30%
Supernode (4,096 ETH or more)
All columns
Stores everything, heavy bandwidth
The Fusaka upgrade explained for block builders has one catch. They upload more data, so they need about two to three times more upload bandwidth at launch. At the final blob level, that rises to around 100 Mbps.
So PeerDAS shifts work around. Most nodes carry less. A few carry more.
This is the part users may actually feel, so the Fusaka upgrade explained in practice starts here. Blob space is what rollups buy when they post data to Ethereum. More space can mean lower costs for them, and lower costs can reach users as cheaper L2 transactions.
Fusaka activated PeerDAS on December 3, 2025, but it did not immediately raise the blob target or maximum. Those increases came through two later Blob Parameter Only forks: BPO1 on December 9, 2025, and BPO2 on January 7, 2026.
Stage
Date
Target blobs per block
Maximum blobs per block
Dencun
March 2024
3
6
Pectra
May 2025
6
9
Fusaka
Dec 3, 2025
6
9
BPO1
Dec 9, 2025
10
15
BPO2
Jan 7, 2026
14
21
A Blob Parameter Only (BPO) fork changes blob settings and nothing else. Fusaka upgrade explained by analogy: a dimmer switch instead of rebuilding the house. Developers can turn blob capacity up in small steps without waiting for a full upgrade.
Fusaka also introduced EIP-7918, which changes blob-fee pricing. It links the blob base fee more closely to the execution-layer costs associated with processing blobs. The aim is to prevent blob fees from becoming unrealistically low relative to those costs. This does not create a fixed fee or guarantee that blob prices will remain high.
Will extra space always mean cheaper L2s? Not automatically. Fees follow demand. If rollup traffic grows as fast as capacity, prices may not fall much. This article does not quote fee averages because they change daily. Check live public dashboards for current numbers.
Did Fusaka make Ethereum faster? Gas is the unit that measures computing work on Ethereum, so start there. The gas limit is the cap on work in one block. Think of seats on a bus. A higher limit means more passengers per trip.
The limit sat at 30 million from the Merge in 2022 until early 2025. It then moved to 36 million and 45 million. EIP-7935 updated execution-layer client defaults to a 60 million gas limit for Fusaka. Validators still signal the network's live gas limit, so the default setting and the actual network limit are not the same thing. The network had reached approximately 60 million shortly before the Fusaka activation.
Raising capacity needs guard rails. Here is the Fusaka upgrade explained through three separate ones.
Transaction gas cap (EIP-7825): A single transaction cannot use more than 16,777,216 gas (2^24). This limits how much execution work one transaction can demand. Very large contract deployments may need splitting.
Block-size limit (EIP-7934): Fusaka introduced a maximum encoded execution block size of approximately 10 MiB. This places a separate limit on block data and helps manage network propagation requirements.
ModExp changes (EIP-7883 and EIP-7823): Fusaka increased the gas cost of certain ModExp operations and introduced input limits. These changes better align the cost of resource-intensive cryptographic calculations with the work they require.
The Fusaka upgrade explained on gas is simple: the 60 million figure is a ceiling, not a speed promise. Blocks only fill up when people use them.
PeerDAS and blob capacity got most of the attention, but a complete Fusaka upgrade explained guide must cover the execution-layer improvements too.
EIP-7951 added a secp256r1 precompile, allowing smart contracts to verify signatures using a curve supported by common hardware security systems. This can make it easier for wallets and applications to use familiar authentication tools, including passkey-style experiences.
Fusaka also introduced the CLZ opcode through EIP-7939, which lets contracts count leading zero bits more efficiently. These changes do not automatically make every wallet or application use passkeys, but they give developers additional tools.
Many readers search "will Fusaka lower gas fees" and expect a yes. The honest Fusaka upgrade explained answer is less exciting. The Ethereum Foundation's answer is no, at least not directly. The focus is blob space for layer 2s. Layer 1 fees may feel small side effects at most.
Here is what stayed the same.
Your ETH:Nothing to convert, upgrade or claim. Anyone asking you to "upgrade" your ETH is running a scam.
Layer 1 gas prices: No direct cut. The fee market for normal transactions was not redesigned.
Block building rules: Enshrined proposer-builder separation did not ship. That belongs to Glamsterdam.
Existing contracts: Their behavior stays the same. The exceptions are contracts that lean on ModExp or push past the transaction cap.
That is why the Ethereum Fusaka upgrade is best labelled a capacity upgrade, not a fee-market overhaul.
So, when is the Fusaka upgrade? It already happened. Here is the Fusaka upgrade explained as a timeline.
Date
Milestone
Oct 1, 2025
Holesky testnet
Oct 14, 2025
Sepolia testnet
Oct 28, 2025
Hoodi testnet (final rehearsal)
Nov 6, 2025
Mainnet date and client releases announced
Dec 3, 2025
Mainnet activation
Dec 9, 2025
BPO1
Jan 7, 2026
BPO2
Who needed to act? ETH holders did not. Stakers and node operators had to update both the beacon node and the validator client to a Fusaka-ready release. Anyone who skipped the update would have been cut off from upgraded peers.
Nothing remains to prepare for the Ethereum Fusaka upgrade today. The useful habit is keeping clients current before the next fork.
Anyone who read a Fusaka upgrade explained guide may now look for the Ethereum December upgrade. That could mean Glamsterdam. As of November 4, 2026, it has no mainnet date.
Glamsterdam combines Amsterdam, the execution layer part, with Gloas, the consensus layer part. Its headliners are enshrined proposer-builder separation and block-level access lists. Both change how blocks are built and checked.
Here is where testing stands after the Fusaka upgrade explained above, per the Ethereum Foundation.
Glamsterdam activated on the Sepolia testnet on October 6, 2026.
Hoodi was scheduled for October 26, with a planned gas-limit increase to 200 million.
On October 22, the Ethereum Foundation postponed the Hoodi activation and removed the scheduled gas-limit increase. No replacement date has been announced.
Glamsterdam's Ethereum mainnet activation remains undecided.
The 200 million gas-limit figure was a Hoodi testnet configuration, not a mainnet commitment. It was also removed from the postponed schedule.
Work on the following upgrade has started too. In a September 7, 2026 post, the Ethereum Foundation's Protocol team said it had entered the Hegotá scoping season, with 62 EIPs proposed for inclusion.
The Fusaka upgrade explained in hindsight shows a pattern: timelines are targets. The Hoodi delay shows how a testnet date can move after developers spot a risk. Fusaka's value will keep showing as blob demand grows, and Glamsterdam will test whether Ethereum can scale the base layer too.
Fusaka went live on December 3, 2025, and the Fusaka upgrade explained here comes down to three points. It added PeerDAS, raised blob limits in two later steps, set a 60 million client default gas limit, and added safety rails. That is the Fusaka upgrade explained in a paragraph.
Put simply, the Fusaka upgrade explained for non-engineers is a story about capacity.
What stands out is the design. Nodes sample assigned data instead of downloading everything. What remains uncertain is how far L2 fees fall, since demand decides that. Next, watch the Glamsterdam mainnet announcement on the Ethereum Foundation blog.
Check the sources before relying on any date or figure in this Fusaka upgrade explained guide.
Disclaimer: This article is for information only and is not financial, investment or legal advice. Crypto assets are volatile and risky. Do your own research before making any decision.
