SIMD-0500 turns the one-instruction program freeze into a three-transaction rebuild

The check sits in the authority path. A dev.to post, originally published on xroot.dev, reads it out of the loader source. With the gate active, a `SetAuthority` instruction that asks to set the authority to none makes the loader read the program's bytecode version first. If that version is below v3, the instruction fails with an invalid-account-data error ^[15][5]. Solana compiles programs to SBPF, and four versions are in circulation, v0 through v3, of which only v3 stays deployable ^[3][4]. Freezing is folded into the deployment rule for a stated reason. A program that could never be redeployed in its current form must not be locked into that form, because the freeze would strand it on a format the network is retiring ^[6]. The post gives no mainnet activation date.

So the order of operations changes for anyone who left the renounce until later. Rebuild with a current toolchain to get v3 bytecode, upgrade the program with that build, then set the authority to none ^[8]. Three transactions, at least one slot between them, because the loader rejects a second mutation of the same program in the same slot ^[8]. The upgrade also moves lamports: excess from the old program-data account and the buffer's balance go to the spill account, and the buffer is left at 37 bytes, holding rent ^[9].

The population this catches is the long tail that stopped touching its code. The post describes it as 2023 and 2024 token launches with a custom program, NFT projects, small DeFi protocols and games. Add any team that goes to freeze as a trust signal after activation and finds the instruction rejected ^[7].

Extend behaves differently, in both directions. `ExtendProgram` is permissionless: anyone can grow anyone else's program-data account and pay the rent on the added bytes themselves, and a checked variant of the instruction existed and was removed ^[10]. The source comment quoted in the post says the deployment gate deliberately leaves extend alone, so a legacy program can still be grown once it can no longer be redeployed or frozen ^[12]. Under SIMD-0431 each extend must add at least 10,240 bytes, unless the program is within 10 KiB of the 10 MiB size cap, where it must add exactly the remaining headroom ^[11]. At that minimum step, an account can be grown from zero to the cap in at most 1,024 extends ^[14]. Deploy scripts that grew the account by a few hundred bytes per build now fail, and the fix is 10 KiB steps or a generous size up front ^[11].

This reaches your program only if the program-data account behind it holds v0, v1 or v2 bytecode and you still hold the upgrade authority ^[5]. For everyone else the one instruction keeps working ^[1]. In a report, "upgrade authority: none" describes only the programs that could reach that state, which is why the post argues for a second field next to it: bytecode version ^[13]. After activation, a v0, v1 or v2 program with a live authority needs a rebuild before it can renounce at all ^[13].