17,332 Solana Programs Need a Rebuild Before Their Next Upgrade

Install the Solana CLI version that Solana’s own migration guide recommends, run cargo build-sbf with no extra flags, and you’ll get a program that Solana’s network is set to reject after November.

That’s the main readiness gap ahead of Agave 4.4. From that release on, every new program deployment, upgrade or finalization must target sBPFv3. Programs already on-chain keep running. But developers who can’t produce a v3 build won’t be able to ship their next fix. I went through the release history of the major Solana toolchains to see which ones are ready, which still need manual flags, and what happens to a project that isn’t ready in time.

What Changes When sBPFv3 Becomes Mandatory

Solana’s network upgrade tracker lists “sBPFv3 Programs” under Agave 4.4, expected November 2026. It sums up the change as deployment formats going “4 → 1.” The rules are set out in SIMD-0500, “Disable deployment of SBPF-v0, -v1 and -v2.”

Once its feature gate activates, validators must reject three loader-v3 operations when the program is built for v0, v1 or v2:

• Deployment: DeployWithMaxDataLen
• Upgrades: Upgrade
• Finalization: SetAuthority or SetAuthorityChecked with no new authority, which makes a program immutable

Other operations are unaffected. InitializeBuffer, Write, ExtendProgram and Close all keep working. Programs already on-chain keep executing, and users calling them don’t need to change anything. According to Solana’s sBPFv3 programs page, a blocked deploy will fail with: “Detected sbpf_version required by the executable which are not enabled.”

The code is already in place. Agave’s 4.4.0 release candidate includes the feature disable_sbpf_v0_v1_v2_deployment, with the key B8JJXCy5amZyWG9r7EnUYLwzXSXTxG7GZ1qZ1qggo83g. That’s the same key Solana publishes. As of this week, Solana’s page lists the feature as not yet activated on testnet, and gives no devnet date.

17,332 Upgradable Programs Still Use Older Formats

SIMD-0500 includes a count of mainnet programs by format, compiled with Blueshift’s program-sync tool:

• Upgradable loader-v3 programs: 17,279 on sBPFv0, 12 on v1 and 41 on v2, for a total of 17,332
• Finalized programs across loaders v1, v2 and v3: 873, all on v0

The finalized programs are unaffected, since they can’t be upgraded anyway. The 17,332 upgradable programs are the ones that matter. Nearly all of them, 99.7%, are on the oldest format, v0. Each will need a v3 rebuild before its next upgrade.

SIMD-0500 is clear about the longer-term goal. Restricting deployments should reduce the number of old-format programs “over time,” which “will eventually allow us to deprecate the execution of these SBPF versions.” For now, the SIMD states that execution “will remain supported.” Agave does include a disable_sbpf_v0_execution feature, from the older SIMD-0161. In 4.4 it uses only a placeholder test key, so it can’t be activated on mainnet.

The Toolchain Default Is the Catch

The most important finding is in cargo-build-sbf, the compiler wrapper behind almost every Solana program build. Its repository shows when the default build target changed:

• cargo-build-sbf 4.2.0 (August 20): --arch defaults to v0
• cargo-build-sbf 4.3.0 (September 3): --arch still defaults to v0
• cargo-build-sbf 4.4.0 (September 22): --arch defaults to v3

Solana’s migration guide tells developers to install Solana CLI v4.3.0. With that toolchain, a plain build still produces a v0 program. That’s why the guide’s native Rust, Pinocchio and Quasar instructions all add --arch v3 explicitly. A team that upgrades the CLI but keeps its existing build scripts will still produce v0 programs and won’t know until a deploy fails.

The default only changes with the 4.4 toolchain. Agave tagged v4.4.0-rc.1 on October 26, so that toolchain is still a release candidate. Until it becomes stable and widely installed, the safe assumption is that the flag has to be set by hand.

Framework by Framework: Who Is Ready

Solana’s sBPFv3 page lists minimum versions. Here’s what each project’s release history shows:

Anchor. Anchor 1.2.0, released September 4, added --arch and --tools-version flags to anchor build. Its CLI also sets DEFAULT_BUILD_ARCH to “v3”, so it’s the most ready of the major frameworks. Anchor also put out maintenance releases 0.30.2, 0.31.2 and 0.32.2 together on September 14. For the 0.31 line, that’s the first release since April 2025. Projects can stay on an older major version and still meet Solana’s minimum versions. Anchor 2.0 is in release candidate, with rc.2 tagged October 12.

Pinocchio. The minimum is v0.10, released January 5. Teams moving up to v0.11, released April 8, face a separate change. Solana’s page notes that v0.11 “changed the entrypoint signature,” so the upgrade may require code changes, not just a rebuild. Pinocchio builds also need --arch v3 explicitly on the 4.3 toolchain.

Native Rust. Projects need solana-program 2.3.0 or later, plus the explicit --arch v3 flag.

Quasar. v0.1.0 or later, again built with --arch v3.

solana-verify. The verifiable-build tool shipped v0.5.2 on September 21. Its changes include “agave 4.2/4.3 Dockerfiles and SBPFv3 toolchain pins,” and its newest build image is Agave 4.3.0. Verified builds still need the flag passed through: --cargo-build-sbf-args="--arch v3". Projects that don’t depend on solana-program, such as Pinocchio programs, must also declare their CLI version in Cargo.toml so the tool picks the right image. If a team’s local build and its verification build use different settings, the hashes won’t match.

So the frameworks are ready in terms of available versions. The risk is in configuration. Except for Anchor 1.2, most build paths only target v3 if developers set the flag themselves.

What Happens to a Project That Misses the Deadline

Nothing breaks for users. A v0 program keeps running, and its accounts, tokens and integrations work as before.

The impact falls on the team that maintains it. After activation, an upgradable program that hasn’t been rebuilt can’t be upgraded and can’t be finalized. Its upgrade authority still exists, and buffers can still be written and closed, but the network will refuse the upgrade. In practice, if a team finds a bug after November, it has to rebuild for v3 before it can deploy the fix. For a team on an old framework version, that could mean upgrading dependencies in the middle of an incident.

SIMD-0500 also flags a less visible effect. Testing frameworks and mocks “will have to be adapted to either deactivate this feature or bypass the entire deployment” if they test older formats. Teams running local test environments should expect those to change too.

A Checklist Before Agave 4.4 Activates

From Solana’s guide and the toolchain code, the steps are:

• Check your current build. Run readelf -h target/deploy/<program>.so | grep Flags:. 0x3 means v3, while 0x0, 0x1 or 0x2 means the program needs rebuilding.
• Set the architecture yourself. Use Anchor 1.2 or later, or add --arch v3 to every cargo build-sbf call until the 4.4 toolchain is your default.
• Update verification settings. Pass --arch v3 to solana-verify and pin the CLI version in Cargo.toml.
• Do a test upgrade now. Upgrade on devnet or a local validator with the feature enabled, so the first v3 upgrade isn’t an emergency.

The Anza migration guide covers the same steps in more detail. The deadline only affects teams that need to ship an upgrade, so the best time to do the v3 rebuild is before one is urgent.

Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services. 

Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!