Dependency manifest uses unpinned versions
ether.fi'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 .gitmodules file pins openzeppelin-contracts to branch v4.8.0 and openzeppelin-contracts-upgradeable to branch v4.8.2. The git tree confirms all 6 submodule dependencies are pinned to specific commit SHAs: forge-std (77041d2), OZ (0457042), OZ-upgradeable (f6c4c9c), solady (8583a6e), v3-core (e3589b1), v3-periphery (80f26c8). EigenLayer-contracts is commit-SHA pinned in the tree (via the submodule SHA mechanism) but not branch-constrained in .gitmodules — this is the correct posture for a dependency that undergoes active development. Build is reproducible at current commit. No ^ or ~ floating version references (Foundry uses git submodules, not npm packages).
Sources #
- GitHubGit tree — all 6 submodules have pinned commit SHAsapi.github.com/repos/etherfi-protocol/smart-contracts/git/trees/HEAD?recursive=1retrieved 2026-04-28
- .gitmodules — OZ branches pinned v4.8.0/v4.8.2; others floating by branch but SHA-pinned in treeraw.githubusercontent.com/etherfi-protocol/smart-contracts/master/.gitmodulesretrieved 2026-04-28
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 →