Migrate Stake to Core BPF
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Migrate the Stake program to Core BPF.
Proposal at a glance
What changes
- Migrate the Stake 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 Stake program within their runtime.
Action may be requiredValidators & operators Medium impact
Validator client teams are no longer required to implement and maintain the Stake 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 Stake 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 Stake program should be migrated to Core BPF.
Alternatives Considered
The Stake 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 Stake 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 Stake program within their runtime.
All validator client teams can work to maintain the single Stake 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
One or more sources are unavailable.
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 3
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
6M4oQ6eXneVhtLoiAr4yRYQY43eVLjrKbiDZDJc892ykExact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · stale · Sep 11, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
One or more sources are unavailable.
simd.watch community discussion · SIMD-0196
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.