"Revoke the upgrade authority" is the last line of every honest token launch checklist and the first thing an auditor looks for. It is the on-chain promise that the code holding your money will never change. It has always been one instruction: set the program's upgrade authority to none, and the program is frozen forever.
For a class of programs, that instruction will fail once SIMD-0500 activates; as of 17 September 2026 the gate exists in the validator but has not activated on mainnet. SIMD-0500 will stop old bytecode formats from being deployed, and as part of that rule the loader will refuse to freeze a program whose bytecode is one of those old formats. A creator who built with a toolchain from a couple of years ago, never touched the program since, and leaves the renounce until after the gate activates cannot do it — until they rebuild, upgrade, and only then renounce.
Here is the rule from the loader source, who it catches, the other loader rule that changed alongside it, and what an audit should now show.
The Rule
Solana programs are compiled to SBPF, and SBPF has versions: v0, v1, v2, and the current v3. The feature disable_sbpf_v0_v1_v2_deployment, once it activates, makes the upgradeable loader reject any new deployment or upgrade whose ELF is not v3. Old programs keep executing; they just cannot be redeployed as they are.
The part that surprises people is in the authority path. When that gate is active and a SetAuthority instruction asks to set the authority to none, the loader reads the program's bytecode version first. If it is below v3, the instruction fails with an invalid-account-data error. The reasoning is consistent: a program that could never be redeployed in its current form must not be frozen in that form either, because freezing it would strand it on a format the network is retiring.
The immutability instruction becomes conditional on the bytecode being current.
Who This Catches
Anyone with a deployed program built before the v3 toolchain who has not upgraded since. That describes a large share of the long tail: token launches from 2023 and 2024 with a custom program, NFT projects, small DeFi protocols, games. Many of them intended to renounce eventually and never got round to it.
It also catches the honest-but-late: a team that goes to freeze the program as a trust signal after the gate activates, and discovers the instruction fails.
The fix is not hard, but from then on it is not one instruction:
- Rebuild the program with a current toolchain, producing v3 bytecode.
- Upgrade the program with the new build. The upgrade spills the old program-data's excess lamports and the buffer's balance to your spill account and leaves the buffer as a 37-byte husk holding rent.
- Then set the authority to none.
Three transactions, in that order, at least one slot apart — the loader rejects a second mutation of the same program in the same slot.
The Other Loader Rule That Changed: Extends
Programs need more space over time, and ExtendProgram grows the program-data account. Two things about it are worth knowing now.
- It is permissionless. The loader passes no authority check on extend; anyone can grow anyone's program-data account, paying the rent for the extra bytes themselves. A checked variant existed and was removed. This is old behaviour, but it is newly relevant because of the second point.
- It has a minimum. Under SIMD-0431 an extend must add at least 10,240 bytes, unless the program is within 10 KiB of the 10 MiB size cap, in which case it must add exactly the remaining headroom. Incremental extends of a few hundred bytes — the habit of many deploy scripts that grow the account to fit each new build — now fail, and the fix is to extend in 10 KiB steps or size the account generously up front.
And extends still accept old bytecode. The source comment is explicit: the deployment gate is deliberately not applied to extend, so a legacy program can still be grown once it can no longer be redeployed or frozen.
What "Immutable" Should Mean in an Audit Now
An audit that reports "upgrade authority: none" is reporting a fact about programs that could reach that state. For programs that cannot, the report needs a second field: bytecode version. Once the gate activates, a v0, v1 or v2 program with a live authority is not "not yet renounced"; it is "cannot be renounced without a rebuild", and the difference is material to anyone deciding whether to trust it.
The token audit on this site reads the program-data account behind any program a token depends on. The version of the bytecode is in the first bytes of it, and the audit will say when a program is in the stranded state rather than implying the team simply has not pressed the button.
The Smaller Rules That Arrive With the Same Gate
Deploying will also de-register the old allocator symbol, sol_alloc_free_, so programs that depend on it load at runtime but cannot be deployed. The deploy verifier is stricter than the executor — it rejects broken ELFs that the runtime would tolerate — which means "it runs on mainnet" is not evidence that "it will redeploy".
Execution of old bytecode is a separate question with its own gates, and in the current build those gates are placeholders. Old programs keep running. The gate discussed here is about deployment and freezing, not execution.
Program Immutability: Questions People Actually Ask
Why does setting my Solana program’s upgrade authority to none fail?
Once SIMD-0500 activates — it had not activated on mainnet as of 17 September 2026 — the loader refuses to freeze a program whose bytecode is SBPF v0, v1 or v2. Rebuild with a current toolchain, upgrade, then set the authority to none.
Do old Solana programs stop running under SIMD-0500?
No. The gate blocks new deployments and upgrades of old bytecode, and freezing it. Execution is governed by separate gates that are placeholders in the current build.
Can anyone extend my Solana program’s size?
Yes. ExtendProgram carries no authority check; the caller pays the rent for the added bytes. Extends must now add at least 10,240 bytes unless the program is within 10 KiB of the 10 MiB cap.
How should an audit report a legacy Solana program?
With the bytecode version next to the authority. Once SIMD-0500 activates, a v0–v2 program with a live authority cannot be renounced without a rebuild, which is a different state from a team that has not renounced yet.
If You Hold a Program's Upgrade Authority
Check the bytecode version of every program you control. If it is below v3, you can still renounce it today, and you will not be able to once the gate activates, so plan the rebuild-upgrade-renounce sequence rather than discovering the failure in front of your community.
If you audit programs, report the version alongside the authority. "None" and "cannot be set to none" are different states, and the second one is about to become common.
And if you are extending a program, extend in 10 KiB steps. The one-byte top-up era is over.
— Authority Is Half the Answer —
Read the bytecode version next to it.
The token audit reads the program-data account behind the programs a mint depends on, straight from the chain — the authority, and the version that decides whether that authority can ever be given up.
A different kind of program change is happening at the same time: SPL Token is being replaced in place and ends up with no upgrade authority at all. And the lamports an upgrade spills back to you are part of the wider rent surplus sitting in old accounts.
Loader behaviour read from the Agave validator source at commit beee69b958: programs/bpf_loader/src/lib.rs and feature-set/src/lib.rs. On 17 September 2026 the deployment gate had not activated on mainnet; the rules above describe the validator's behaviour once it does. Check the tracker before relying on either rule.