@nonreentrant Decorator vs Manual Boolean Guard for Vyper Reentrancy Protection

Question

ContextWhen securing state-changing external functions in Vyper against reentrancy, two documented patterns exist: the built-in @nonreentrant decorator and a manually managed boolean state variable. The decorator reserves a storage slot and reverts on reentry, while a manual guard offers custom revert or skip logic but demands discipline across every exit path.Constraints and UncertaintyThe decorator is function-scoped, so each vulnerable entry point must be decorated individually, and it does not automatically extend protection to other functions. A manual guard risks leaving the contract permanently locked if an exception occurs before the flag is reset, unless every revert path clears the variable. Both approaches add storage reads and writes, increasing gas relative to unprotected functions, with exact costs varying by Vyper version and EVM schedule. Additionally, @nonreentrant may be unavailable in older compiler releases, and neither pattern addresses cross-function reentrancy unless all interacting entry points are protected consistently.QuestionsFor a contract targeting Vyper 0.3.x, does the gas overhead of @nonreentrant differ materially from a well-implemented manual guard across typical state-changing functions?When cross-function reentrancy is a concern, which pattern composes more safely with a shared lock variable without introducing deadlock risk?Are there version-specific semantics in @nonreentrant (e.g., error message, storage slot allocation) that would make a manual guard preferable for long-term maintainability?

Tasadduq Burney · Answer

AnswerFor Vyper 0.3.x the gas overhead of the built‑in @nonreentrant decorator is essentially the same as a well‑implemented manual boolean guard; both add one storage write and a cheap read‑check before any external call.Confirmed factsThe decorator reserves a single storage slot and reverts on reentry; the generated code performs an unconditional jump after checking the slot.A manual guard that reads/writes the same slot incurs comparable storage reads/writes.Both patterns require the lock to be checked before every external call; using the same shared lock variable across functions prevents cross‑function reentrancy without deadlock.@nonreentrant is unavailable in Vyper releases prior to 0.2.0, but its semantics (revert on reentry, single slot) are stable across the 0.3.x series.Likely explanationBecause the compiler translates @nonreentrant into a straightforward lock‑check, there is no hidden overhead such as extra jumps or auxiliary variables. A manual guard can be marginally cheaper only if the lock variable is already read for other logic, but the extra code maintenance usually outweighs any tiny gas saving.RecommendationIf you only need the standard “revert on reentry” behavior, use @nonreentrant on each external state‑changing function for clarity and compile‑time safety.If you require a custom revert message, a skip‑on‑reentry path, or want to combine the lock with other state logic, implement a manual boolean guard and ensure every exit path (including reverts) resets the flag.For cross‑function reentrancy, share the same lock variable (either via the decorator on all functions or a manual guard) and verify that no function forgets the check.To confirm that the gas difference is negligible on your target chain, you would need to measure the exact cost of a protected call versus an unprotected one under the current EVM gas schedule.Missing diagnostic detailDo you need a custom revert message or alternative behavior (e.g., skipping the call) when reentry is detected?

@nonreentrant Decorator vs Manual Boolean Guard for Vyper Reentrancy Protection

Context

Constraints and Uncertainty

Questions

1 answer

Answer

Confirmed facts

Likely explanation

Recommendation

Missing diagnostic detail

Your perspective belongs here.

0 question comments