Reentrancy guard on external-calling functions
Uniswap (v2 + v3)'s assessment for RD-F-014 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
V3: Custom lock modifier (slot0.unlocked flag) applied to mint, burn, swap, flash, setFeeProtocol. Equivalent to nonReentrant. V2: Custom lock modifier (unlocked uint) applied to mint, burn, swap, skim. Both versions protected. Green.
Detail #
V3 pool uses `require(slot0.unlocked, 'LOK'); slot0.unlocked = false; _; slot0.unlocked = true;` — gas-efficient reentrancy guard stored in the Slot0 struct alongside sqrtPriceX96. This is a well-understood and thoroughly audited pattern. V2 uses the same conceptual approach with `uint private unlocked = 1` and a lock modifier on all state-mutating functions that make external calls.
Sources #
- GitHubUniswapV3Pool.sol — lock modifier (slot0.unlocked) reentrancy protectionUniswapV3Pool.sol lock modifierretrieved 2026-05-12
- UniswapV2Pair.sol — lock modifier (unlocked uint) reentrancy protectionUniswapV2Pair.sol lock modifierretrieved 2026-05-12
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 →