April 2026: Devnet Planned Restart and Block History Clarification

Summary

Anza planned and executed a Devnet cluster halt on April 14, 2026. The purpose of the halt was to deactivate several abandoned features that were live on Devnet but not Mainnet-Beta. By disabling the features on Devnet, Devnet and Mainnet-Beta are brought closer to parity. The two clusters being as similar as possible is beneficial for developers who look to test on Devnet prior to launching on Mainnet-Beta.

As a result of the feature deactivations and cluster halt, the Devnet block history available for read was incorrect for two blocks. The block history has since been corrected, but users who read the blocks prior to the correction may have observed incorrect or missing data.

There is no potential impact to Mainnet-Beta as features are not deactivated on Mainnet-Beta like they may be on Testnet and Devnet.

Feature Deactivations

Any given feature is typically activated sequentially on Testnet, Devent and finally Mainnet-Beta. The goal of this sequence is to find implementation issues and to allow developers to test the new feature out before it hits Mainnet-Beta.

The following three features were all previously activated on Devnet to enable testing but have since been abandoned:

• Fail libsecp256k1_verify if count appears wrong

  • Feature key: 8aXvSuopd1PUj7UhehfXJRg6619RHp8ZvwTyyJHdUYsj

  • Previously active on Devnet since Epoch 297 (April 2022)

• Enable blake3 syscall

  • Feature key: HTW2pSyErTj4BV6KBM9NZ9VBUJVxt7sacNWcf76wtzb3

  • Previously active on Devnet since Epoch 368 (September 2022)

• Increase tx account lock limit

  • Feature key: 9LZdXeKGeBV6hRLdxS1rHbHoEUsKqesCC2ZAPTPKJAbK

  • Previously active on Devnet since Epoch 386 (October 2022)

A program deployed on Devnet could potentially experience a change of behavior due to these feature deactivations. However, these features would never have been activated on Mainnet-Beta in their current state. Thus, a potential Devnet change of behavior is viewed as a positive in order to more loudly indicate that some functionality is being relied upon that is not available on Mainnet-Beta.

Block History Correction

Preliminaries

When a cluster stops finalizing blocks (planned or not), restarting the cluster involves several steps:

• Agree on the latest optimistically confirmed slot; this will be the restart slot

• Prepare a restart snapshot with a hard fork at the restart slot; the hard fork signals that a node is aware of the cluster restart

• Restart validators in a special mode to synchronize restart; the current threshold is to wait for at least 80% of stake before resuming normal chain activity

The Bug

In order to deactivate features, the step to create a restart snapshot from above is adjusted slightly to remove feature account(s) from the snapshot. These changes take effect in an additional block in order to avoid ambiguity about whether feature deactivation occurred before or after the transactions in the restart slot. For this Devnet restart specifically, the latest optimistically confirmed slot was 455406515 and the slot that deactivated the features was 455406516.

There were two issues with the Devnet block history, slots 455406516 and 455406517.

Slot 455406516

This block was created in a repeatable manner for the restart snapshot, but the block was not persisted to the local blockstore. Since the block was not persisted to the local blockstore, it was unavailable to read for RPC consumers.

Slot 455406517

This block was the immediate child block of 455406516. Block 455406517 was both stored in the blockstore and finalized so it was available to read from RPC immediately. However, the getBlock RPC method includes the blockhash of the parent block in the previousBlockhash field. As described above, 455406516 was not properly persisted to the blockstore. So, the data for block 455406517 had an incorrect value populated in the previousBlockhash field.

The Fix

The long term block history (Google Bigtable) was cleaned up to insert the missing block 455406516 and to update the previousBlockhash field in block 455406517 to create continuity for any consumers reading Devnet history.

Additionally, two code changes are in progress:

• To address the missing block issue (slot 455406516 in this case), tooling will be adjusted to persist any additional blocks created by hard fork snapshot generation

• To address the incorrect blockhash issue (slot 455406517 in this case), stricter checks are being added to the getBlock method implementation