Reentrancy guard on external-calling functions
Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap'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 #
v2-core UniswapV2Pair uses a `lock` mutex modifier (equivalent to nonReentrant) on swap/mint/burn. v3-core uses lock slots in pools. SushiXSwap v2 source shows a `lock` modifier (uint8 unlocked = 1). RouteProcessor2 exploit involved a callback reentrancy-adjacent pattern before state was cleared — peripheral routing did not have adequate guards. No Slither output for comprehensive confirmation of all functions. Scoring yellow: core AMM has guards; peripheral routing demonstrated a guard gap at RP2.
Sources #
- URLRouteProcessor2 Post Mortem — SushiRP2 post-mortem — callback-pattern exploit in routing layer indicates guard absence at peripheral levelretrieved 2026-05-17
- SushiXSwapV2.sol raw source — lock modifierSushiXSwapV2.sol — uint8 private unlocked = 1; modifier lock pattern presentretrieved 2026-05-17
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 →