Reentrancy guard on external-calling functions
Dolomite'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 #
DolomiteMargin uses a noEntry guard pattern (dYdX-heritage storage-based entry guard) rather than OZ ReentrancyGuard. OperationImpl.sol operates as a library with no inherent per-function guard. The old 2019 legacy contract was exploited via reentrancy on callFunction; the v2 architecture has a different guard pattern. Cannot fully confirm v2 reentrancy guard coverage without complete Operation.sol entry point inspection. Yellow: guard pattern exists in architecture but non-standard form and cannot be fully verified.
Sources #
- URLHacker Exploits Flaw in Dolomite ProjectMarch 2024 exploit details: noEntry modifier bypassed on old contract via separate TradeManager contract with no reentrancy guardretrieved 2026-05-16
- DolomiteMargin OperationImpl.solOperationImpl.sol: no explicit nonReentrant modifier in library file (guard is at Operation.sol call entry)retrieved 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 →