Reentrancy guard on external-calling functions
Lombard Finance'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 #
BridgeV2.sol imports ReentrancyGuardUpgradeable and applies the nonReentrant modifier to deposit() (multiple overloads) and handlePayload() — the most external-call-heavy functions. BaseLBTC.sol also inherits ReentrancyGuardUpgradeable. Core bridge and minting functions are guarded. No reentrancy finding in any published audit (Veridise 0 findings; OZ findings were governance/logic, not reentrancy). Peripheral contracts (PMM, StakeAndBake, iDepositor) not fully inspected.
Sources #
- GitHubBridgeV2.sol source — reentrancy guards confirmedBridgeV2.sol: ReentrancyGuardUpgradeable imported; nonReentrant on deposit() and handlePayload()retrieved 2026-05-05
- Veridise V2 Audit — zero findingsVeridise V2: 0 findings (includes reentrancy scope)retrieved 2026-05-05
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 →