Dependency manifest uses unpinned versions
mETH Protocol'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 #
.gitmodules uses branch-tracking for all submodules: openzeppelin-contracts (branch: v4.9.0), openzeppelin-contracts-upgradeable (no branch specified), aave-v3-origin (no branch specified), forge-std (no branch specified), openzeppelin-contracts-v5 (release-v5.0 branch). No submodule is pinned to an exact commit SHA. Branch-tracking submodules can drift if the upstream branch receives new commits. For OZ v4.9.0 (a final release of v4.x) the risk is lower since the branch is stable, but the pattern is technically unpinned at commit level. Yellow: OZ unpinned at commit level.
Sources #
- GitHubmantle-lsp/contracts .gitmodules — branch-tracking (no commit SHA pinning).gitmodules: branch: v4.9.0 for openzeppelin-contracts, no commit SHA pinned; other submodules also branch-tracking without commit pinsretrieved 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 →