Disable deployment of SBPF-v0, -v1 and -v2
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Disable deployment of SBPFv0, SBPFv1 and SBPFv2.
Proposal at a glance
What changes
- deployment: DeployWithMaxDataLen
- redeployment: Upgrade
- finalization: SetAuthority and SetAuthorityChecked with no new authority
Stakeholder map
Who is affected
Builders & client teams Medium impact
dApp developers using outdated toolchains will have to update them and adjust their programs before they can re-/deploy or finalize them.
Action may be requiredValidators & operators Medium impact
Furthermore, testing frameworks and mock ups will have to be adapted to either deactivate this feature or bypass the entire deployment in order to continue to test older SBPF versions.
Action requirement unknownUsers & stakers Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
Disable deployment of SBPFv0, SBPFv1 and SBPFv2.
Motivation
The number of programs using these older SBPF versions will decrease over time as dApp developers will have to target at least SBPFv3 for re-deployments. This will eventually allow us to deprecate the execution of these SBPF versions after their existence (and thus also usage) drops to near zero.
Dependencies
This proposal depends on the following previously accepted proposals:
which together form SBPFv3. Thus, there will be a new valid deployment target before we deactivate the older ones.
New Terminology
None.
Detailed Design
After the activation of the associated feature key a validator must fail to (re-)deploy or finalize programs with any SBPF version older than SBPFv3.
Currently loader-v3 is the only loader with program management enabled, thus this means for each of the following loader-v3 instructions:
- deployment:
DeployWithMaxDataLen - redeployment:
Upgrade - finalization:
SetAuthorityandSetAuthorityCheckedwith no new authority
must return InstructionError::InvalidAccountData when the ELF (in the buffer
account for re-/deployments and in the programdata account for finalization)
contains a SBPFv0, SBPFv1 or SBPFv2 program. While InitializeBuffer, Write,
ExtendProgram and Close remain unaffected.
In order not to interfere with other SIMDs, all core program migrations (SIMD-0418) and upgrades (SIMD-0495) are exempt from this. These core programs, while owned by loader-v3, are not using the program management instructions of loader-v3 anyway.
Alternatives Considered
Not deprecating some or all older SBPF versions.
Impact
dApp developers using outdated toolchains will have to update them and adjust their programs before they can re-/deploy or finalize them.
Furthermore, testing frameworks and mock ups will have to be adapted to either deactivate this feature or bypass the entire deployment in order to continue to test older SBPF versions.
Currently Deployed SBPF Versions per Loader (Mainnet)
Analysis performed using Blueshift's program-sync tool.
| Loader | SBPFv0 | SBPFv1 | SBPFv2 |
|---|---|---|---|
| Loader-v1 (Finalized) | 136 | 0 | 0 |
| Loader-v2 (Finalized) | 315 | 0 | 0 |
| Loader-v3 (Finalized) | 422 | 0 | 0 |
| Loader-v3 (Upgradable) | 17279 | 12 | 41 |
Security Considerations
None.
Backwards Compatibility
Execution of SBPFv0, SBPFv1 and SBPFv2 will remain supported for now.
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.
PR #500 · merged SIMD-0500: Disable deployment of SBPF-v0, SBPF-v1 and SBPF-v2 26 comments and reviews · Jun 24, 2026we should probably clarify what this actually means. Maybe list out the set of core programs that are exempt and a brief explanation of what exempt means (e.g. All Loader v3 instructions may still be performed on core programs according to the rules specified in past SIMD XXX)
GitHub ↗Good point, the finalize instruction is SetAuthority.
GitHub ↗This should read something like a list of all the components that need to be changed, and the new checks they should now do. Is it just in the loader v3 instructions? Or other places? This needs to be explicit.
GitHub ↗✅ All approvals received! @Lichtso, you can now merge this by commenting /merge. ✅ Status: Ready to merge
GitHub ↗I don't mind this rewording, but can you just make it clear which ELF we're talking about with each instruction? Previously the paragraph stated program or buffer. It will be helpful to distinguish here.
GitHub ↗/merge
GitHub ↗✅ Merge successful! Lichtso(https://github.com/Lichtso)'s PR has been merged.
GitHub ↗@jacobcreech is interested in amending this SIMD so we do not deny upgrades, instead only new deployments. For anyone whose program is using Anchor and an old version of SDK deps, the upgrade block forces them to overhaul the whole program, which can turn a small, incremental upgrade into a full-blown refactor. Since we can't ever truly get rid of deployed SBPF versions 0..2, seems like we can probably be less aggressive here if it helps the ecosystem.
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 2
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · stale · Sep 9, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
simd.watch community discussion · SIMD-0500
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.