SIMD-0685 would retire Solana's ExtendProgram instruction now that Upgrade can resize programs
Serguey Asael Shinder1 min readA new Solana Improvement Document, SIMD-0685, was merged into the proposals repository on 2 November with the status Review. Written by Joe Caulfield and Alexander Meißner of Anza and Dean Little of Blueshift, it proposes removing the ExtendProgram instruction from Loader V3, the upgradeable BPF loader.
ExtendProgram existed for two reasons, the document says: the Upgrade instruction could not grow a program's programdata account, and resizing inside a cross-program invocation is limited to 10 KiB. The previously accepted SIMD-0433 lets Upgrade resize programdata to match the ELF being deployed, which removes the first reason. After activation, ExtendProgram, discriminator 6, must fail with InvalidInstructionData, and the discriminator is retired for good. No other Loader V3 instruction or account layout changes, and deployed programs keep running, upgrading and closing as before. Deploying a larger program becomes a single Upgrade, with the rent for the growth paid through the buffer or credited to programdata beforehand.
The second reason is handled with a workflow rather than a new instruction. Programs whose upgrade authority is owned by a program, a PDA, and that need to grow by more than 10 KiB at once would use one transaction signed by a hot keypair: a CPI that hands the upgrade authority to that keypair, a top-level Upgrade, and a top-level SetAuthority that hands it back, optionally with guard instructions that check the final authority. The document lists SIMD-0164, a permissioned ExtendProgramChecked, as the alternative it rejected.
What it means
For most developers nothing changes except that extension disappears as a separate step. The teams to watch are those running programs governed by a DAO or multisig through a PDA, because their large upgrades now depend on getting that atomic hand-off right, and a mistake there means an upgrade authority left with the wrong key.