Migrate Config to Core BPF
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Migrate the Config program to Core BPF.
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 requiredValidators & operators Medium impact
Validator client teams are no longer required to implement and maintain the Config program within their runtime.
Action may be requiredUsers & 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
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, 2026nit: 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 ↗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 ↗Now that you mention it, I think I can actually just do SIMD 0088(./0088-enable-core-bpf-programs.md).
GitHub ↗Why not use feature gates as an upgrade mechanism?
GitHub ↗@joncinque mentioned that, too. I'll update this bit.
GitHub ↗@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 ↗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 ↗Merging as this SIMD reached consensus.
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 1
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
2Fr57nzzkLYXW695UdDxDeR5fhnZWSttZeZYemrnpGFVExact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · current · Sep 11, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
simd.watch community discussion · SIMD-0140
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.