First-depositor / share-inflation guard
Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap's assessment for RD-F-075 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
BentoBox implements MINIMUM_SHARE_BALANCE = 1000 as a first-depositor guard: any deposit must yield at least 1000 shares; withdrawals are rejected if they would leave fewer than 1000 shares (unless fully emptied). This is minimal protection — it is a small absolute-value threshold with no virtual-share offset and no dead-shares mechanism. A sophisticated attacker with a high-value token could still execute a share-inflation attack against BentoBox before the minimum threshold prevents meaningful mitigation. For SushiSwap v2 AMM: inherits Uniswap v2's MINIMUM_LIQUIDITY = 1000 burn to address(0) on first deposit — this is the standard and adequate first-depositor protection for constant-product pairs. For v3 CLMM: tick-based architecture does not have the same cToken/share-inflation surface. Net assessment: AMM surface (v2/v3) adequately protected; BentoBox has weaker but non-trivially-zero protection. Kashi is deprecated so the risk is theoretical for the lending surface. Yellow (BentoB
Sources #
- GitHubsushiswap/v2-core — Uniswap v2 fork MINIMUM_LIQUIDITYsushiswap/v2-core: SushiSwap v2 pair inherits Uniswap v2 MINIMUM_LIQUIDITY = 1000 burn to address(0) on first depositretrieved 2026-05-17
- BentoBox.sol — MINIMUM_SHARE_BALANCE constantsushiswap/bentobox BentoBox.sol: MINIMUM_SHARE_BALANCE = 1000; 'Any deposit should lead to at least the minimum share balance'; 'There have to be at least 1000 shares left to prevent reseting the share/amount ratio'retrieved 2026-05-17
Methodology #
Determine whether the vault has a first-depositor guard (seed deposit on deploy, virtual-share offset, or floor-check).
See the full factor methodology and distribution across all protocols →