Skip to main content
Technical proposal SIMD-0140 Activated

Migrate Config to Core BPF

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. Active

Decision brief

Why this proposal matters

Migrate the Config program to Core BPF.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • Migrate the Config program to Core BPF.

Stakeholder map

Who is affected

Builders & client teams Medium impact

Validator client teams are no longer required to implement and maintain the Config program within their runtime.

Action may be required
Validators & operators Medium impact

Validator client teams are no longer required to implement and maintain the Config program within their runtime.

Action may be required
Users & stakers Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

Migrate the Config program to Core BPF.

Motivation

BPF programs offer less complexity than native programs for other clients, such as Firedancer, since developers will no longer have to keep up with program changes in their runtime implementations. Instead, the program can just be updated once.

In this spirit, the Config program should be migrated to Core BPF.

Alternatives Considered

The Config program could instead remain a builtin program. This would mean each validator client implementation would have to build and maintain this program alongside their runtime, including any future changes.

New Terminology

N/A.

Detailed Design

The Config program will be reimplemented in order to be compiled to BPF and executed by the BPF loader.

The reimplemented program's ABI will exactly match that of the original.

The reimplemented program's functionality will exactly match that of the original, differing only in compute usage. Instead it will have dynamic compute usage based on the VM's compute unit meter.

The program will be migrated to Core BPF using the procedure outlined in SIMD 0088.

The program will have no upgrade authority. If changes are required, for essential network operations, the program will be updated using feature-gates.

Impact

Validator client teams are no longer required to implement and maintain the Config program within their runtime.

All validator client teams can work to maintain the single Config program together.

Security Considerations

The program's reimplementation poses no new security considerations compared to the original builtin version.

The greatest security concern is a mistake in the reimplementation.

Backwards Compatibility

The Core BPF implementation is 100% backwards compatible with the original builtin implementation.

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 #140 · merged SIMD-0140: Migrate Config Program to Core BPF 14 comments and reviews · Feb 2, 2026
@joncinque

nit: since it's merged, what do you think about linking the actual proposal in the repo? suggestion SIMD 0088(https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0088-enable-core-bpf-programs.md).

GitHub ↗
@joncinque

It might be worth calling out that the biggest risk is a mistake in the reimplementation. It's not a big deal for the config program, but the stake program is certainly a huge risk.

GitHub ↗
@buffalojoec

Now that you mention it, I think I can actually just do SIMD 0088(./0088-enable-core-bpf-programs.md).

GitHub ↗
@ripatel-fd

Why not use feature gates as an upgrade mechanism?

GitHub ↗
@buffalojoec

@joncinque mentioned that, too. I'll update this bit.

GitHub ↗
@buffalojoec

@joncinque @CantelopePeel How best to specify the program within the SIMD? Here's the IDL: https://github.com/solana-program/config/blob/main/program/idl.json Do we just link it? Maybe add a program-specs folder? Lmk any ideas.

GitHub ↗
@ripatel-fd

As soon as the core BPF program is ready I suggest posting its final BLAKE3 hash to the doc. And providing a link to the source and the compiled program. This SIMD can't be reviewed before the program is written. (Would like to see how far we can optimize it without making it harder to read. The Rust Solana program SDK is extremely bloaty. Typically ~10x more code footprint and CUs than an optimized program)

GitHub ↗
@0xSol

Merging as this SIMD reached consensus.

GitHub ↗

simd.watch community discussion · SIMD-0140

Powered by Giscus · Sign in with GitHub to comment

Community comments load when this section approaches the viewport.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
1

SIMD

Deployment Status

Document lifecycleActivated
CategoryCore protocol
Devnetactive Epoch 817
Testnetactive Epoch 746
Mainnet-Betaactive Epoch 753
2Fr57nzzkLYXW695UdDxDeR5fhnZWSttZeZYemrnpGFV

Exact source revision

Sources & integrity

  • Proposal document pinned_commit_blob
    0616093b2952ed6de52c4a27d66aadd11d48d4f9
  • simd-document document · current · Sep 11, 2026
    0616093b2952ed6de52c4a27d66aadd11d48d4f9

One or more sources are unavailable.