Fusaka Hard Fork on LUKSO Testnet

Ethereum activated Fusaka on December 3, 2025. LUKSO is now preparing its own Testnet rollout of the same upstream fork family. For operators, this is a client and network-configuration upgrade. It is not a token migration or asset event. (Ethereum Foundation Blog)

What Fusaka is

Fusaka is Ethereum’s Fulu plus Osaka upgrade. It follows Pectra and bundles changes across the consensus layer and execution layer. The parts operators should care about are PeerDAS, Blob Parameter Only forks, eth_config, deterministic proposer lookahead, the per-transaction gas cap, the execution block-size limit, and the default gas-limit move to 60M. EOF is not part of the final Fusaka scope and should not be mentioned as if it shipped in this fork. (Ethereum Improvement Proposals)

A note on gas limits

Fusaka does not mean LUKSO Testnet’s live block gas limit changes immediately at activation. The gas limit is not being changed in the network’s genesis.json. Instead, the live block gas limit is a validator-coordinated execution-layer setting that moves gradually as proposers signal their target values in their client configuration. In practice, this means that any subsequent gas-limit increase depends on validator coordination across the network, not on the fork instantly enabling it.

Why it matters

PeerDAS changes how blob data is handled. Instead of every full node storing all blob data, nodes sample and custody only part of it. Ethereum’s own Fusaka page says regular full nodes hold 1/8 of the blob data, which creates a path to about 8x blob scaling over time while keeping node requirements in a range the network can live with. Ethereum also kept blob targets unchanged at activation and then used BPO forks to raise them later. (ethereum.org)

For validators, the main takeaway is simple. Fusaka changes the resource profile more than the basic operating model. Disk use and download bandwidth can drop at activation, but upload bandwidth becomes more relevant for nodes that build locally as blob counts rise. (ethereum.org)

How this maps to LUKSO

LUKSO runs an unmodified Ethereum protocol stack, so the upstream Fusaka changes are directly relevant. LUKSO’s public Testnet config already reserves the consensus-side Fulu slot through 0x42010007 and an unset 242550, which is the public sign that the chain config has already left room for a future Fusaka-era rollout. The article should explain this carefully: the public name is Fusaka, while the consensus-side config naming is Fulu. (LUKSO Tech Documentation)

What changes for validators?

Validators should expect the same shape of work they saw in prior LUKSO fork cycles. Update the execution client. Update the consensus client and validator client. Update the chain configuration files. Restart the node. Verify peers, sync state, and finality before the activation window. Ethereum required both execution and consensus updates for Fusaka, and prior LUKSO Dencun and Pectra notices used the same model. (Ethereum Foundation Blog)

eth_config should be part of the readiness checklist if your client exposes it. EIP-7910 was added so node operators and validator teams can verify current and next-fork configuration before activation. Deterministic proposer lookahead belongs in the “tooling compatibility” bucket rather than the “manual operator action” bucket, but it is still part of the fork. (Ethereum Improvement Proposals)

What changes in config?

On the consensus side, expect the released config.yaml to set the final FULU_FORK_EPOCH to 242550 for Testnet and confirm the matching fork version. On the execution side, expect the released genesis.json to define the Fusaka-era activation time and any related blobSchedule changes that LUKSO chooses to adopt. If LUKSO also pre-announces any BPO path, those values should come from the published config diff, not from guesswork. (Ethereum Improvement Proposals)

For Teku or Nethermind based setups, prior LUKSO notices also called out client-specific config locations in addition to the shared folder. That pattern is worth preserving here once the final PR is public. (LUKSO Validators)

What should operators do now?

If you are on LUKSO Testnet, prepare your node before Wednesday, 15th April 2026 16:20:00 GMT. Use the final published version matrix and config PR, not early assumptions. Prior LUKSO notices advised operators to do this about a week ahead of the fork, which is still the right tone here. (LUKSO Validators)

If you use the LUKSO CLI, the public workflow is already familiar: the CLI supports execution, consensus, and validator clients, and stores per-network genesis.json and config.yaml files, and exposes lukso update and lukso update configs for the standard fork-prep flow. (GitHub)

lukso stop lukso update lukso update configs lukso start --testnet # add your usual validator flags if applicable

If you use Docker or a custom setup, pull the published minimum client releases, replace the chain configuration files with the ones from Network Config PR, restart, and verify that the node is on the canonical Testnet chain before the activation window. If Dappnode packages are available for this fork, add them as a separate subsection with exact minimum package versions. (LUKSO Validators)

Final version matrix

LUKSO Testnet Fusaka activation Date and time (UTC): Wednesday, 15th April 2026 16:20:00 GMT Activation epoch: 242550 Minimum supported LUKSO CLI & Docker execution releases: - Geth: v1.17.2 - Erigon: v3.3.8 - Besu: v26.1.0 - Nethermind: v1.36.0 Minimum supported LUKSO CLI & Docker consensus releases: - Prysm: v7.1.2 - Lighthouse: v8.1.1 - Teku: v26.2.0 - Nimbus: v26.3.0 Network configuration - Shared config PR: https://github.com/lukso-network/network-configs/pull/153 - config/testnet/shared/config.yaml - config/testnet/shared/genesis.json - https://github.com/lukso-network/network-configs/tree/main/testnet/nethermind - https://github.com/lukso-network/network-configs/tree/main/testnet/nimbus2 - https://github.com/lukso-network/network-configs/tree/main/testnet/teku BPO policy - [STATE WHETHER LUKSO WILL MIRROR ETHEREUM BPO1/BPO2 OR NOT] THE SAME ETHEREUM 1:1 which is: { "name": "bpo1", "timestamp": "0x967A7600", "target": 10, "max": 15, "baseFeeUpdateFraction": "0x7f5a51" }, { "name": "bpo2", "timestamp": "0x967A7600", "target": 14, "max": 21, "baseFeeUpdateFraction": "0xb24b3f" }

“Minimum supported” refers to what we tested in CLI and Docker for LUKSO configurations. Official minimal versions are lower for the Ethereum Mainnet, but we are currently sticking to LUKSO.

Do not

Do not interpret this as an LYX conversion to LYXt, migration, swap, bridge step, or wallet “upgrade” implied by this fork. This is a node software and configuration update for operators. Any message asking you to move assets because of Fusaka should be regarded as malicious. Ethereum issued the same warning for Fusaka on Mainnet. (ethereum.org)

This is a testnet-only fork, and it only impacts testnet network components and dApps.


Follow LUKSO Validators Substack:
https://luksovalidators.substack.com/publish/post/192730519