Reentrancy guard on external-calling functions
mETH Protocol's assessment for RD-F-014 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
claim() in UnstakeRequestsManager.sol lacks nonReentrant modifier (confirmed from GitHub source analysis). The contract interacts with ETH and mETH (ERC-20 via SafeERC20) — not ERC-777, so reentrancy hooks are less likely. The CEI pattern appears partially followed. MixBytes v1 audit reviewed this contract without flagging a reentrancy critical finding, suggesting the specific ordering was acceptable at audit time. Yellow rather than red because: (1) no ERC-777 hooks in use, (2) MixBytes explicitly audited this contract without a reentrancy critical, (3) SafeERC20 is used for token transfers.
Sources #
- GitHubUnstakeRequestsManager.sol — reentrancy guard inspectionUnstakeRequestsManager.sol — claim() function confirmed without nonReentrant modifierretrieved 2026-05-16
- MixBytes Mantle METH Audit — no reentrancy critical in UnstakeRequestsManagerMixBytes audit reviewed UnstakeRequestsManager without flagging reentrancy criticalretrieved 2026-05-16
Methodology #
Determine whether all state-mutating functions that perform external calls carry `nonReentrant` or an equivalent reentrancy guard.
See the full factor methodology and distribution across all protocols →