Gnosis Chain — Fusaka Hard Fork Announcement
The Fusaka hard fork at epoch 1714688, Tuesday, April 14, 2026 at 12:06:20 UTC.
Gnosis Chain will activate the Fusaka hard fork at epoch 1714688, Tuesday, April 14, 2026 at 12:06:20 UTC.
Fusaka was activated on Ethereum mainnet in December 2025. While we usually try to deliver hardfork before Ethereum, this one in particular was delayed following the Balancer hack. It is primarily a data availability and execution-layer efficiency upgrade. The headline feature is PeerDAS (EIP-7594), which replaces full blob downloads with probabilistic data availability sampling, significantly reducing per-node bandwidth requirements while enabling sustainable increases in blob throughput over time.
Additional changes harden gas accounting, cap transaction and block size, add a new cryptographic precompile, and introduce a mechanism for adjusting blob parameters without requiring a hard fork.
This change is not backwards compatible. Nodes that do not upgrade will fork off of the network that decided to upgrade.
The Fusaka activation on Gnosis Chain is later than Ethereum mainnet due to the emergency Balancer hard fork executed in late 2025. Gnosis Core Devs conducted Fusaka testing on the Chiado testnet in early 2026 before scheduling mainnet activation.
Required Client Versions
Both your execution client and consensus client must be updated before Epoch 1714688.
Running an updated execution client with an outdated consensus client (or vice versa) is not sufficient. Both layers must be upgraded.
Execution Layer Clients
Consensus Layer Clients
Nethermind and Lighthouse currently hold a majority client share on Gnosis Chain. If you are running either of them, you should strongly consider switching to a different client for safety of the network.
Timeline & Action Required
If you wish to go through with the upgrade, you need to complete your client upgrades before April 14, 2026 at 12:06:20 UTC.
Epoch: 1714688
Time (UTC): Tue Apr 14, 2026 — 12:06:20 UTC
Nodes running pre-fork client versions at this point will diverge from the canonical chain. You can upgrade at any time until the hard fork timestamp. If you don’t upgrade in time, you can still update your nodes after the hard fork to join the network again.
Key EIPs and what it changes
EIP-7594: Nodes verify blob data availability by sampling random fragments using erasure coding, rather than downloading full blobs. Reduces per-node bandwidth. Foundational step toward higher blob throughput on Gnosis Chain.
EIP-7892: Allows blob capacity parameters (target and max blobs per block) to be adjusted between hard forks via pre-scheduled coordination, without requiring a new named upgrade.
EIP-7825: Caps the gas a single transaction may consume at 16,777,216 gas (~16.78M). Prevents any individual transaction from monopolizing a full block as block gas limits rise.
EIP-7934: Introduces a hard 10 MiB ceiling on the RLP-encoded execution block. Closes a DoS surface where large but computationally inexpensive payloads could stress block propagation.
EIP-7918: Pins a proportional minimum price floor under blob fees. Prevents blob base fees from collapsing to near-zero during low-demand periods, preserving fee signal integrity.
EIP-7951: Adds native EVM support for the
secp256r1curve, enabling device-native signing via hardware security modules (HSMs) and FIDO2/WebAuthn. Relevant primarily for contract developers.EIP-7939: Adds a Count Leading Zeros (
CLZ) opcode to the EVM, improving efficiency of certain bitwise and cryptographic operations.EIP-7823: Caps MODEXP precompile inputs at 8192 bits (1024 bytes). Inputs exceeding this limit are rejected and gas is consumed. Removes an extreme-case DoS vector and simplifies gas estimation.
EIP-7883: Revises the gas cost schedule for MODEXP to more accurately reflect actual computational cost. Works in conjunction with EIP-7823.
EIP-7917: Makes the Beacon Chain deterministically aware of the next epoch's proposer schedule. Enables future preconfirmation mechanisms. No direct operational change required at fork time.
EIP-7935: An informational EIP coordinating client teams to raise the default block gas limit toward ~60M. The new default is shipped in client releases; no manual configuration required.
EIP-7642: Formalises that clients must support partial pre-Merge history expiry. No immediate state change at fork activation.
Checklist for Operators
Identify your current execution and consensus client versions.
Update your execution client to the minimum required version.
Update your consensus client to the minimum required version.
Restart both clients and confirm peer discovery and slot progress are normal.
Monitor attestation performance and finalization in the first few epochs after activation (~10–15 minutes). Allow the network to reach a stable consensus before drawing conclusions about chain health.
No changes to validator keys, withdrawal credentials, or deposit configurations are required for this upgrade.
Support
For technical questions or upgrade assistance:
Gnosis Discord: discord.gg/gnosis
For specification-level questions, the canonical reference is the gnosischain/specs repository. Gnosis Core Devs hold a public weekly call every Wednesday — details are pinned in the Discord.
This announcement will be updated if client versions or activation parameters change before fork activation. Always verify client release notes directly before upgrading.