cargo-build-sbf fails with 'feature edition2024 is required' on base64ct while building solana-program 3.0 — pin base64ct to 1.6.0
Building an onchain program that depends on solana-program = "3.0.0", cargo-build-sbf (3.0.6) fails during dependency resolution, not compilation:
error: failed to download `base64ct v1.8.0`
...
feature `edition2024` is required
The package requires the Cargo feature called `edition2024`, but that feature is not
stabilized in this version of Cargo (1.84.0 ...)Your own crate is edition = "2021" and your system toolchain is new enough, which makes the error look impossible. The cause is that cargo-build-sbf does not use your system cargo — it uses the cargo bundled inside Solana platform-tools, which lagged behind. An upstream transitive dependency (base64ct) moved from edition 2021 to edition 2024 in 1.8.0 — a semver-compatible release, not a major one — and the bundled cargo cannot even parse that manifest. Cargo's own guidelines treat raising the MSRV as a minor change rather than a breaking one, and edition bumps appear to be treated the same way in practice, so semver-compatible resolution pulls the unbuildable version in with no warning.
Fix by pinning the offending crate back below the edition bump:
cargo update --precise 1.6.0 -p base64ct@1.8.0Then cargo build-sbf / anchor build succeeds. Commit the resulting Cargo.lock, or CI will re-resolve forward.
The pattern generalizes: whenever build-sbf reports edition2024 is required, read the crate name out of the error and pin that crate, rather than touching your own edition field, upgrading rustup, or downgrading solana-program. It stops being necessary once platform-tools ships a cargo with edition 2024 stabilized, so check your cargo-build-sbf --version before assuming the pin is still needed.
Source: adapted from a Stack Exchange answer by Jon C (question by Michal Palkowski), https://solana.stackexchange.com/questions/23578/how-to-build-with-solana-program-3-0-0-cargo-build-sbf-3-0-6-fails-with-edition — CC BY-SA 4.0
Resolution-only check, 2026-10-30, using stock cargo 1.84.1 (same version as the platform-tools v1.51 cargo). I did not run cargo-build-sbf. (1) The pin target is too low. Per crates.io, base64ct 1.7.1-1.7.3 are edition 2021 with rust-version 1.81, 1.7.0 (edition 2024) is yanked, and 1.8.x is edition 2024. The only dependent is spki 0.8.1 with 'base64ct ^1', so --precise 1.7.3 is the newest pin that works. (2) Pinning base64ct is no longer enough. A fresh lockfile for solana-program = "3.0.0" pulls solana-secp256k1-recover 3.3.1 -> k256 0.14 -> crypto-bigint 0.7 -> cpubits 0.1.1 and digest 0.11 -> block-buffer 0.12, and all of those need edition2024. Pinning secp256k1-recover back to 3.0.0 then fails on blake3 1.8.7. Setting rust-version = "1.84" with CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback picks base64ct 1.7.3 automatically, but cpubits has no 1.84-compatible release, so 'cargo +1.84 fetch' still exits 101. (3) Source-read: cargo-build-sbf v3.0.6 defaults to DEFAULT_PLATFORM_TOOLS_VERSION = "v1.51" (Rust 1.84.1 per the platform-tools release notes) and accepts --tools-version. Platform-tools v1.54+ ships Rust 1.89, so 'cargo build-sbf --tools-version v1.54' or a newer CLI should avoid the whole edition2024 chain without per-crate pins. I have not run that here.