Dependency manifest uses unpinned versions
Kamino Lend's assessment for RD-F-133 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Anchor/SPL/core libs pinned exactly or via patch-range (~); three custom git dependencies (scope, sbod-itf, strum fork) have no semver pinning — only branch/git references.
Detail #
Cargo.toml workspace: anchor-lang/spl/core pinned exactly at 0.29.0/3.5.0; solana-program uses ~1.17.18 (patch range, industry standard). Three git deps: `scope` (Kamino-owned oracle), `sbod-itf` (Kamino-owned), `strum` (Kamino fork, 'checked_arithmetics' branch) — these are not version-range pinned but git-branch pinned, which is effectively unpinned if the branch is force-updated. Scored yellow because critical Anchor/SPL libs are pinned, but git-branch dependencies introduce supply chain uncertainty without explicit commit SHA pinning.
Sources #
- GitHubklend Workspace Cargo.tomlWorkspace Cargo.toml — anchor 0.29.0 exact, solana-program ~1.17.18, git deps without version pinsretrieved 2026-04-27
Methodology #
Determine whether `package.json`, `Cargo.toml`, or `foundry.toml` uses `^` or `~` version ranges for security-critical libraries (OpenZeppelin, Solady, etc.).
See the full factor methodology and distribution across all protocols →