Dependency manifest uses unpinned versions
StakeWise v3's assessment for RD-F-133 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
The lib/ directory confirms OpenZeppelin contracts-upgradeable is pinned to a specific commit SHA (60b305a8f3ff0c7688f02ac470417b6bbf1c4d27) and forge-std is pinned to commit SHA b93cf4b. Pinning by exact commit hash is stricter than semantic version ranges (^ or ~) — no floating dependency. No ^ or ~ version specifiers for security-critical libraries found in foundry.toml.
Sources #
- GitHubStakeWise v3-core foundry.tomlfoundry.toml: no [dependencies] semver ranges; dependencies managed via forge submodules at exact SHAsretrieved 2026-05-16
- StakeWise v3-core lib/ directory — dependency pinslib/ directory listing: openzeppelin-contracts-upgradeable @ 60b305a8f3ff0c7688f02ac470417b6bbf1c4d27; forge-std @ b93cf4b — both pinned by commit SHAretrieved 2026-05-16
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 →