sBPFv3 Programs

sBPFv3 Programs

Q4 2026 • Solana Foundation

Solana is simplifying its runtime by making sBPFv3 the standard format for new program deployments. Today, the runtime must support four different formats, each with its own rules for loading and running programs. Requiring new programs to use sBPFv3 stops the number of programs using older formats from growing and may allow support for those formats to be removed in the future. The sBPFv3 format also moves some setup work from validators to program-building tools, so validators have less work to do when they load a program.

A new feature on the runtime will restrict deployments and modifications for programs not compiled in the new sBPFv3 format. This only restricts deployments. Current programs onchain will still continue to run as normal.

Current feature gate activation status:

Technical Details

Solana program developers might start to see the following error message when deploying or modifying programs:

  Program BPFLoaderUpgradeab1e11111111111111111111111 invoke [1]
  Detected sbpf_version required by the executable which are not enabled
  Program BPFLoaderUpgradeab1e11111111111111111111111 failed: invalid account data for instruction

This would mean that the feature has been activated and you will need to update your dependencies to build your program on sBPFv3 before deploying.

Toolchain Support for sBPFv3

These are the minimum releases that support building sBPFv3 programs. Upgrade your dependencies before deploying or redeploying programs after SIMD-0500 activates.

Why sBPFv3 Is the New Minimum

Solana programs are built and deployed with custom build tools. These tools convert source code (usually in Rust) to a Solana Berkeley Packet Filter (sBPF) format that can be read by the Solana runtime. Solana currently executes four sBPF formats: v0, v1, v2, and v3. Keeping the older formats available for new deployments would allow their usage to continue growing, requiring validators and developer tooling to support their legacy behavior indefinitely.

Each sBPF version defines the instructions, calling conventions, and ELF features that a compiled program may use. The version is recorded in the ELF header so the runtime can verify and execute the program with the correct rules.

The versions are not a linear list of every feature introduced before them. For example, v3 does not retain v2's PQR instructions or its dynamic stack frames. Instead, v3 establishes a cleaner compatibility boundary with upstream eBPF tooling. This means developers should rebuild for v3 with a supported toolchain rather than treating the migration as a header-only version change.

SIMD-0500 makes v3 the minimum for deployment, redeployment, and finalization. Existing v0, v1, and v2 programs can still execute, but requiring future deployments to use v3 lets the population of legacy programs decline over time. This creates a path to eventually retire execution support for the older formats once their usage is near zero.

sBPFv3 is the new minimum because it combines stricter ELF requirements, static syscalls, and compatibility with the eBPF v3 instruction set. Static syscalls move syscall resolution to link time, so validators no longer need to copy and modify a program's ELF in memory to resolve syscall addresses when loading it. This removes syscall relocations from the loading path, reduces temporary memory and processing work, and narrows the set of ELF metadata that validators must parse and validate.

Stricter ELF headers reinforce those gains by excluding dynamic-linking sections that sBPFv3 programs no longer need. Compatibility with the eBPF v3 instruction set also replaces Solana-specific instruction behavior with encodings that LLVM already understands. This gives compiler maintainers fewer custom differences to support, makes more upstream eBPF tooling reusable, and gives the runtime a more standardized program format to verify and execute. For developers, these changes stay largely behind the build process: a supported toolchain emits the required instructions and ELF structure automatically.

Previous Related SIMDs

SIMD-0377 adds instructions and encoding changes needed to support code generated for the eBPF v3 instruction set. The changes include 32-bit jump instructions, an eBPF-compatible callx encoding, and the removal of stack-frame gaps for sBPFv3 programs.

Programs identify the new target by setting the sBPF version in their ELF header. This allows the runtime to apply sBPFv3 semantics only to programs compiled for the new format while continuing to recognize earlier program versions.

SIMD-0178 lets the compiler resolve syscall references at link time. Today, loading a program can require runtime relocations to resolve those calls. Static syscalls remove that work and reduce the amount of dynamic ELF metadata a program needs to carry.

Together with stricter ELF headers, this gives validators a simpler program format to validate and load. For developers, the compiler and Solana toolchain will produce the required format when targeting sBPFv3.

About SIMD-0500

sBPFv3 creates a cleaner foundation for Solana program development by aligning the runtime with modern eBPF compiler output and reducing work during program loading. It also gives future compiler and runtime improvements a standardized target without forcing existing deployed programs to migrate immediately.

Learn more: Solana Upgrades