SIMD-0690: check a SHA-256 hash before Solana swaps a core program's code
Serguey Asael Shinder2 min readSIMD-0690, opened on 7 October by febo of Anza, proposes a small safety step for one of the most sensitive operations on Solana: migrating an existing program from the old Loader v2 to Loader v3. The proposal is in Review status and not yet accepted; on 11 October the SIMD bot recorded an approval from reviewer topointon-jump and listed an approval from Anza's designated reviewers as still missing.
What it extends. Under the already accepted SIMD-0418, a Loader v2 program is migrated by preparing a buffer account holding the new program bytes. When a dedicated feature gate activates, the runtime replaces the old program account with new Loader v3 program and program-data accounts built from that buffer. Feature gates are how Solana changes runtime behaviour across all validators at once, so a migration cannot happen without one.
The gap. Today nothing checks that the buffer actually contains the program everyone expects. The migration is tied to the buffer's address, not its contents. The proposal's security section names the risk: accidental or malicious substitution of program data, including changes to the buffer's bytes between the creation of the feature gate and its activation. Because these migrations replace what the proposal calls essential programs, a wrong buffer would put unexpected code where core functionality runs.
The check. A SHA-256 hash of the expected program (the ELF bytes) is supplied alongside the feature gate. On activation the runtime:
- extracts the ELF bytes from the buffer, ignoring trailing zero bytes;
- hashes them with SHA-256;
- compares the result with the expected hash.
On a match the migration runs exactly as SIMD-0418 describes. On a mismatch it fails and leaves the existing program unchanged. The only validator component affected is transaction execution in the runtime, and the author states that there are no breaking changes, since the step runs only when a migration feature gate activates. The alternative — carrying on without validation — is rejected in the text because of the risk of migrating incorrect program data into important programs.
How the hash is delivered is left to validator implementations: the proposal says it must be supplied with the feature gate "in accordance with the validator implementation", so each validator client will need to define where the expected value lives. That is the detail to watch when the proposal moves to implementation.
Why it matters beyond Solana. Upgrading a chain's built-in programs is a governance act carried out in code. Binding the change to a hash fixed in advance turns "we activate the feature for this account" into "we activate the feature for these exact bytes" — the same idea as pinning a dependency by checksum rather than by name.
Source: SIMD-0690, Hash validation in v2 program migrations, pull request opened 7 October 2026 — https://github.com/solana-foundation/solana-improvement-documents/pull/690 ; discussion — https://github.com/solana-foundation/solana-improvement-documents/discussions/689