SIMD-0500: your next upgrade is forced, and some programs will be frozen

Once SIMD-0500 activates, Solana will refuse to deploy, upgrade or finalize any program built for sBPF versions 0, 1 or 2 [1][2]. Your next upgrade must ship sBPFv3 bytecode, so before it comes, check who holds your upgrade key and whether they can use it.

What changes

SIMD-0500 is short. After its feature is active, a validator "must fail to (re-)deploy or finalize programs with any SBPF version older than SBPFv3" [2]. For the upgradeable loader (loader-v3), that means three instructions now check the bytecode version:

Rejected calls fail with InvalidAccountData [2]. Programs already on chain "will continue to execute without restriction" [1]. Nothing stops running on activation day. What stops is your ability to change the program, or to give up the ability to change it, until it is rebuilt.

The SIMD counts how many programs this touches. Using Blueshift's program-sync tool, it lists 17,279 upgradeable loader-v3 programs on mainnet built for sBPFv0, plus 53 on v1 or v2 [2].

When

Solana's upgrades page lists sBPFv3 Programs under Agave 4.4, planned and expected in November 2026, with devnet activation "to be determined" [3][4]. Agave v4.4.0-rc.1 was published on 26 October 2026 [5]. No mainnet activation date has been announced. Anza's guide says to watch its announcements [1]. The 16 October changelog already warns that "upcoming changes will enforce sBPFv3-only deployments" [6].

Treat it as weeks, not months.

Why this is an admin-plane problem

An upgrade is the moment an upgrade authority is used. Every upgradeable program now has an upgrade it did not plan: the next one, which must also be a rebuild. Three things follow.

Your emergency fix depends on your toolchain. If a bug is found after activation, the hotfix must be an sBPFv3 build. A team that has not yet moved to platform-tools v1.56 or later and cargo-build-sbf v4.2.0 or later [1] is debugging a toolchain during an incident.

An authority on old bytecode is weaker than it looks. solana program show still prints an Authority, but if the team has lost the source, or cannot rebuild it, that key can no longer ship any change. The program is frozen in practice while appearing upgradeable.

You can no longer make an old program immutable as it stands. Finalizing is the same SetAuthority call, and it is rejected for pre-v3 bytecode [2]. xroot.dev wrote up this point in September [10]. A team that planned to renounce its upgrade key "one day" must now rebuild and upgrade first.

How to check, read-only

Both checks use public data and no keys.

# Who holds the upgrade key
solana program show "$PROGRAM_ID" --url mainnet-beta

# Which sBPF version is deployed: 0x3 is v3; 0x0, 0x1 or 0x2 need a rebuild
solana program dump "$PROGRAM_ID" program.so --url mainnet-beta
readelf -h program.so | grep Flags:

solana program show prints the program's owner, ProgramData address, Authority and last deployed slot [7]. The ELF flags check is the one Anza and the Solana docs give [1][3]. On macOS, use llvm-readelf from the Solana platform tools [3].

Authority is only an address. To see what is behind it, our open-source scanner, solana-authority-scan, reports the loader, whether the authority is nobody, a single key or a Squads v4 vault, and for a vault its threshold, members, time lock, config authority and approved proposals that can still be executed [9]:

cargo install --locked solana-authority-scan
export SOLANA_MAINNET_RPC_URL=https://api.mainnet-beta.solana.com
solana-authority-scan --cluster mainnet "$PROGRAM_ID"

It is read-only and holds no keys. It does not report the sBPF version, so run the readelf check alongside it. Public endpoints often refuse the call that builds its Squads index; it then falls back to recent transactions, or you can pass --multisig with the address you expect [9].

Before activation

1. Rebuild and test. Update the toolchain, build with cargo build-sbf --arch v3, and test with Mollusk, LiteSVM, Surfpool or Anchor before deploying [1]. Two traps from Anza's guide: do not pass --arch v3 to platform-tools older than v1.53, and replace extern "C" syscall declarations with define_syscall!, because they can leave an unresolved call that bricks the program [1]. Anchor now compiles to sBPFv3 by default [6].

2. Confirm the authority can act. Before you need it:

• Name every key or multisig that holds an upgrade authority, and confirm each holder can still sign.
• For a multisig, check the threshold, the members and the time lock. A Squads time lock defers execution of every approved transaction for the set period [11]. Budget it into your timeline.
• Rehearse the full path on devnet: write the buffer, transfer it to the authority, propose, approve, wait out the time lock, execute.
• Check the deployed hash against your build. A rebuild changes the hash, so publish a new verified build afterwards (solana-verify get-program-hash, then verify-from-repo) [8].

3. Decide on immutability now. Finalizing old bytecode before activation still works. But SIMD-0500's own motivation is to "eventually ... deprecate the execution of these SBPF versions" once their use drops to near zero [2]. No date or proposal for that exists. If you want the program immutable, the safer order is rebuild, upgrade, then finalize, each as a separate step. If you want to keep an authority, make sure it is a multisig with a time lock, not one laptop.

What happens to immutable programs

Programs that are already immutable cannot be changed either way, so SIMD-0500 asks nothing of them. They keep running: the SIMD says execution of old versions "will remain supported for now" [2]. The SIMD's table lists 873 finalized programs on sBPFv0 across loaders v1, v2 and v3 [2]. If you depend on one, note that "for now" is the SIMD's own wording, and nobody can rebuild that program to keep up.

The short version

• Old programs keep running. They just cannot be upgraded or finalized until rebuilt.
• The next upgrade is a rebuild. Rehearse it through your real authority before you need a hotfix.
• If you meant to renounce the key, rebuild first.

What we do: our admin-plane Snapshot maps who can change your programs, tokens and funds, and how fast. It is not an audit and does not review program code. See https://centrob.co/#solana.