Reentrancy guard on external-calling functions

Evidence summary #

v2: Vault uses a custom reentrancy lock (not OZ nonReentrant). A read-only reentrancy vulnerability class was identified across v2 integrations (Balancer forum 'reentrancy-vulnerability-scope-expanded' 2022); Balancer v2 published a scope expansion to notify integrators. v3 (higher risk): Only _swap, _addLiquidity, _removeLiquidity internal functions have reentrancy guards. Hook callbacks (onBeforeSwap, onAfterSwap, onBeforeAddLiquidity, etc.) are explicitly reentrant by design — the docs state 'it is possible to reenter the Vault as part of a hook execution.' Third-party hook contracts create an open-ended reentrancy surface for custom logic. This is intentional but represents elevated risk compared to a fully non-reentrant protocol.

Sources #

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 →