Solana sBPFv3: why your next program deploy will fail unless you rebuild

sBPF is the bytecode format a Solana program is compiled to, and four versions exist, v0 to v3. With Agave 4.4, expected in November 2026, the network will accept only sBPFv3 for a first deployment or an upgrade (SIMD-0500). Programs already on chain keep running unchanged. The catch is the next upgrade: on October 16, 2026, none of the 20 major mainnet programs I checked was built as v3, and several of them were upgraded in the last week.

Everything here comes from the Solana upgrade page and from reading program headers on mainnet, with the script below. First, how to check your own build.

$ readelf -h target/deploy/my_program.so | grep Flags:

Flags: 0x0

$ agave-install init v4.3.0

solana-cli 4.3.0

$ cargo build-sbf --arch v3

To deploy this program:

$ solana program deploy target/deploy/my_program.so

$ readelf -h target/deploy/my_program.so | grep Flags:

Flags: 0x3

Tap the diagram to jump · ← → to step

1. Command 01Read the header of your current build

   e_flags in the ELF header is the sBPF version. 0x0 here means v0, which an upgrade after Agave 4.4 will reject. On macOS use llvm-readelf from the platform tools in ~/.cache/solana.

2. Command 02Install the toolchain that builds v3

   Solana CLI 4.3.0. Confirm with solana --version afterwards.

3. Command 03Rebuild for v3

   Native Rust uses --arch v3. Anchor projects run anchor build with a supported Anchor version.

4. Command 04Check again

   0x3 is v3. Deploy or upgrade as usual. Outputs on this page are what you should see, not a copy of my terminal.

← Prev▶ PlayNext →

What is sBPFv3?

The newest version of the format every Solana program is compiled to before it is deployed. Validators have to support all four versions, because programs built years ago still run. SIMD-0500 stops the network from accepting new code in the older three, so that over time there is one format to support.

v3 lets validators patch fewer addresses when they load a program and parse less metadata, and its encodings match what upstream LLVM produces for eBPF. Moving to it is a rebuild with a newer toolchain, not an edit to a header.

Will my deploy or upgrade fail?

Your build

readelf -h target/deploy/my_program.so | grep Flags:

Flags: 0x0

The network

SIMD-0500 active · sBPFv3 only

→ Detected sbpf_version required by the executable which are not enabled · invalid account data for instruction

Rejected

An upgrade of an sBPFv0 program is rejected once the feature is active. Rebuild with --arch v3 and deploy again.

Built asv0v1v2v3YouKeep runningFirst deployUpgradeAgave 4.4 gateTodayAfter activation

The rule is short: once the feature is active, a deploy, an upgrade or a finalization of anything but v3 is rejected with Detected sbpf_version required by the executable which are not enabled, reported as invalid account data for instruction. Running programs, and clients that call them, are not affected.

The feature gate is B8JJXCy5amZyWG9r7EnUYLwzXSXTxG7GZ1qZ1qggo83g. Activation is expected with Agave 4.4 in November 2026, and the devnet date is not set yet.

Which mainnet programs are already sBPFv3?

None of the ones I checked. I read the ELF header of 20 programs that bots and wallets touch every day, on October 16, 2026:

Exact dates come from the block time of the slot each program was last deployed in. The ones marked "early", "mid" or "Aug" are placed between known slots, not read directly.

This does not mean anything is broken. These programs run fine and will keep running. It means the teams that upgrade every week or two, the trading programs at the top of the list, have to switch toolchains before their first upgrade after activation. If you depend on one of them through CPI, nothing changes for you.

To check any program yourself, read the first bytes of its program data account. For an upgradeable program the ELF file starts 45 bytes in, and e_flags is 48 bytes into the ELF header:

import base64, json, urllib.request

RPC = "https://api.mainnet-beta.solana.com"
B58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"

def rpc(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC, body, {"Content-Type": "application/json"})
    return json.load(urllib.request.urlopen(req))["result"]["value"]

def b58(raw):
    n, out = int.from_bytes(raw, "big"), ""
    while n:
        n, r = divmod(n, 58)
        out = B58[r] + out
    return out

def sbpf_version(program_id):
    program = rpc("getAccountInfo", [program_id, {"encoding": "base64"}])
    programdata = b58(base64.b64decode(program["data"][0])[4:36])
    head = rpc("getAccountInfo", [programdata, {"encoding": "base64", "dataSlice": {"offset": 45 + 48, "length": 4}}])
    return int.from_bytes(base64.b64decode(head["data"][0]), "little")

print(sbpf_version("6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"))  # Pump: 0 on October 16, 2026

What do I need to rebuild?

• Solana CLI 4.3.0, installed with agave-install init v4.3.0 or the Anza install script.
• Anchor: 0.30.2, 0.31.2, 0.32.2 or 1.2.0 and later, then anchor build.
• Pinocchio: 0.10 or later. 0.11 changed the entrypoint to take &mut [AccountView], so code may need edits.
• Native Rust: solana-program 2.3.0, built with cargo build-sbf --arch v3.
• Verified builds: set solana = "4.3.0" under [workspace.metadata.cli] in the root Cargo.toml, then pass --cargo-build-sbf-args="--arch v3" to solana-verify build or solana-verify verify-from-repo.

Then run your tests on the v3 build before the upgrade that matters. A rebuild with a new toolchain is new code, and the compute units it uses can differ from the old build. Measure it rather than assume it. A transaction sized to the last compute unit of the old build is exactly the kind of thing to re-check, as with priority fees in v1 transactions.

This is the third change this autumn that lands on deploy and send scripts rather than on users, after the 200 ms slot and the rent cut.

What do the terms mean?

• sBPF: Solana's variant of the eBPF bytecode format. Every on-chain program is an sBPF ELF file.
• ELF: the executable file format. Its header carries e_flags, which here is the sBPF version.
• Program data account: the account that holds the code of an upgradeable program. The program account points to it.
• Syscall: a function a program calls in the runtime, such as logging or hashing. v3 resolves them when the program is linked, not when it is loaded.
• Feature gate: a switch in the validator software that turns a change on at an epoch boundary.

FAQ

Will my existing Solana program stop working with sBPFv3?

No. Programs already on chain keep running unchanged, whatever version they were built as. Only deploying or upgrading a program built as v0, v1 or v2 is rejected once the feature is active.

When does Solana require sBPFv3?

With Agave 4.4, which the Solana upgrade page expects in November 2026. The devnet date is not set yet. The feature gate is B8JJXCy5amZyWG9r7EnUYLwzXSXTxG7GZ1qZ1qggo83g.

How do I check which sBPF version my program is?

Run readelf -h on the .so file and look at Flags. 0x3 means sBPFv3. 0x0, 0x1 or 0x2 means you need to rebuild. For a deployed program, read e_flags from the start of its program data account.

What error do I get if I deploy an old sBPF version?

Detected sbpf_version required by the executable which are not enabled, reported as invalid account data for instruction.

Which Anchor version supports sBPFv3?

Anchor 0.30.2, 0.31.2, 0.32.2, or 1.2.0 and later, with Solana CLI 4.3.0.

Further reading

• sBPFv3 Programs: the Solana upgrade page, with toolchain versions and the verification steps.
• SIMD-0500: Disable deployment of sBPF v0, v1 and v2: the proposal that makes sBPFv3 the only accepted format.