Ethereum’s Fusaka network upgrade (also referred to as Fulu-Osaka) is a major protocol milestone focused on scaling, node sustainability, and better UX—especially for a rollup-centric Ethereum. The name reflects a combined upgrade: “Fulu” for the consensus layer and “Osaka” for the execution layer.
When did Fusaka activate?
The Fusaka upgrade activated on Ethereum mainnet at slot 13,164,544 (start of epoch 411,392) on December 3, 2025 at 21:49:11 UTC.
Fusaka also introduced Blob-Parameter-Only (BPO) forks—lightweight, config-only follow-ups designed to raise blob capacity in a controlled way after PeerDAS.
The Headliner: PeerDAS (EIP-7594) — Scaling Blob Data Without Centralizing Nodes
Fusaka’s biggest scaling lever is Peer Data Availability Sampling (PeerDAS), specified in EIP-7594. Instead of requiring every node to download and store all blob data, nodes can verify availability via sampling. This keeps hardware/bandwidth requirements more manageable while enabling higher blob throughput—directly benefiting L2s that post data to Ethereum.
In practical terms: higher blob capacity can translate into cheaper rollup data costs, which is one of the key inputs to lower L2 transaction fees, assuming demand doesn’t rise faster than capacity.
Blob Capacity Ramps After Fusaka: BPO1 and BPO2 (EIP-7892 + scheduled parameters)
Fusaka doesn’t stop at enabling PeerDAS. It sets the stage for parameter-only upgrades that increase blob throughput gradually:
- BPO1 (Dec 9, 2025 14:21:11 UTC): blob target 10, max 15
- BPO2 (Jan 7, 2026 01:01:11 UTC): blob target 14, max 21
This approach lets Ethereum adjust blob capacity with less operational overhead than a full hard fork.
More L1 Execution Capacity: Gas Limit Increase + Safety Caps
Fusaka also improves Layer 1 execution capacity and resilience:
EIP-7935 — Default gas limit raised (target 60 million)
Fusaka raises Ethereum’s default block gas limit to 60,000,000, increasing the baseline computation per block (more room for transactions and onchain activity).
EIP-7825 — Transaction gas limit cap (16,777,216)
Fusaka adds a protocol-level transaction gas limit cap of 16,777,216 gas to reduce denial-of-service risk where one transaction could otherwise consume an excessive share of a block.
Together, these changes push throughput upward while adding guardrails that help keep the chain stable under stress.
Better Wallet UX: Passkey-Friendly Cryptography (EIP-7951)
A highly practical change in Fusaka is EIP-7951, which introduces support for the secp256r1 curve—widely used by device security hardware and modern passkey systems. This enables more “mainstream” authentication patterns (hardware-backed signing and passkeys) that can reduce reliance on seed-phrase-only UX over time.
Network and Efficiency Cleanups: eth/69 and MODEXP Protections
Fusaka includes execution/network efficiency work intended to reduce unnecessary overhead and harden expensive operations:
- EIP-7642 (eth/69): removes legacy pre-merge fields and receipt bloom from the networking protocol, simplifying and reducing sync bandwidth requirements.
- EIP-7823 + EIP-7883: set bounds and adjust pricing for MODEXP (modular exponentiation) so computationally heavy operations are priced more accurately and can’t be abused cheaply.
Who Needs to Care (and What to Do)
Node operators / validators
Ethereum upgrades require node operators to update clients to stay on the canonical chain. For any future upgrade, always verify you’re running client versions that explicitly support the fork you’re targeting.
L2s and “blob transaction originators”
If you originate blob transactions (typical for rollups), update transaction-sending systems to generate the required proofs introduced alongside PeerDAS-related changes.
Wallets and app teams
Wallet teams should evaluate passkey/HSM/WebAuthn-compatible signing paths enabled by secp256r1 support and track ecosystem adoption as standards mature.
Bottom Line: Fusaka Makes Ethereum More Rollup-Ready (Without Pricing Out Nodes)
Fusaka is best understood as a coordinated upgrade that:
- expands Ethereum’s data availability runway for rollups (PeerDAS + blob ramps),
- increases L1 execution headroom (gas limit changes with safety caps), and
- improves security/UX primitives (passkey-friendly cryptography).
For users, the benefit is mostly indirect: a stronger path to more L2 throughput and, in many cases, lower L2 costs, while keeping Ethereum’s base layer robust.

