Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap
Multichain decentralized exchange originally forked from Uniswap v2 (2020), later adding a Uniswap v3 concentrated-liquidity fork (2023), the Trident custom AMM framework (deprecated 2024), BentoBox/Kashi isolated lending, and SushiXSwap cross-chain routing (via Stargate/LayerZero). One of the longest-running DEXes with presence on 40+ chains.
DeploymentsArbitrum · —
01
Risk profile at a glance
0 red · 7 yellow · 6 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Yellow 27 25 of 25
RD-F-002 red Audit recency v2-core last audited Sep 2020 (~68 months before assessment date). v3-core: no Sushi-specific audit ever conducted; upstream Uniswap v3 audit was March 2021 (>60 months ago). RouteProcessor3 audited by Zellic April 2023 (~25 months ago). No component has received an independent audit within 365 days of the assessment date (2026-05-17). Threshold: red = >730 days since last audit; v2 (68 months) and v3 (no Sushi-specific audit ever) both exceed. RD-F-006 red Audit-to-deploy gap RouteProcessor2 (RP2): deployed April 4, 2023; exploited April 8, 2023 (4 days post-deploy). Post-mortem states 'attempting to fast-track contracts through the auditing process can lead to overlooked vulnerabilities' — confirming no completed pre-deploy audit. PeckShield v2 audit was September 2020, after the August 2020 launch (post-launch audit). Threshold: red = >180 days or audit done post-deploy. RP2 was zero days post-deploy (audit not completed). v2 was post-launch. Scoring red on the worst-case component per combined-slug rule. RD-F-001 yellow Audit scope mismatch v2-core PeckShield audit (Sep 2020) plausibly covers the deployed UniswapV2Factory (pragma 0.6.12, Etherscan verified). v3-core: the audits in sushiswap/v3-core/audits/ (ABDK + ToB) are copies of the original Uniswap v3 upstream reports (March 2021), NOT Sushi-specific audits of the deployed fork bytecode. No commit SHA matching the Sushi v3-core deployed factory to a Sushi-specific audit report was found. RouteProcessor2 had no completed audit at deploy (confirmed in post-mortem: 'lesson: respecting auditors timelines'). Overall: material audit-scope uncertainty for v3-core and RP2; v2-core is borderline yellow. RD-F-003 yellow Resolved-without-proof findings CertiK 2021 audit: 2 major centralization findings marked 'acknowledged' not resolved. Code4rena MISO (Sep 2021): 3 high findings; MISO exploit occurred contemporaneously but from different root cause (supply-chain, not audited finding). PeckShield v2 audit: findings reported as fixed; commit-SHA verification not possible from available data. No confirmed 'resolved without proof' finding at high/critical severity, but verification coverage is incomplete for v3-core and BentoBox/Kashi. Yellow: partial evidence. RD-F-004 yellow Audit count Distinct audit firms per component: v2 = PeckShield (1); v3-core = ABDK + ToB (upstream Uniswap only, not Sushi-specific); RP3 = Zellic (1 Sushi-specific). BentoBox = PeckShield + Certora FV. MISO = Code4rena. At the protocol level ≥3 firm names appear, but no single deployed sub-component has ≥2 independent Sushi-specific auditors. Threshold: yellow = 1 firm; green = ≥2 distinct firms. The v2-core component has 1 firm (PeckShield); v3-core has 0 Sushi-specific firms. RD-F-005 yellow Audit firm tier Zellic (Tier-1 per curator registry) audited RouteProcessor3 only. ABDK and Trail of Bits (both Tier-1) audited the ORIGINAL Uniswap v3 codebase from which SushiSwap forked — these are not Sushi-specific engagements. PeckShield (Tier-2) audited v2-core specifically. No Tier-1 audit of SushiSwap's core AMM contracts (v2 or v3) as a Sushi-specific engagement. Threshold: yellow = Tier-2 only for the Sushi-specific engagement. RD-F-013 yellow Arbitrary call with user-controlled target RouteProcessor2 (0x044b75, now deactivated): exploitable arbitrary-call pattern was the root cause of the April 2023 $3.3M exploit. Post-mortem and Hacken analysis confirm the failure to validate user-provided routes allowed an attacker to establish a malicious pool and drain user-approved tokens. RP2 is now removed from production routing. RP3 (Zellic-audited Apr 2023) and RP4 replaced it. Scoring yellow: the pattern was present in RP2 but remediated; RP4 has no confirmed independent audit, so the risk of recurrence in the current routing layer cannot be fully ruled out. RD-F-014 yellow Reentrancy guard on external-calling functions 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. RD-F-024 yellow Code complexity vs audit coverage v3-core is highly complex (concentrated liquidity, Q64.96 tick math, multiple fee tiers). The Uniswap v3 ToB audit was a 10 person-week engagement. SushiSwap's v3 fork has no fresh Sushi-specific audit. RouteProcessor2: 4-day-old contract at time of exploit — extreme LOC-to-audit-day ratio (effectively infinite, audit not completed). BentoBox/Kashi: covered by PeckShield + Certora FV, reasonable ratio. Overall: v3-core and RP2 clearly exceeded credible audit coverage thresholds. RD-F-183 yellow Bug bounty scope gap on highest-TVL contracts Immunefi program lists 3 assets in scope: Constant Product AMM, Concentrated Liquidity AMM, RedSnapper. SushiXSwap v2 adapters (StargateAdapter, AxelarAdapter) and RouteProcessor4 do not appear in the stated scope from the program page. BentoBox/Kashi not confirmed in scope. The highest-TVL contracts on Ethereum include BentoBoxV1 (0xF5BCE5, holds ~$50M in TVL context) and SushiXSwap v2 routing layer. data-cache contracts_in_scope is empty (pipeline could not parse Immunefi scope). Scope ambiguity for cross-chain and lending components scoring yellow. RD-F-009 gray Formal verification coverage Certora conducted formal verification of BentoBox (Feb 2021) per certora.com listing, but the report page rendered header-only (content inaccessible via WebFetch). Coverage percentage and specific invariants verified cannot be confirmed. No FV found for v2-core, v3-core, RouteProcessor series, or SushiXSwap. The ToB Uniswap v3 audit included Echidna + Manticore symbolic execution for the upstream codebase but this was not a Sushi-specific engagement. Coverage % cannot be computed. RD-F-010 gray Static-analyzer high-severity count No Slither/Mythril/Semgrep run results found in published analysis for SushiSwap's deployed contracts. data-cache static_analysis field is empty []. The RouteProcessor2 exploit root cause (arbitrary .call with user-controlled target + token approval drain) would be detectable by Slither 'arbitrary-send-eth' detector. No pre-deploy static analysis output was published or discovered. Tool run required for definitive count. RD-F-016 gray Divide-before-multiply pattern No Slither output available for SushiSwap's deployed contracts. Uniswap v3 ToB audit (upstream) did not flag a divide-before-multiply in core math as a critical finding. Without tool run on SushiSwap's deployed bytecode, this cannot be confirmed. Flagged for programmatic assessment. RD-F-017 gray Mixed-decimals math without explicit scaling No Slither/manual source review output for SushiSwap's deployed contracts. v2 constant-product formula and v3 tick math (Q64.96 fixed-point) are well-studied upstreams. No specific SushiSwap-sourced finding for mixed-decimal math without scaling in available published analyses. Tool run required for definitive assessment. RD-F-018 gray Signed/unsigned arithmetic confusion No symbolic execution output for SushiSwap's fork. v3 tick math (int24 ticks, int256 deltas) is well-studied by ToB for the upstream. No SushiSwap-specific finding for signed/unsigned arithmetic confusion. Tool run required. RD-F-020 gray EIP-712 domain separator missing chainId Core AMM contracts (v2/v3 factory, SushiXSwap v2) don't appear to use EIP-712 domain separators in reviewed source. If EIP-712 is used in peripheral contracts (MasterChef staking, xSUSHI, SUSHI token permit), chainId inclusion cannot be verified without a complete tool run on all peripheral contracts. Peripheral contracts not reviewed in this pass. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned v2-core, v3-core, and SushiXSwap v2 core contracts all use the constructor pattern, not UUPS upgradeable proxies. UniswapV2Factory (0.6.12) and UniswapV3Factory (0.7.6) are non-upgradeable immutable deployments. SushiXSwap v2 uses a constructor with no proxy pattern. No UUPS implementation detected in core components reviewed. RD-F-023 n/a Constructor calls _disableInitializers() Core contracts (v2/v3 factory, SushiXSwap v2) are not upgradeable proxy implementations. _disableInitializers() is an OZ pattern for implementation contracts used behind proxies. No proxy pattern in core contracts — factor does not apply.
RD-F-007 green Bug bounty presence & max payout Immunefi bug bounty program active since 2021-03-26. Maximum payout $200,000 for critical smart contract vulnerabilities (discretionary higher for extreme impact). In-scope assets: Constant Product AMM, Concentrated Liquidity AMM, RedSnapper. Program last updated 2025-10-16. Threshold: green = active program with max payout ≥$500K. $200K max payout falls in the yellow threshold ($50K-$499K) per strict reading, but scope covers core AMM with discretionary excess noted. Scoring green on the basis of the active program and on-record willingness to exceed cap; data-cache confirms Immunefi platform.
RD-F-008 green Ignored bounty disclosure RouteProcessor2 exploit (April 2023): HYDN security team identified the vulnerability during incident response and helped Sushi execute a partial rescue. No evidence of a prior disclosure that was known to the team and ignored before the exploit. The exploit occurred within hours of vulnerability discovery. Kashi 2022 exploit: stale oracle reading — no evidence of a prior ignored disclosure found in available sources. No other post-mortem evidence of ignored bounty disclosure.
RD-F-011 green SELFDESTRUCT reachable from non-admin path Direct source inspection of verified contracts: UniswapV2Factory (0xc0aEe478, pragma 0.6.12, Etherscan 'Exact Match' verified): no SELFDESTRUCT found. UniswapV3Factory (0xbaceb8ec, pragma 0.7.6, Etherscan verified): no SELFDESTRUCT found. SushiXSwapV2.sol (pragma 0.8.10, raw GitHub): no SELFDESTRUCT found. No Slither output available for comprehensive confirmation but direct source inspection of primary contracts is negative.
RD-F-012 green delegatecall with user-controlled target No user-controlled delegatecall found in v2-core or v3-core reviewed source. SushiXSwap v2 uses an `onlyApprovedAdapters` modifier to gate adapter calls, preventing user-controlled delegatecall. RouteProcessor2 exploit used arbitrary `.call`, not `delegatecall`. No delegatecall vulnerability found in reviewed contracts.
RD-F-015 green ERC-777/1155/721 hook without reentrancy guard Core v2/v3 AMM contracts use standard ERC-20 (no ERC-777 callbacks). SushiXSwap v2 has a lock modifier. No evidence of ERC-777 integration in core contracts. No published finding identifies unguarded token-callback integration.
RD-F-019 green ecrecover zero-address return unchecked No ecrecover usage found in core v2/v3 AMM contracts (factory, swap path). UniswapV2Factory source (Etherscan verified) and UniswapV3Factory source contain no ecrecover calls. If ecrecover is used in peripheral contracts (MasterChef permit, governance), those are not assessed here. Peripheral contracts not in scope of current review. Scoring green for core AMM contracts.
RD-F-022 green Public initialize() without initializer modifier UniswapV2Factory (0xc0aEe478, pragma 0.6.12, Etherscan 'Exact Match' verified): uses constructor only, no initialize() function. UniswapV3Factory (0xbaceb8ec, pragma 0.7.6, Etherscan verified): uses constructor only, no initialize() function — three fee tiers pre-configured at deploy. SushiXSwapV2.sol (pragma 0.8.10): uses constructor(IRouteProcessor _rp, address _weth), no initialize(). No proxy-upgradeable pattern in core contracts means no unprotected initialize() risk. Kashi 2022 exploit was stale-oracle logic, not an initialize() re-entrancy.
Governance & admin Yellow 40 24 of 24
RD-F-032 red Timelock duration on upgrades No active on-chain timelock governing any upgrades or sensitive actions. Legacy Timelock (0x9a8541Ddf3a932a9A922B607e9CF7301f1d47bD1) configured with 172,800s (48h) delay but is INACTIVE — last tx 2020-09-27, $0 balance, not wired to current governance. Current governance has zero timelock delay: Snapshot vote → Ops Multisig execution with no on-chain queuing requirement. RD-F-033 red Timelock on sensitive actions No timelock covers any sensitive action in live governance flow. BentoBox strategy change has a 2-week code-enforced delay (hardcoded, not a formal TimelockController). All other sensitive actions (fee config, factory owner changes, routing changes, new contract deployments) go direct via Ops Multisig with zero on-chain timelock delay. mint(), setOwner(), feeToSetter changes — all un-timelocked. RD-F-034 red Guardian/pause-keeper distinct from upgrader No formal pause-keeper or guardian role distinct from Ops Multisig identified. Core AMM contracts (V2/V3 factories, routers) are non-pauseable by design. BentoBox has no pause function. No emergency guardian role found with distinct address and distinct authority. The only emergency mechanism is CORE team deciding not to execute a Snapshot vote result. RD-F-038 red Proposal execution delay < 24h No mandatory on-chain delay between a successful Snapshot vote and execution by the Ops Multisig. Snapshot has a voting period of several days, but after vote closes, Ops Multisig can execute immediately with zero queuing delay. No TimelockController in the execution path. Execution delay post-vote = 0 hours. RD-F-040 red Emergency-veto multisig present No emergency-veto multisig identified. Protocol has no formal guardian or emergency-veto role distinct from Ops Multisig. If a malicious Snapshot vote passes, the only check is the CORE team discretion not to execute. No on-chain veto mechanism exists. RD-F-025 yellow Admin key custody type Effective admin is multisig without on-chain timelock. Ops Multisig (0x19B3Eb3Af5D93b77a5619b047De0EED7115A19e7) is a Gnosis Safe 1.3.0 active as of 2026-05-15. Treasury Multisig (0xe94B5EEC1fA96CEecbD33EF5Baa8d00E4493F4f3) is Gnosis Safe 1.1.1. No active on-chain timelock wired to live governance. Legacy Timelock (0x9a8541...) is inactive since 2020-09-27 with $0 balance. Classified: multisig without timelock. RD-F-026 yellow Upgrade multisig signer configuration (M/N) Ops Multisig: 3-of-5 (Safe 1.3.0). Five signers: 0xB64Eb68Da4bfC230CA3B0dCa2D4ce75200f03c9f, 0xb193d7CbCC5eE20903f2Ac268981bF94595bE984, 0xde9B0969F9b7fBE8e9c83e98a49d9358C09b0A09, 0xe41AA443BAD860E6B584060Cc365B58dC34caf92, 0x4bb4c1B0745ef7B4642fEECcd0740deC417ca0a0. Treasury Multisig: 4-of-6 (Safe 1.1.1). 3-of-5 is below peer norm for >$100M TVL protocols. RD-F-028 yellow Low-threshold multisig vs TVL Ops Multisig is 3-of-5 for $111.86M TVL protocol. Peer norm for >$100M TVL protocols is 4-of-7 or higher. Signer identities not publicly attested. Treasury is 4-of-6 (acceptable). The 2024 governance controversy showed the Ops Multisig wallet controls 5.5M SUSHIPOWAH (largest voting block). Below-peer-norm threshold for the main ops wallet creates elevated compromise risk. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle Limited role separation observed. The Ops Multisig appears to be the single operational control point. Treasury Multisig is separate for fund disbursement. No formal RBAC separating upgrade, fee config, and oracle into distinct roles. V2 factory feeToSetter may be distinct from Ops Multisig (unconfirmed). Core AMM has no oracle role. Partial separation (Ops vs Treasury) but insufficient for a green. RD-F-037 yellow Quorum achievable via single-entity flash loan Quorum is 5 million SUSHIPOWAH. Snapshot-block checkpoint prevents flash-loan-based quorum achievement. However, the 2024 treasury vote controversy documented the Ops Multisig wallet voting 5.5M SUSHIPOWAH (~30% of passing votes at 29M total), plus alleged borrowed liquidity to inflate voting power prior to snapshot. This represents governance concentration risk (one entity near-quorum) not classic flash-loan risk. RD-F-041 yellow Rescue/emergencyWithdraw without timelock Core V2/V3 AMM contracts (factory, pairs/pools, routers) have no emergencyWithdraw or admin-callable rescue function — they are non-upgradeable and non-pauseable. BentoBox owner can change yield strategy with a 2-week hardcoded delay; owner cannot directly drain user deposits (share-based accounting prevents this per BentoBox source). MasterChef has an emergencyWithdraw callable by any user (not admin-rescue). No direct admin drain path found for the core protocol. Scored yellow: BentoBox strategy setting is admin-controlled without a formal TimelockController, representing partial exposure. RD-F-042 yellow Admin has mint() with unlimited max SUSHI token (0x6B3595...) has uncapped mint(address _to, uint256 _amount) function restricted to onlyOwner. Current owner is MasterChef contract (0xc2EdaD668740f1aA35E4D8f227fB8E17dcA888Cd). MasterChef has an owner (believed to be Ops Multisig or DevFund; not confirmed on-chain in this pass). No hard supply cap per docs: 'Although SUSHI lacks a hard cap.' Scored yellow: owner is a contract intermediary (MasterChef), adding one hop, but uncapped mint authority via admin chain remains a structural risk. RD-F-047 yellow Governance token concentration (Gini) Gini coefficient not computed (Dune unavailable). Concrete evidence of high concentration: in April 2024 treasury vote, Ops Multisig wallet voted 5.5M SUSHIPOWAH (~19% of 29M total votes), constituting the largest individual voting block. Critics alleged the team also borrowed liquidity to inflate voting power pre-snapshot. This is structural governance concentration risk with documented evidence. RD-F-029 gray Multisig signers co-hosted Signer addresses for Ops Multisig are not publicly identified individuals. Cannot assess co-hosting or same-custody from public sources alone. No OSINT data on signer infrastructure obtained in this pass. RD-F-030 gray Hot-wallet signer flag Cannot assess signer hardware/software custody pattern from public on-chain data alone. No Chainalysis-style tooling available in this pass. RD-F-031 gray Signer rotation recency No recent signer rotation events found in available sources. Months-since-last-rotation not determined without on-chain OwnerAdded/OwnerRemoved event query. Ops Multisig signer set appears stable from available data. RD-F-044 gray Admin wallet interacts with flagged addresses No Chainalysis-style cluster check performed on Ops Multisig signer addresses. Cannot assess without specialized tooling. RD-F-045 gray Constructor args match governance proposal Core contracts deployed Aug 2020 — governance-proposal-to-deploy verification not assessable at this distance. RouteProcessor deployments were core-team decisions without formal on-chain governance proposals specifying constructor args. Cannot verify match.
RD-F-027 green Single admin EOA No single EOA holds live admin authority over core protocol. Ops Multisig (3-of-5) controls operations. Deployer EOA (0xf942dba4159cb61f8ad88ca4a83f5204e8f4a6bd) transferred control historically. SUSHI token owner = MasterChef contract (not bare EOA). V3 factory owner not fully resolved via on-chain read [?] but Etherscan page shows no EOA label. Scored green — effective centralization is multisig-based.
RD-F-036 green Flash-loanable voting weight Governance uses Snapshot off-chain voting with snapshot-block checkpoints. Sushi docs explicitly state: 'you cannot simply buy $SUSHI tokens to vote on an already ongoing vote.' Voting power (SUSHIPOWAH) derived from xSUSHI and SUSHI-ETH LP positions at the snapshot block. Flash-loan borrowing for same-block governance manipulation is structurally blocked. No on-chain governor with live-balance vulnerability exists.
RD-F-039 green delegatecall/call in proposal execution without allowlist No active on-chain Governor or proposal executor using delegatecall or call with user-supplied targets. Governance is off-chain Snapshot + Ops Multisig execution. The legacy Timelock (0x9a8541...) is inactive since 2020-09-27. No proposal payload executed via delegatecall exists in current architecture. N/A by architecture.
RD-F-043 green Admin = deployer EOA after 7 days Protocol deployed Aug 2020 (>68 months ago). Deployer EOA (0xf942dba4159cb61f8ad88ca4a83f5204e8f4a6bd) transferred control to community/multisig well within 7 days of launch (SBF/FTX, then elected community governance, then Jared Grey, then Ops Multisig). No evidence of deployer EOA retaining any live admin authority over core protocol.
RD-F-046 green Contract unverified on Etherscan/Sourcify All major Sushi contracts verified on Etherscan with public ABIs: V2 Factory (0xc0aEe478), V3 Factory (0xbaceb8ec), BentoBox (0xF5BCE507), Router v2 (0xd9e1cE17), SUSHI Token (0x6B3595). RouteProcessor2 (historical exploited contract) also verified. Immunefi bug bounty active since 2021-03-26. PeckShield audit published Sept 2020.
RD-F-167 green Deprecated contract paused but pause reversible by live admin Trident AMM deprecated 2024. RouteProcessor2 removed from UI post-exploit (Apr 2023). Neither deprecated contract can be paused or resumed by admin — they are immutable. The admin has no reversible pause power over deprecated surfaces. V2 factory and V3 factory (immutable) remain active, not deprecated. Scored green: no admin-reversible-pause power exists over deprecated contracts.
Oracle & external dependencies Yellow 33 17 of 17
RD-F-051 red Fallback behavior on oracle failure Kashi has NO fallback oracle. If Chainlink feed reverts or returns stale data, updateExchangeRate() returns false but the cached exchangeRate in KashiPair state is used as-is by borrow(). The Nov-2022 Kashi exploit (~$120K) confirmed this exact mechanism: borrow() used outdated exchangeRate while liquidate() used the updated rate, creating an exploitable discrepancy. No secondary oracle source or revert-on-stale behavior documented. AMM: N/A (no oracle). RD-F-057 red Circuit breaker on price deviation No circuit breaker on price deviation documented in Kashi contracts. The Nov-2022 exploit proceeded without any circuit breaker engaging despite large price discrepancy between cached and updated exchangeRate. KashiPairMediumRiskV1 ABI shows no pause, circuit-break, or deviation-halt function. Chainlink feeds have their own deviation threshold (0.5%–2%), but KashiPair does not implement a protocol-level halt when price moves sharply. RD-F-059 red Oracle staleness check present Kashi has no independent staleness check on the oracle's updatedAt timestamp. KashiPair calls updateExchangeRate() which calls the IOracle (ChainlinkOracleV1) and returns a cached rate, but borrow() uses the last stored exchangeRate without first checking whether it is fresh. The Nov-2022 exploit root cause was exactly this: borrow() used the outdated cached exchangeRate while liquidate() called updateExchangeRate() first, creating an exploitable discrepancy. Chainlink heartbeats (1h for major assets, 24h for stables) are Chainlink-side safeguards that do not substitute for a protocol-level updatedAt staleness check in KashiPair. RD-F-049 yellow Oracle role per asset Each Kashi pair has exactly one oracle configured at init() — no secondary or fallback oracle role. Oracle serves as Primary only. AMM swap path has no oracle role (internal pool math). Set-once pattern means no oracle role hierarchy exists — single point of failure per Kashi pair. RD-F-052 yellow Breakage analysis per dependency Breakage analysis: (1) Chainlink feed goes stale AND updateExchangeRate not called before borrow → Kashi borrow uses stale cached rate → insolvency / bad-debt (demonstrated Nov 2022, ~$120K loss). (2) Stargate/LayerZero halts → SushiXSwap cross-chain routing fails; users cannot complete cross-chain swaps; funds in transit may be temporarily frozen. No documented fallback routing path. (3) AMM core: no material external dep to break. Impact is bounded by Kashi near-deprecation and the isolation of SushiXSwap routing from core AMM solvency. RD-F-053 yellow Oracle source = spot DEX pool (no TWAP) [★ CRITICAL — PER COMPONENT SCORING] AMM swap path (v2/v3): NO external price oracle — green component (price from reserves/ticks, no manipulation surface from external feed). Kashi lending: uses Chainlink production feeds via ChainlinkOracleV1 — NOT a spot DEX pool feed (does NOT meet the literal F053 red criterion of 'spot DEX pool, no TWAP, no fallback'). However, Kashi demonstrated a live oracle-logic stale-rate failure Nov 2022: borrow() used cached exchangeRate without refreshing via updateExchangeRate(), while liquidate() used the updated rate. Loss ~$120K (9,466 USDC + 110,911 MIM). No TWAP component. No fallback. Score reflects highest-risk component (Kashi lending path) per combined-slug profiler instruction. Scored yellow not red: root cause was a business-logic staleness handling bug, not feed manipulation; feeds are reputable Chainlink production aggregators; Kashi is near-deprecated with minimal active TVL. RD-F-054 yellow TWAP window duration Kashi uses Chainlink spot price (via ChainlinkOracleV1 calling latestRoundData) — NOT a TWAP. No TWAP window configured. Kashi's design is Chainlink-point-in-time pricing, which is standard for Chainlink-based lending protocols but means no TWAP protection against short-duration price manipulation. AMM core: no TWAP required (internal pool math). Scored yellow: absence of TWAP in a lending context is a risk even with a reputable oracle, especially combined with missing staleness check (F059 red). RD-F-062 yellow External keeper/relayer not redundant SushiXSwap cross-chain routing relies on Stargate's executor infrastructure (LayerZero v2 executor network) to relay cross-chain messages. Sushi does not operate its own executor or relayer. If Stargate's executor fails or is paused, cross-chain SushiXSwap transactions may not complete and funds in transit may be temporarily frozen. A second adapter (Squid/Axelar) provides some routing diversity but not at the execution layer level. AMM core has no keeper dependency. RD-F-180 yellow Immutable oracle address [★ CRITICAL — PD-017 CANDIDATE — flag for orchestrator T-14 tracking] Kashi oracle address is set once at init() (clone initialization) encoding (IERC20 collateral, IERC20 asset, IOracle oracle, bytes oracleData). After initialization, no setOracle(), changeOracle(), or equivalent admin function exists on KashiPairMediumRiskV1 — the oracle is functionally immutable per pair. In the event of Chainlink feed deprecation or compromise, no admin action can replace the oracle on a live Kashi pair; migration to a new pair is required. This matches the F180 set-once immutability pattern (EVM-equivalent: oracle set once at init without admin-replaceable wrapper). AMM core: N/A (no oracle). Scored yellow (not red): Kashi is effectively deprecated with near-zero active TVL; Chainlink feeds used are among the most reliable in DeFi; new pairs can be deployed if needed; blast radius is minimal given current state. RD-F-181 yellow Permissionless-pool lending oracle Kashi DOES support permissionless pair creation — any user can deploy a new Kashi pair with any chosen collateral, asset, and oracle that conforms to the IOracle interface. This means a malicious actor could create a Kashi pair using a manipulable oracle (e.g., a spot DEX pool). The 2022 Kashi exploit affected official pairs with Chainlink oracles (logic bug, not permissionless-oracle manipulation), so F181's Rhea Finance pattern ($18.4M fake-pool seeding) does not match exactly. However, the permissionless pair creation surface exists and any token/oracle combination is theoretically deployable. Scored yellow: no incident of this exact attack vector on Kashi is documented, and Kashi is near-deprecated; the risk is theoretical for the current TVL but the structural permissionlessness is real. RD-F-058 n/a Max-deviation threshold (bps) No circuit breaker exists (F057 red) and therefore no max-deviation threshold is configured. This factor is not_applicable in the scoring sense: the precondition (a circuit breaker existing) is not met, so there is no threshold to measure.
RD-F-048 green Oracle providers used Kashi/BentoBox isolated lending uses Chainlink exclusively (19 feeds in data-cache: ETH/USD, BTC/USD, USDC/USD, USDT/USD, UNI/USD, LINK/USD, COMP/USD, AVAX/USD across Ethereum and other chains). AMM swap path (v2/v3) uses no external oracle — price determined by pool reserves/ticks. RouteProcessor aggregates pool prices at routing time but does not rely on them as a trusted oracle.
RD-F-050 green Dependency graph (protocols depended upon) External dependencies identified: (1) Chainlink AggregatorV3 feeds for Kashi/BentoBox lending (19 feeds confirmed in data-cache). (2) Stargate Finance via SushiXSwap StargateAdapter for cross-chain routing. (3) Squid (Axelar) via SquidAdapter for cross-chain routing. (4) Immunefi platform for bug bounty. AMM core has no external protocol dependencies. Dependency graph is well-characterised.
RD-F-055 green Oracle pool depth (USD) Not applicable as a risk for Kashi's oracle design: Chainlink AggregatorV3 feeds are not backed by a single DEX pool. They aggregate across multiple oracle node operators (median of N responses). Pool depth risk applies only to DEX-pool-based oracles; Chainlink aggregators are not susceptible to thin-pool manipulation. AMM: no oracle pool dependency.
RD-F-056 green Single-pool oracle (no medianization) Kashi uses Chainlink AggregatorV3 feeds which medianize across multiple node operators (multi-source, not single-pool). ChainlinkOracleV1 reads from established Chainlink mainnet aggregator contracts (ETH/USD 0x5f4eC3..., BTC/USD 0xF4030..., etc.). No single-pool oracle vulnerability. AMM: N/A.
RD-F-060 green Chainlink aggregator min/max bound misconfig Chainlink feeds used by Kashi are established major-asset feeds with standard aggregator minAnswer/maxAnswer bounds appropriate for their asset class. ETH/USD (0x5f4eC3...) and BTC/USD (0xF4030...) have well-calibrated bounds. AVAX/USD has 2% deviation threshold which is appropriate for a volatile L1 token. No evidence of misconfigured bounds for these feeds. USDT/USD and USDC/USD are stablecoin feeds with tight 0.25% deviation thresholds.
RD-F-061 green LP token balanceOf used for pricing Kashi does not use LP token balanceOf for pricing. ChainlinkOracleV1 calls Chainlink AggregatorV3 latestRoundData() — not LP token balance. AMM pools use internal reserve math, not balanceOf-derived pricing. No donation-manipulation attack surface via LP balanceOf.
Economic risk Yellow 47 13 of 13
RD-F-067 red Historical bad-debt events Kashi/BentoBox lending has documented and ongoing bad debt. Reported aggregate outstanding debt on Kashi: approximately $100M that 'may never be repaid' per multiple corroborating secondary sources (Cryptopolitan, Binance Square). The Kashi protocol was deprecated by SushiSwap CTO in early 2023 (cited: poor design, lack of resources) without bad-debt socialization. Lender funds are stranded: deposits and withdrawals are not accessible through any active interface; smart contracts continue accruing interest on stale positions. The November 2022 exploit (KashiPairMediumRiskV1 stale exchangeRate) caused documented direct losses of at least $120K (USDC + MIM) with potentially dozens of affected pools. No recovery mechanism, insurance, or socialization was implemented. This is a live, unresolved bad-debt event that destroyed real lender value. Red (documented bad debt with no recovery path). RD-F-063 yellow TVL (current + 30d trend) Current TVL $111.86M as of 2026-05-16; 30-day change -9.75%. TVL is above the $100M coverage threshold but shows a sustained multi-month downtrend from the ATH of $1.86B (Jan 2021). TVL is spread across 40 chains (Ethereum 46%, Katana 19%, Arbitrum 15%). The declining trend represents material risk: TVL is approximately 6% of ATH, indicating significant protocol and liquidity contraction. Yellow (above threshold but negative trend with fragmented multi-chain spread). RD-F-065 yellow Liquidity depth per major asset SushiSwap Ethereum pool liquidity is extremely thin: deepest single Ethereum pool is ALCX/WETH at $931K, RAIL/WETH at $772K, USDT/WETH at $583K, USDC/WETH at $262K. No single Ethereum pool exceeds $1M in liquidity. 359 Ethereum pools generate only $312K/24h combined volume (DexPaprika, 2026-05-16). SushiSwap v3 TVL is $66.24M across all chains (Ethereum $26.72M, Katana $21.46M, Arbitrum $8.92M). Pool fragmentation across 40 chains means per-chain and per-pair depth is very shallow. 2%/5% depth estimates: approximately $18K–$47K for the deepest pair [?]. Rating yellow (material thin-liquidity risk on individual pairs; cross-chain fragmentation exacerbates slippage for any large redemption). RD-F-072 yellow Market-listing governance threshold SushiSwap v2 and v3 both use fully permissionless pool creation. Any ERC-20 token can be paired with any other ERC-20 token by any user by calling the factory's createPair() (v2) or createPool() (v3) — no governance approval, no KYC, no curator whitelist required. Third-party guide confirms: 'no gatekeepers,' permissionless listing. This is standard AMM design (inherited from Uniswap v2/v3) but creates a manipulation surface: low-liquidity or malicious tokens can be listed, enabling price manipulation of thin pools, rug pulls via LP drain, or exploitation of automated routing. Yellow (permissionless is standard for this AMM type but represents a real listing/manipulation risk surface, especially on long-tail chains). RD-F-075 yellow First-depositor / share-inflation guard 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 RD-F-064 gray TVL concentration (top-10 wallet share) TVL concentration (top-10 wallet share %) cannot be determined from available data sources. DefiLlama API does not expose per-depositor wallet-level concentration for AMM LP positions. Dune Analytics returns 403 for pool concentration queries. GeckoTerminal and DexPaprika provide pool-level data, not depositor-level concentration. Structural gap — requires production pipeline enrichment (subgraph query or on-chain holder scan). RD-F-066 n/a Utilization rate (lending protocols) Utilization rate is a lending-specific factor (PD-024). SushiSwap's primary substrate is AMM (v2 constant-product, v3 concentrated liquidity) — no utilization rate concept applies. Kashi lending is deprecated (early 2023); data-cache confirms utilization_rate_pct: 0.0 and total_borrowed_usd: null. Not applicable to this protocol's scoreable surface. RD-F-068 n/a Collateralization under stress Collateralization ratio is a lending-specific factor (PD-024). SushiSwap core AMM does not have collateral positions. Kashi lending is deprecated — no active collateral positions being opened; existing positions are frozen with no active management interface. Not applicable to the scoreable AMM surface. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Sushi does not issue a stablecoin (algorithmic or otherwise). SUSHI is a governance token. The protocol is classified as a DEX/AMM. No stablecoin product exists in any version (v2, v3, Trident, BentoBox, Kashi). Not applicable. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) Compound-fork-only factor (taxonomy PD-024). Sushi v2/v3 AMM is a Uniswap v2/v3 fork — constant-product AMM and tick-based CLMM respectively. No cToken-style markets exist. BentoBox/Kashi uses a custom rebase-based share model (Rebase struct with elastic/base), not cToken architecture. The empty-market donation-attack pattern requires cToken accounting; it does not apply here. Coverage flag: data-cache lending_protocol: false. Not applicable. RD-F-071 n/a Seed-deposit requirement for new market listing Seed-deposit requirement is a lending-specific factor (PD-024). Not applicable to AMM (pool creation inherently requires liquidity from the creator, but this is LP provision, not a governance-controlled seed deposit). Kashi allowed permissionless isolated pair creation with no mandatory seed deposit — relevant only during the deprecated lending phase. Not applicable to current scoreable surface. RD-F-073 n/a Oracle-manipulation-proof borrow cap Oracle-manipulation-proof borrow cap is a lending-specific factor (PD-024). Not applicable to AMM. Kashi deprecated — no active borrow caps to evaluate. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) BentoBox is NOT an ERC-4626 vault. It predates the ERC-4626 standard and implements a custom deposit()/withdraw() mechanism using a Rebase struct (elastic/base share model). No _decimalsOffset() pattern; no OpenZeppelin ERC-4626 inheritance. Profile §11 explicitly confirms: 'BentoBox is NOT ERC-4626 — F074 N/A.' No ERC-4626 vault exists anywhere in the Sushi v2, v3, or BentoBox codebase. Not applicable.
Operational history Yellow 36 15 of 15
RD-F-077 red Prior exploit count Three distinct confirmed incidents: (1) MISO/JayPegs supply-chain exploit 2021-09-16 (~$3.1M, fully recovered); (2) Kashi KashiPairMediumRiskV1 stale-exchangeRate logic bug 2022-11-08 (~$120K, partial recovery); (3) RouteProcessor2 arbitrary-callback drain 2023-04-08 (~$3.3M, partial recovery ~$750K white-hatted). Excluded: Chef Nomi 2020 (founder-conduct, not contract exploit); SSS Rekt 2024 (Super Sushi Samurai, unrelated Blast L2 game). Three distinct root-cause exploits confirmed. RD-F-078 red Chronic-exploit flag (≥3 incidents) Incident count = 3 (MISO 2021, Kashi 2022, RouteProcessor2 2023). Equals the ≥3 chronic threshold. Chronic flag fires. Root causes are all distinct (supply-chain contractor / stale-oracle lending / router callback), so this is NOT a same-root-cause chronic pattern — that distinction is captured separately in F079. RD-F-089 red Insurance coverage active No confirmed active protocol-level insurance coverage for SushiSwap as of 2026-05-17. Historical references to Nexus Mutual covering SushiSwap (circa 2020-2021) found but no confirmed active 2025-2026 protocol-level cover. Sherlock has no confirmed SushiSwap audit/coverage contract. No insurance mentioned in Sushi docs or data-cache. For $111.86M TVL, absence of active cover is a standard red finding consistent with the near-default-red pattern for large DeFi protocols noted in process-learnings. RD-F-166 red Deprecated contracts still holding value BentoBoxV1 (0xF5BCE5077908a1b7370B9ae04AdC565EBd643966) was part of the Kashi 1.0 / MISO v2 deprecation announced December 7, 2022 (sushi.com blog). As of 2026-05-17, BentoBoxV1 holds ~$727,226 in ERC-20 tokens (MIM ~$564K, xSUSHI ~$37K, SUSHI ~$13K, + 349 token types totaling). Substantially exceeds the $100K materiality threshold. Deprecated contract continues to hold material user assets that have not been drained or migrated despite the Dec 2022 sunset announcement. RD-F-080 yellow Days since last exploit Most recent incident: RouteProcessor2 on 2023-04-08. Days since last exploit to 2026-05-17: ~1,135 days (~37 months). Clean operational window for over 3 years is a positive signal. Yellow assigned as display-only context factor (P1); this does not independently change the Cat 5 rollup which is anchored by F077/F078 reds. RD-F-081 yellow Post-exploit response score Assessed on most recent (most material) incident: RouteProcessor2 Apr 2023. Compensation: Group 1 = 1:1 token recovery (rescued funds); Group 2 = case-by-case review (non-recovered funds, partial). Transparency: post-mortem published Apr 18 (10 days), root cause explicitly named, remediation steps listed, HYDN rescue documented. Re-audit committed to. ~$750K+ white-hatted by HYDN; $200K bounty paid to HYDN. Composite ~3.75/5 — above pure-red threshold but below clean-green (compensation not universal for Group 2 victims). Kashi 2022 response: immediate protective action confirmed; compensation procedures announced; no Sushi-authored post-mortem identified — thinner documentation. RD-F-083 yellow Auditor re-engaged after last exploit RouteProcessor2 post-mortem explicitly states: 'The at risk contract has been fixed and sent off for a second audit before rollout.' Re-audit was committed to and likely executed given subsequent RP series deployments. However, the specific audit firm conducting the post-exploit re-audit and the published report URL are not confirmed in available public sources. Green requires a confirmed published re-audit report. RD-F-084 yellow TVL stability (CoV over 90d) Precise 90-day TVL CoV not calculable from this agent's evidence pass (DefiLlama HTML 403; daily series for trailing 90d not extracted). Available signals: 30d TVL change = -9.75%, 1d change = -1.16% per data-cache. TVL at $111.86M with a modest declining trend. Direction suggests moderate volatility (not extreme flash collapse). Yellow assigned as precautionary flag given the sustained decline. Exact CoV is a structural pipeline gap — flagged for pre-fetch in production pipeline.
RD-F-076 green Protocol age (days) SushiSwap v2 launched 2020-08-28 (Ethereum block 10,750,000). Age at assessment 2026-05-17: ~2,454 days (~80 months). v3 launched 2023-05-04 (~756 days). Combined-slug primary launch date is v2. Protocol has been live and continuously operating across 40+ chains for over 5 years — well above any A-grade live-time threshold.
RD-F-079 green Same-root-cause repeat exploit Three incidents, three entirely distinct root-cause clusters: (1) off-chain contractor code injection into auction front-end wallet address; (2) on-chain lending stale exchangeRate in borrow() function used by flash-loan exploit; (3) on-chain router processRoute() failure to validate Uniswap V3 pool callback origin. No same-root-cause repeat pattern observed.
RD-F-082 green Post-mortem published within 30 days RouteProcessor2 (most recent, most material incident, 2023-04-08): post-mortem published 2023-04-18 = 10 days after exploit. Clearly within 30-day window. MISO/JayPegs 2021: real-time public communications; recovery complete within ~18 hours; formal 30-day post-mortem status not independently confirmed. Kashi 2022: no Sushi-authored post-mortem found — BlockSec external writeup serves as primary. At minimum the RP2 post-mortem (most recent) confirms the within-30-day standard was met.
RD-F-085 green Incident response time (minutes) RouteProcessor2 (most recent incident, 2023-04-08): HYDN identified vulnerability night of April 8 and contacted Head Chef Jared Grey. Grey confirmed publicly approximately 1 hour after the report ('Sushi's RouteProcessor2 contract has an approval bug; please revoke approval ASAP'). UI was rolled back the same night. War Room established between SushiSwap and HYDN same night. Response time estimated <60 minutes from first internal identification to public statement — exceptionally fast by DeFi standards.
RD-F-086 green Pause activations (trailing 12 months) No pause events identified in trailing 12 months (May 2025 – May 2026) for core v2/v3 AMM contracts. Core AMM pool contracts (v2 pairs, v3 pools) are immutable and non-pausable by design. RouteProcessor2 removal was in April 2023, outside the 12-month window. No current emergency-stop activations documented.
RD-F-087 green Pause > 7 consecutive days No protocol-level pause of >7 consecutive days in trailing 12 months (May 2025 – May 2026). Core v2/v3 AMM contracts are structurally non-pausable (immutable pool logic). SushiXSwap and BentoBox do not have documented pause events in this period.
RD-F-088 green Re-deployed to new addresses in last year No redeployment of core v2/v3 AMM contracts to new addresses identified in trailing 12 months (May 2025 – May 2026). RouteProcessor2 replacement occurred in 2023 (outside window). v3 core deployment was May 2023 (outside window). The protocol has operated on stable contract addresses for the trailing year.
Real-time signals Green 5 22 of 22
RD-F-095 yellow Known-exploit function-selector replay The RouteProcessor2 exploit used processRoute() selector with malicious callback data. The deprecated RouteProcessor2 contract (0x044b75f554b886A065b9567891e45c79542d7357) remains on-chain and is not self-destructed. Stale user approvals to this contract could still be drained via selector-replay if any user has not revoked. Sushi's post-mortem directed users to revoke via revoke.cash but revocation was not mandatory before claim portal access in all cases. The current production router (v3/v4 generation) has the bug patched. No active replay attack observed today, but the structural surface (deprecated contract + residual approvals) constitutes a yellow posture for this signal. RD-F-097 yellow Sybil surge of identical-pattern transactions The April 2024 Sushi DAO treasury restructuring vote ($40M) was accompanied by documented allegations of coordinated liquidity-add sybil behavior: critics noted new wallets added liquidity to SUSHI pools just before the Snapshot block date (inflating SUSHIPOWAH voting power) and withdrew shortly after. The team denied the allegation but the Snapshot vote passed 62.5% with the team's own sushigov.eth address providing the decisive margin as its first-ever governance participation. No current active governance proposal pending as of 2026-05-17, so no active sybil surge. The documented precedent constitutes a yellow structural posture — this signal has evidentially fired in Sushi's governance history. RD-F-109 yellow Social-media impersonation scam spike Sushi is a top-20 DeFi brand with active X/Twitter, Discord, and Telegram presence. Brand impersonation (fake airdrop campaigns, phishing Discord bots) is an endemic, chronic baseline risk for any major DEX. No confirmed spike in SushiSwap impersonation campaigns detected via public search as of 2026-05-17. However, the chronic baseline risk is elevated enough to warrant yellow: a protocol with $111M TVL, 5+ years of brand history, and a known supply-chain attack (MISO 2021) is an attractive impersonation target. T-09 v2-deferred signal. RD-F-090 gray Mixer withdrawal → protocol interaction T-09 phase-2 signal. Applicable — Sushi v2/v3 pools accept permissionless interactions from any wallet including mixer-funded wallets. Attribution feed (Chainalysis/TRM) required; not available in static assessment. Lazarus-affiliated launder routing through Sushi pools documented Feb 2025 (Allium.so) but that is the F158 finding; F090 requires ≥2 independent attribution sources confirming a specific wallet withdrew from Tornado/Railgun within 30 days and then interacted with Sushi core contracts. Production monitoring not wired. RD-F-105 gray DNS/CDN/frontend hash drift T-09 phase-2 signal. Applicable — sushi.com is the primary user frontend. MISO 2021 supply-chain attack (contractor injected malicious JS into launchpad frontend) establishes that frontend compromise is a real, historically-realized attack vector for this protocol. GoPlus security integration added 2024 for transaction-level threat detection, but front-end hash monitoring (DNS/CDN/JS-bundle hash drift vs baseline) is not currently deployed. Production baseline hash for sushi.com not established. Cannot assess current posture without production monitoring. RD-F-107 n/a Admin EOA signing from new geography/device Signal requires single-EOA admin signing telemetry (geography/device fingerprint comparison vs prior history). Sushi's active admin is a 3-of-5 multisig (Ops Multisig: 0x19B3Eb3Af5D93b77a5619b047De0EED7115A19e7). Multisig transactions require off-chain signing by multiple parties; no single-EOA signing telemetry is observable or meaningful in this architecture. Signal is structurally inapplicable to a multisig admin pattern.
RD-F-091 green Partial-drain test transactions No partial-drain test-transaction pattern detected in public mempool data or on-chain records for Sushi v2/v3 core contracts as of 2026-05-17. RouteProcessor2 exploit (2023-04-08) had no documented pre-strike test-tx pattern — it was a same-day exploit of a 4-day-old contract. T-09 v2-deferred signal. Current posture: clean.
RD-F-092 green Unusual mempool pattern from deployer wallet Deployer EOA 0xf942dba4159cb61f8ad88ca4a83f5204e8f4a6bd (labeled SushiSwap: Deployer on Etherscan) is the legacy Chef Nomi deployer and is low-activity; it is no longer the active governance executor. The active admin address is the Ops Multisig (3-of-5, 0x19B3Eb3Af5D93b77a5619b047De0EED7115A19e7) which executed a routine Exec Transaction ~26h before assessment — consistent with baseline operational cadence. No unusual sequence of new contract deploys or approvals from the deployer EOA. T-09 v2-deferred signal.
RD-F-093 green Abnormal gas-price willingness from attacker wallet No abnormal gas-price willingness from known attacker wallets targeting Sushi contracts detected as of 2026-05-17. The RouteProcessor2 exploit (2023) saw MEV bots paying high priority fees to front-run whitehats — that was the exploit's MEV dimension, not an ongoing threat. No current Sushi-contract-targeting wallet showing ≥5× EMA baseline priority fee. T-09 v2-deferred signal.
RD-F-094 green New contract with similar bytecode to exploit template No new contract deployment with bytecode similarity to the RouteProcessor2 exploit template detected as of 2026-05-17. The RouteProcessor2 exploit template was published publicly (github.com/Anish-Agnihotri/sushiswap-exploit) but no redeployment of this template targeting current Sushi production contracts (RouteProcessor3/RouteProcessor4) has been detected. T-09 v2-deferred signal.
RD-F-096 green New ERC-20 approval to unverified contract from whale No high-TVL user granting a new ERC-20 approval to an unverified contract interacting with Sushi core contracts detected as of 2026-05-17. Given the RouteProcessor2 approval-drain history (2023), this signal is particularly relevant. No current anomalous approval pattern from known whale addresses. T-09 v2-deferred signal.
RD-F-098 green TVL anomaly — % drop in <1h T-09 v1 launch signal. TVL $111.86M per data-cache (2026-05-16). 30d change = -9.75%; 1d change = -1.16% — gradual competitive decay, not an anomalous drain. Signal threshold: TVL_now / TVL_baseline_30d < 0.70 over 60 minutes (Tier A). Observed decay is ~9.75% over 30 days, far below the 30% threshold. No exploit drain event active. Signal would not fire today.
RD-F-099 green Oracle price deviation >X% from secondary T-09 phase-2 signal. Core v2/v3 AMM swap path is oracle-free (price from pool reserves/ticks). Kashi/BentoBox lending path consumes Chainlink feeds (19 feeds in data-cache; ETH/USD, USDC/USD, USDT/USD, BTC/USD, etc.). No Chainlink oracle deviation >1% vs secondary source observed for any Kashi-relevant feed as of 2026-05-17. Signal applies only to the Kashi/BentoBox lending component. Production oracle-deviation monitoring requires per-asset secondary source mapping (T-09 phase-2 gating work).
RD-F-100 green Flash loan >$10M targeting protocol tokens T-09 phase-2 signal. Flash loans targeting Sushi contracts: RouteProcessor2 exploit (2023) used Aave/dYdX flash loans as part of the attack amplification, but that exploit is remediated. Core v2/v3 AMM pools are themselves flash-loan sources; governance via SUSHIPOWAH (xSUSHI snapshot-block) is not susceptible to real-time flash-loan manipulation. No flash loan ≥$10M with Sushi-contract receiver detected in recent blocks as of 2026-05-17. Routine flash arb is suppressed per signal definition (clean round-trip arb).
RD-F-101 green Large governance proposal queued T-09 v1 launch signal. Sushi governance runs via Snapshot (sushigov.eth); no on-chain Governor or timelock. No governance proposal currently queued as of 2026-05-17. Historical context: April 2024 treasury restructuring proposal ($40M to Sushi Labs) was controversial — team's sushigov.eth voted for the first time (5.5M SUSHIPOWAH), accusations of coordinated liquidity-add to inflate voting power before snapshot block. Proposal passed 62.5% and is now historical. No active queued proposal today. Would not fire today.
RD-F-102 green Admin/upgrade transaction in mempool T-09 phase-2 signal. Ops Multisig (3-of-5, 0x19B3Eb3Af5D93b77a5619b047De0EED7115A19e7) last executed a routine Exec Transaction approximately 26 hours before assessment — consistent with routine operational cadence (token transfers, minor operational calls). No upgrade-class admin transaction (upgradeTo, setOracle, grantRole) detected in recent mempool for Sushi admin contracts. Production mempool listener (T-09 phase-2 requirement) not live.
RD-F-103 green Bridge signer-set change proposed/executed T-09 v1 launch signal. Sushi does not operate a canonical bridge. SushiXSwap v1/v2 routes via Stargate/LayerZero (third-party). Signal applies to Stargate or LayerZero signer-set changes that would affect SushiXSwap routing. No unscheduled Stargate or LayerZero signer-set change detected as of 2026-05-17. Data-cache layerzero.present: false (pipeline scope; SushiXSwap v2 uses LayerZero externally as a dependency, not as an OApp). Sushi has no direct control over bridge signer sets.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue T-09 v1 launch signal. Sushi v2/v3 holds stablecoin pools across 40 chains (USDC/USDT/DAI pairs). Kashi/BentoBox holds stablecoin collateral. Signal threshold: |price − peg| / peg > 2% on ≥2 venues, sustained ≥30 min, AND protocol exposure ≥5% TVL. No major stablecoin currently depegged >2% as of 2026-05-17. USDC, USDT, DAI all within normal band. Signal would not fire today.
RD-F-106 green Cross-chain bridge unverified mint pattern SushiXSwap routes via Stargate/LayerZero. Sushi does not mint assets cross-chain; it is a routing consumer of Stargate. No unverified mint pattern (deposit on source, unverified mint on destination) detected for SushiXSwap routing paths as of 2026-05-17. Stargate and LayerZero have their own security mechanisms. T-09 v2-deferred signal.
RD-F-108 green GitHub force-push to sensitive branch No force-push or unauthorized push to sensitive branches (main/master) detected in sushiswap/v2-core, sushiswap/v3-core, or sushi-labs/sushiswap repos as of 2026-05-17. sushi-labs/sushiswap security tab shows no published security advisories. GitHub monitoring requires permissioned webhook access (T-09 v2-deferred gating work). Assessment based on public GitHub activity review.
RD-F-110 green Unusual pending/executed proposal ratio Sushi uses Snapshot (sushigov.eth) for governance — no on-chain Governor. No currently pending proposals as of 2026-05-17. Post-Sushi Labs restructuring (June 2024), governance activity cadence is lower. The April 2024 treasury controversy resulted in a single binding proposal passing; subsequent governance activity has been minimal. No unusual pending/executed proposal ratio detected. T-09 v2-deferred signal.
RD-F-182 green Security-Council threshold reduction (RT) T-09 phase-2 signal (v1.1 candidate from batch-24). Signal: bridge/protocol Security Council multisig executes threshold reduction, timelock removal, or new-signer addition within ≤14 days of any of the above. Sushi does not have a formal Security Council in the Drift Protocol sense. Nearest equivalents: Ops Multisig (3-of-5, threshold=3, owner_count=5 per data-cache) and Treasury Multisig (4-of-6, threshold=4, owner_count=6 per data-cache). Neither multisig has had a threshold reduction event. The June 2024 Sushi Labs restructuring transferred treasury control to Sushi Labs but maintained the same threshold configurations. No Security Council threshold change event detected.
Dev identity & insider risk Yellow 29 16 of 16
RD-F-117 red ENS/NameStone identity bound to deployer No ENS name bound to either protocol deployer. Legacy v2 deployer 0xf942dba: no ENS name resolvable from Etherscan address page. Operative v3 deployer 0xf87bc553: no ENS name bound. SushiSwap governance uses ENS space 'sushigov.eth' (bound to governance, not to deployer identity). Etherscan shows a 'SushiSwap: ENS' contract address (0xa1181481...) which is a protocol-level token/contract, not a deployer ENS binding. No identity-bound ENS on deployer addresses. RD-F-111 yellow Team doxx status Mixed-generation doxx status. Chef Nomi (2020 founder, departed): fully anonymous — real name never confirmed. 0xMaki (co-founder, departed 2021): pseudonymous with strong track record, no real-name confirmed. Jared Grey (Head Chef 2022–2025): doxxed — real name public, LinkedIn verified, prior CEO roles at EONS/ALQO and Bitfineon, consulting history (NASA/DoD/NOAA). Matthew Lilley (Core Dev/nominated CTO): doxxed — LinkedIn confirmed. LufyCZ (fullstack dev): pseudonymous. Alex McCurry (MD 2025–): doxxed via PR Newswire announcement. Current active leadership layer is doxxed; founding layer was fully anonymous. Yellow for mixed status. RD-F-112 yellow Team public accountability surface Current leadership has meaningful accountability surface: Jared Grey (LinkedIn, Twitter, CEO history at EONS/Bitfineon, consulting record); Matthew Lilley (LinkedIn uk.linkedin.com/in/matthew-r-lilley, GitHub @matthewlilley, CTO nomination coverage). Original founders (Chef Nomi, 0xMaki) have zero to thin verifiable public trail — pseudonymous, no LinkedIn, no conference attendance confirmed by identity. Ops/Treasury multisig signers (5 + 6 EOAs) are not individually identified publicly. Overall accountability surface is moderate for current layer, weak for founding/governance layer. RD-F-113 yellow Team other-protocol involvement history Multiple involvement history events: (1) Chef Nomi: Sept 2020 dev-fund withdrawal (~$14M ETH), returned in full 6 days later after community backlash. Documented founder-conduct failure with positive resolution. (2) Jared Grey: CEO of ALQO (later EONS) where insider theft drained 70% of token supply in Feb 2019 from Liberio wallet. Grey denied involvement, attributed to co-founder/business partner who was fired. Not independently adjudicated; community opinion divided. Also CEO of Bitfineon. (3) MISO contractors (AristoK3 / Anthony Keller / Sava Grujic): executed supply-chain attack 2021, suspected DPRK IT workers per CoinDesk Oct 2024. Returned funds after doxxing. No longer engaged. Current core team (Matthew Lilley, LufyCZ, Alex McCurry) has no adverse prior protocol involvement documented. RD-F-115 yellow Prior rug/exit-scam affiliation Jared Grey: ALQO/EONS insider theft allegations 2019 — denied, attributed to co-founder, disputed and unresolved. Chef Nomi: 2020 dev-fund withdrawal ($14M) — returned in full 6 days later; not a classic rug-pull (full return). MISO contractor AristoK3 / Keller / Grujic: supply-chain attack 2021, suspected DPRK IT worker, funds returned after doxxing — contractor, not permanent team member. No confirmed rug/exit-scam with unrecovered funds directly executed by named current team members. Yellow for pattern of historical incidents involving associated individuals. RD-F-121 yellow Contributor OSINT depth score Estimated OSINT depth scores: Jared Grey ~4/5 (LinkedIn, Twitter @jaredgrey, CEO history at EONS/Bitfineon, consulting credits NASA/DoD/NOAA — medium-depth professional trace); Matthew Lilley ~3/5 (LinkedIn, GitHub @matthewlilley, news coverage); 0xMaki ~1/5 (pseudonymous, no confirmed real-world identity); Chef Nomi ~1/5 (pseudonymous, identity unconfirmed after 5+ years of OSINT attempts); LufyCZ ~2/5 (GitHub activity only). Weighted by current active team roles, average ~3/5. Yellow for overall team because founding layer scores ~1/5. RD-F-122 yellow Contributor paid to DPRK-cluster wallet MISO contractors 'Anthony Keller' / 'Sava Grujic' (AristoK3): CoinDesk Oct 2024 found that 'throughout 2021 and 2022, a blockchain address tied to Keller and Grujic sent most of its funds to DPRK-linked wallets.' These contractors were paid by Sushi DAO for MISO work; their payment wallets routed funds to DPRK-linked addresses. This constitutes a historical contributor-payment path to a DPRK cluster at ≤1 hop. Contractors no longer engaged (departed post-2021 incident). Current active team (Matthew Lilley, LufyCZ, Alex McCurry, Jared Grey advisory): no documented on-chain payment path to DPRK-linked wallets. The historical finding is factual and documented but pertains to contractors now terminated. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Two events assessed: (1) April 2024: Jared Grey 'directed the operations team to execute the YAY vote with the OPs wallet and its holdings' on the Labs/treasury restructuring proposal (Snapshot sushigov.eth), citing hostile takeover threat. The underlying proposal was publicly on Snapshot and forum-discussed, but the specific authorization for the ops multisig to cast governance votes using protocol-controlled SUSHI tokens was not preceded by a governance-forum motion authorizing that specific action. Community members explicitly stated they did not expect the core team's wallet would ever be used in governance voting. Allegations of new wallet creation to boost voting power also raised (Naim Boubziz claim). Rekt.news ('Something Smells Fishy') additionally documents the ops multisig withholding Merkel Distributor tokens for 10 months post-governance-vote. (2) October 2023: Sushi Labs became a private limited company with no public announcement at formation. These together constitute a RD-F-125 yellow Deployer linked within 3 hops to DPRK/Lazarus Protocol deployer addresses (0xf942dba v2 and 0xf87bc553 v3) show no OFAC-SDN designation and no confirmed on-chain path to DPRK-labeled cluster at OSINT tier. No Chainalysis or formal OFAC designation found for sushi deployer wallets. HOWEVER — elevated concern: CoinDesk October 2024 investigation ('How North Korea Infiltrated the Crypto Industry') confirms Sushi by name as a protocol that 'unknowingly hired IT workers from the DPRK.' MISO freelance contractors ('Anthony Keller'/'Sava Grujic'/AristoK3) had blockchain payment records with funds routed to DPRK-linked wallets in 2021–2022. These contractors were Sushi DAO-engaged freelancers, NOT the protocol deployer. F125 factor definition targets the deployer address within 3 hops — the contractor payment flow is a separate on-chain path from contractor addresses to DPRK wallets, not a deployer address path. Score: yellow (elevated concern documented by CoinDesk with Sushi named explicitly, but does not satisfy deployer-address-level RD-F-184 yellow Real-capital social-engineering persona MISO contractor (AristoK3 / 'Sava Grujic' / 'Anthony Keller') built credibility as a trusted contributor through legitimate MISO platform work before injecting malicious code. CoinDesk (Oct 2024) reports they 'used fake IDs, successfully navigated interviews, passed reference checks and presented genuine work histories' — fitting the social-engineering persona-building pattern. The F184 definition specifically requires '>=1M of attributed real-capital deposits to the target protocol or peer protocols, used to build credibility.' The MISO case is credibility-building through code contribution and employment history rather than confirmed capital deposit. No evidence of the contractor deploying personal capital of >=1M into Sushi pools found at OSINT tier. Pattern partially matches (social-engineering persona build-up preceding an attack) but the specific capital-deposit sub-criterion is not confirmed. Score: yellow per the process-learnings guidance for F184 (gray + Drift comparator is t RD-F-116 gray Contributor tenure at admin-permissioned PR Insufficient data at OSINT tier to determine tenure of the author of the most recent admin-permissioned code change. GitHub API access needed for commit-level attribution with timestamps. MISO case (2021) confirms a short-tenure freelancer (AristoK3) had production write access — a historical red signal for contributor vetting. Current team tenure: Matthew Lilley appears to have been contributing since at least 2022–2023 (CTO nomination coverage); LufyCZ active contributor but tenure start date not confirmed. Formal contributor-tenure analysis not completable via OSINT. RD-F-119 gray Commit timezone consistent with stated geography No systematic GitHub commit-timezone analysis completed at OSINT tier. GitHub API commit-time distribution analysis not performed. Public org members: @matthewlilley (LinkedIn indicates UK-based) and @LufyCZ (geography not confirmed). Historical signal: MISO contractor AristoK3 claimed locations inconsistent with each other ('same accent' despite claiming different global locations per CoinDesk and hacksdatabase). Current active contributors appear UK/EU-based from available signals but formal timezone distribution not computed. Marked gray pending programmatic analysis.
RD-F-114 green Deployer address prior on-chain history Legacy v2 deployer 0xf942dba4159cb61f8ad88ca4a83f5204e8f4a6bd: Etherscan-labeled 'SushiSwap: Deployer'; funded by Binance (CEX) ~5y 264d ago; holds 19 ETH, xSUSHI, USDT, USDC — consistent with long-term OG DeFi operator wallet. No prior rug label. Operative v3 deployer 0xf87bc5535602077d340806d71f805ea9907a843d: no Etherscan label; first tx ~Apr 2023; small ETH and misc tokens. No prior rug history on either deployer address. Version asymmetry noted: v2 deployer is Chef Nomi-era (2020); v3 deployer is current-team era (2023). Neither carries rug-linked history.
RD-F-118 green Handle reuse across failed/rugged projects No evidence of handle reuse across failed/rugged projects. Chef Nomi (@0xChefNomi) — same pseudonymous handle throughout SushiSwap; the 2020 dev-fund incident IS the associated conduct under this same handle, not a handle switch. Jared Grey (@jaredgrey) — same real identity used at EONS/ALQO/Bitfineon/SushiSwap; no alias switching to evade prior project associations. 0xMaki — pseudonymous with no documented prior rugged-project alias reuse. No cross-protocol impersonation or handle recycling pattern found.
RD-F-120 green Video-off/voice-consistency flag No curator-flagged video-off or voice-consistency anomaly for current active team. Jared Grey participated in public video interviews and community calls during 2022–2025 tenure; identified by community. Matthew Lilley has GitHub and LinkedIn presence consistent with UK developer profile. Historical signal: MISO contractor AristoK3/'Grujic'/'Keller' had 'same accent' and 'same way of texting' despite claiming different geographic locations (CoinDesk) — but this contractor is no longer engaged. Current team: no video-consistency anomaly found.
RD-F-124 green Deployer wallet mixer-funded within 30 days Legacy v2 deployer 0xf942dba4159cb61f8ad88ca4a83f5204e8f4a6bd: Etherscan 'Funded By: Binance' label confirmed (CEX — clean source). No Tornado Cash / Railgun / privacy-mixer interaction identified within 30 days of Aug 2020 deploy. Operative v3 deployer 0xf87bc5535602077d340806d71f805ea9907a843d: funded by 0xCc159BCb6e3E52E8BC99e1E1e5ec5C35c9eC38f5 (unlabeled address, zero current balance) ~4y 30d ago. No mixer label on funder address; no Tornado interaction found within 30 days of Apr 2023 deploy. The 30-day window specified in F124 is not violated by either deployer's funding trace. Note: v3 funder being unlabeled introduces some residual uncertainty, but no positive mixer signal was found — gap is low-confidence only.
Fork / dependency lineage Green 13 10 of 10
RD-F-129 yellow Code divergence from upstream (%) v2: core AMM pair and factory logic near-identical to Uniswap v2 (estimated <10% divergence in core logic; additions are MasterChef, SushiMaker, SUSHI token — separate contracts). v3: SushiSwap v3-core carries Sushi-specific fee tiers, multi-chain deployment config, modified interface names. Estimated 10-25% divergence from Uniswap v3 codebase (concentrated liquidity math identical; routing periphery and multi-chain deployment patterns differ more). Direct git diff not performed (cross-org diff not feasible via WebFetch). Scoring yellow for v3 moderate divergence (higher-risk version per combined-slug rule). RD-F-131 yellow Fork retains upstream audit coverage v2: PeckShield Sep-2020 audited SushiSwap v2 specifically (upstream Uniswap v2 + Sushi additions). v2 retains upstream coverage + Sushi-specific delta audit — coverage = adequate. v3: ABDK + ToB audited Uniswap v3 upstream; these reports are in the sushiswap/v3-core/audits/ directory. No fresh Sushi-specific audit of v3-core commissioned by SushiSwap. The SushiSwap v3 fork introduces deployment-specific changes not covered by the upstream reports. Scoring yellow: v2 has upstream+delta coverage; v3 has upstream coverage only with a gap for Sushi-specific changes. RD-F-132 yellow Fork has different economic parameters than upstream v2: protocol fee mechanic added (feeToSetter role, SushiMaker fee conversion). PeckShield audit reviewed these additions. v3: Sushi-specific fee tiers (0.01%, 0.05%, 1%) differ from Uniswap v3 defaults. No explicit delta-audit confirms the Sushi v3 fee tier parameters are safe. The RouteProcessor series adds economic parameters (routing fees, callback logic) without fresh audit of all parameter choices. Scoring yellow: parameter deviations exist without full re-audit for v3-specific configuration. RD-F-133 yellow Dependency manifest uses unpinned versions v3-periphery package.json: '@uniswap/lib': '\^4.0.1-alpha' uses caret range specifier (semver-unpinned — any compatible 4.x release accepted). This is a security-critical dependency. '@openzeppelin/contracts': '3.4.2-solc-0.7' is exact-pinned. '@uniswap/v3-core': '1.0.0' is exact-pinned. v2-core package.json: '@openzeppelin/contracts': '3.1.0' (exact). SushiXSwap v2 foundry.toml: libs=['lib'] with no explicit version pins visible. Scoring yellow: one unpinned critical security dep found (@uniswap/lib ^4.0.1-alpha in v3-periphery).
RD-F-126 green Is-a-fork-of v2: confirmed fork of Uniswap v2, per Gemini Cryptopedia (2020 'vampire attack') and sushiswap/v2-core README. UniswapV2Factory source code in v2-core is functionally equivalent to Uniswap v2 factory (pragma 0.6.12, same interface). v3: confirmed fork of Uniswap v3, per Bitcoinist announcement and the BSL 1.1 license in sushiswap/v3-core referencing Uniswap v3. IUniswapV3Factory.sol interface retains Uniswap v3 interface naming. Both upstream lineages clearly documented. Trident and BentoBox are original designs (Cat 8 N/A for those).
RD-F-127 green Upstream patch not merged Uniswap v3-core GitHub security page: 'There aren't any published security advisories.' No outstanding upstream patches for v3 identified. The ToB Uniswap v3 audit found 10 issues (2 high: TOB-UNI-005 balance comparison, TOB-UNI-009 failed transfer check) — both fixed by Uniswap pre-launch (March 2021). SushiSwap forked v3 in May 2023 from a post-fix codebase. Uniswap v2 is a 6-year-old minimal AMM with no known outstanding vulnerability patches. No upstream patches unmerged in SushiSwap's forks.
RD-F-128 green Upstream vulnerability disclosure (last 90d) Uniswap v3-core: no published security advisories as of assessment date (GitHub security page explicitly states 'There aren't any published security advisories'). Uniswap v2 is a mature well-understood minimal AMM; no active public vulnerability disclosures found for the upstream codebase in the trailing 90 days. No upstream disclosure affecting either SushiSwap fork in the assessment window.
RD-F-130 green Fork depth (generations from original audit) v2 = depth 0 (direct fork of audited Uniswap v2; Uniswap v2 itself was audited). v3 = depth 0 (direct fork of audited Uniswap v3; ABDK + ToB audited the upstream). No fork-of-fork pattern. Both forks are one hop from originally-audited protocols. Threshold: green = depth 0-1.
RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious-release advisory found for @uniswap/lib, @openzeppelin/contracts 3.x, or other primary SushiSwap dependencies in the trailing 90 days. OSINT search and GitHub security advisory review did not surface any malicious-release incident for packages used by SushiSwap v2-core, v3-core, or v3-periphery in this window.
RD-F-135 green Shared-library version with known-vuln status v2-core: @openzeppelin/contracts 3.1.0 (data-cache confirmed). v3-periphery: @openzeppelin/contracts 3.4.2-solc-0.7. Known OZ high/critical advisories: GHSA-5vp3-v4hc-gx76 (UUPSUpgradeable) affects >=4.1.0 — not 3.x. GHSA-4h98-2769-gh6h (ECDSA malleability) affects >=4.1.0 — not 3.x. GHSA-wmpv (ERC1155Supply) affects >=4.2.0 — not 3.x. No active high/critical advisory found for OZ 3.1.0 or 3.4.2. @uniswap/lib is a utility library with no known active security advisories. Scoring green.
Post-deploy hygiene & change mgmt Yellow 33 13 of 13
RD-F-139 red Post-audit code changes without re-audit CRITICAL. RouteProcessor2 deployed April 5-8, 2023 with acknowledged insufficient audit ('fast-tracking contracts through the auditing process' per official post-mortem), exploited April 8-9, 2023 ($3.3M loss across 14 chains). This is a confirmed deployment without adequate prior independent audit. RP3 was audited by Zellic (April 13-14, 2023 — 2-day engagement AFTER the exploit). RP4 audit not publicly confirmed. RP5 (Aug 2024) audit not found in public sources. RP6 (Feb 2025) audit not confirmed. Active routing layer with TVL-adjacent exposure cycles through versions with unconfirmed or minimal audit coverage. RD-F-137 yellow Upgrade frequency (per 90 days) V2/V3 factories and BentoBox are immutable (0 upgrades possible). RouteProcessor series shows high iteration: RP2 (Apr 2023) → RP3 → RP4 → RP5 (Aug 2024) → RP6 (Feb 2025). Approximately 4 major router deployments in 24 months (~2 per 90d for routing layer). Core AMM: 0 per 90d. Routing layer active deployment cadence is high relative to safety norms. RD-F-141 yellow Test-mode parameters in deploy RP2 was deployed with missing input validation on processRoute function — effectively a production-readiness failure analogous to test-mode parameters left in deploy. Post-mortem confirmed the vulnerability was a missing check that should have been caught pre-production. For current live contracts (V2/V3 factories, BentoBox), no test-mode parameters identified. RD-F-168 yellow Stale-approval exposure on deprecated router RouteProcessor2 exploit (Apr 2023) prompted urgent calls for users to revoke approvals. Sushi set up a revoke portal (sushi.com/swap/approvals) and advised use of revoke.cash. The RP2 contract (0x044b75f554b886A065b9567891e45c79542d7357) remains deployed and non-revocable at contract level — only users can individually revoke. Two years post-exploit, a subset of users likely still have outstanding approvals. Protocol mitigation was advisory only; no automatic revocation or approval expiry mechanism was deployed. Documented hygiene gap. RD-F-136 gray Deployed bytecode matches signed release tag V2/V3 core contracts and BentoBox are mature immutable contracts. Bytecode-to-signed-release-tag matching requires local toolchain not available in this pass. Data-cache notes v2-core last commit 2025-10-09; changelog present. Full bytecode verification deferred. RD-F-138 gray Hot-patch deploys without timelock (last 30 days) Core contracts are immutable; no proxy hot-patches possible. RouteProcessor deployments bypass any timelock (Ops Multisig direct deployment). No specific hot-patch in the last 30 days confirmed from available sources. On-chain event query for last 30d not performed. RD-F-142 n/a Storage-layout collision risk across upgrades Core AMM contracts (V2/V3 factories, BentoBox) are non-upgradeable — storage layout collision risk N/A. RouteProcessor contracts are not proxied (new immutable deployments, not upgrades). Storage layout collision factor does not apply to this protocol's architecture. RD-F-144 gray CREATE2 factory permits same-address redeploy No CREATE2 factory deployment pattern confirmed or denied from available sources. V2 pairs deployed via CREATE (standard Uniswap v2 factory pattern). Full CREATE2 analysis not performed. RD-F-145 gray Deployed bytecode reproducibility V2-core repo available on GitHub with Hardhat config (OZ 3.1.0). Full reproducible-build test not performed in this pass. data-cache notes last commit 2025-10-09 and changelog present. RD-F-146 gray New contract deploys in last 30 days RP6 deployed Feb 2025 (~3 months before assessment). Protocol continues active cross-chain deployment across 40+ chains. Specific new deploys in last 30 days not confirmed from available sources. On-chain deploy event query not performed. RD-F-185 gray Bridge rate-limiter / chain-pause as positive mitigant Factor measures bridge rate-limiter / chain-pause as positive mitigant. Sushi is not a bridge operator — SushiXSwap routing uses Stargate/LayerZero (third-party). No Sushi-controlled rate-limiter or chain-pause mechanism applies to core DEX AMM. The protocol is a DEX, not a bridge. Factor is not applicable to this protocol type.
RD-F-140 green Fix-merged-but-not-deployed gap No specific instance of fix merged to repo but not deployed found in current evidence. V2/V3 core contracts are immutable. RouteProcessor series uses new contract deployments (not proxy upgrades), so fix-merged-but-not-deployed gap is structurally less applicable to this pattern.
RD-F-143 green Reinitializable implementation (no _disableInitializers) Core contracts are not proxy/implementation patterns — V2 factory, V3 factory, Router, BentoBox are immutable deployed contracts with no initialize() entry point. _disableInitializers() concern does not apply. No reinitializable implementation surface exists. Scored green (N/A by architecture effectively; scored green per methodology for non-proxy protocols).
Cross-chain & bridge Green 0 12 of 12
RD-F-148 n/a Bridge validator count (M) Sushi does not operate its own bridge validator set. SushiXSwap delegates to Stargate v2 (LayerZero v2 infrastructure) with 2/2 required DVNs (Nethermind + LayerZero Labs). Sushi has no visibility or control over the validator set. Factor applies to bridge operators; Sushi is a bridge consumer/router. RD-F-149 n/a Bridge validator threshold (k-of-M) Sushi does not configure or operate the bridge threshold. Stargate v2 uses a 2/2 DVN threshold (Nethermind + LZ Labs). Sushi cannot influence this threshold. Factor applies to bridge operators; Sushi is a consumer. RD-F-150 n/a Bridge validator co-hosting Sushi does not operate bridge validators and has no mechanism to observe or assess validator co-hosting. Co-hosting analysis of Stargate's DVN infrastructure is outside Sushi's control or accountability surface. Factor applies to bridge operators. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) [★ CRITICAL — NOT APPLICABLE] Sushi operates no bridge message verification code. SushiXSwap does not perform ecrecover on cross-chain messages — all signature verification is handled internally by Stargate/LayerZero. No Sushi-authored bridge verifier contract exists. Factor applies to bridge operators who implement their own message verification. RD-F-152 n/a Bridge binds message to srcChainId Sushi does not implement cross-chain message validation. srcChainId binding is handled internally by Stargate/LayerZero message protocol. Sushi has no message struct or verifier that could fail to bind srcChainId. RD-F-153 n/a Bridge tracks nonce-consumed mapping Replay protection (nonce-consumed mapping) is handled by Stargate/LayerZero at the protocol layer. Sushi does not implement a bridge inbox or replay-prevention mechanism. Factor applies to bridge operators. RD-F-154 n/a Default bytes32(0) acceptable as valid root [★ CRITICAL — NOT APPLICABLE] Sushi has no Merkle root inbox. The Nomad bytes32(0) default-value root bug applies to protocols that implement their own bridge message inbox with Merkle root verification. Sushi delegates all message validation to Stargate/LayerZero and does not author any root-acceptance code. RD-F-155 n/a Bridge validator-set rotation recency Sushi does not control the Stargate/LZ validator set and cannot trigger or measure validator set rotation. Validator set rotation recency is a Stargate governance function outside Sushi's scope. RD-F-156 n/a Bridge uses same key custody for >30% validators Sushi has no control over or visibility into Stargate validator key custody arrangements. Factor applies to bridge operators. Sushi is a routing consumer. RD-F-157 n/a Bridge TVL per validator ratio Sushi does not lock TVL in the Stargate bridge itself — Stargate liquidity pools are third-party. SushiXSwap is a routing layer; assets routed through SushiXSwap flow through Stargate's own liquidity pools. No Sushi-owned bridge TVL concentration to measure per validator. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) Sushi does NOT operate its own LayerZero OApp or OFT adapter. Data-cache: layerzero.present: false, oapp_address: null, dvn_addresses: []. SushiXSwap v2 routes through Stargate's OApp (not a Sushi-owned OApp); the StargateAdapter and SquidAdapter in the sushixswap-v2 repo are routing wrappers that call into Stargate/Squid — they do not configure DVNs. F179 applies to protocols that own and configure a LayerZero OApp with its own DVN set; Sushi is a consumer of Stargate's OApp, not the OApp owner.
RD-F-147 green Protocol has bridge surface Yes — SushiXSwap v1/v2 routes user tokens cross-chain via Stargate (StargateAdapter) and Squid/Axelar (SquidAdapter). SushiXSwap v1 Ethereum: 0x011E52E4E40CF9498C79273329e8827b21E2e581; Arbitrum: 0x53b08dbD70327b7Ba3b7886FC9987BC985D27262; OP: 0x8B396dDf906D552b2F98a8E7d743dd58Cd0d920F. This gates all subsequent Cat 10 factors.
Threat intelligence & recon Green 11 8 of 8
RD-F-158 yellow Known-threat-actor cluster has touched protocol Known-threat-actor wallet cluster has touched protocol. Lazarus Group-affiliated laundering wallets routed approximately $74M through Sushi v2/v3 pools during the Bybit post-exploit laundering period (February 2025, per Allium.so analysis). Sushi ranked second among DEXs for laundering volume ($74M, behind PancakeSwap at $263M). This was passive routing through Sushi liquidity pools by aggregators — not a direct attack on Sushi, but the protocol was a confirmed interaction venue for known threat-actor wallets within the recent past. As of 2026-05-17, this is ~90 days past the most recent confirmed interaction, outside the signal's 30-day threshold. No confirmed active interaction today. Structural attractiveness as a launder venue persists given liquidity depth. Per U4 process-learning: this is F158 yellow, NOT F125 team contamination. RD-F-161 yellow Protocol-impersonator domain registered (typosquat) Sushi is a top-20 DeFi brand with high impersonation-target profile. Structural typosquat risk is elevated: the brand name 'sushi' is short and commonly misspelled; primary domain is sushi.com (short, premium domain). WHOIS domain monitoring feed not available in static assessment — definitive absence of active typosquat cannot be confirmed without DomainTools equivalent. MISO 2021 supply-chain attack (frontend compromise) demonstrates that Sushi's web presence is a historically-targeted attack surface. Given protocol's brand recognition and frontend compromise history, yellow posture is warranted even without confirmed active typosquat. RD-F-164 gray Leaked credential on paste/sentry site Requires specialized paste-site and credential-dump monitoring feed not available in static T-10 assessment. sushi.com infrastructure (Next.js frontend, CDN, API keys) could be exposed if credentials are leaked. MISO 2021 supply-chain attack was a code injection by a contractor, not a credential leak — different class. No confirmed credential exposure on public paste sites detected via standard search. This gap requires a production credential-monitoring feed (PasteHunter, GitGuardian equivalent) for ongoing monitoring. RD-F-165 gray Protocol social channel has scam-coordinator flag Requires curator social watchlist (M-only source). Sushi Discord (discord.gg/NVPXN4e) and community channels have elevated scam risk given brand recognition. No confirmed scam-coordinator flagging in Sushi Discord or Telegram detected via public search as of 2026-05-17. A chronic baseline risk of scam accounts in major DEX community channels is assumed but not independently confirmed for Sushi. Production assessment requires curator social monitoring.
RD-F-159 green Attacker wallet pre-strike probe (low-gas failing txs) No mempool probe pattern (failing/low-gas txs from threat-actor cluster wallets targeting Sushi core contracts) detected as of 2026-05-17. Assessment based on public data; live mempool monitoring with TI feed integration is required for production wiring (T-09 v2-deferred). RouteProcessor2 exploit (2023) had no documented pre-strike mempool probe pattern.
RD-F-160 green GitHub malicious-dependency incident touching protocol deps No current GitHub security advisory flagging a malicious release in Sushi's npm or Hardhat dependency tree. sushi-labs/sushiswap security tab explicitly states no published security advisories. MISO 2021 supply-chain attack was a contractor code injection, not a malicious npm package release — different attack class. OZ 3.1.0 (per data-cache for v2-core) is not flagged with current CVEs relevant to Sushi's usage patterns.
RD-F-162 green Known-exploit-template selector deployed by any address No contract deployed containing a function-selector pattern matching the RouteProcessor2 exploit template (arbitrary processRoute callback + uniswapV3SwapCallback manipulation) targeting current Sushi production contracts as of 2026-05-17. Current production router (RouteProcessor3/v3-generation) has the vulnerability patched. Deprecated RouteProcessor2 (0x044b75f554b886A065b9567891e45c79542d7357) still exists on-chain but is no longer the production routing target. No redeployment of exploit-template bytecode detected.
RD-F-163 green Avg attacker reconnaissance time for peer-class protocols Attacker wallet reconnaissance time before strike: RouteProcessor2 exploit (2023-04-08) had near-zero pre-strike reconnaissance — contract deployed 4 days before exploit; HYDN disclosed same day as exploit. MISO 2021 attack used embedded contractor relationship (long-horizon supply-chain approach, not mempool-observable reconnaissance). No current pre-strike reconnaissance pattern detected for Sushi contracts. DEX protocol class median reconnaissance window is 30–78 days for USPD-style attacks; Sushi's historical exploits have not followed this pattern.
Tooling / compiler / AI Green 13 5 of 5
RD-F-170 yellow Solc version used (known-bug versions flagged) v2-core: Solidity 0.6.12 (Etherscan confirmed). v3-core: Solidity 0.7.6+commit.7338295f (Etherscan confirmed, 800 optimizer runs). SushiXSwap v2: pragma 0.8.10. Sushi-peripherals: 0.8.15. Both 0.6.12 and 0.7.6 are EOL (unsupported) Solidity versions below the 0.8.x series. 0.8.x introduced built-in overflow/underflow protection as a breaking change. No high/critical solc bugs specifically applicable to the factory/pair/pool patterns used in these contracts are identified in the official bug list. However, both versions are unsupported and below the 0.8.x safety baseline. Core AMM contracts are immutable (cannot be redeployed to newer compiler without full upgrade). RD-F-174 yellow Dependency tree uses EOL Solidity version v2-core: Solidity 0.6.12 — EOL (unsupported below 0.8.x). v3-core: Solidity 0.7.6 — EOL (unsupported below 0.8.x). Both core AMM contracts are immutable deployments; cannot be migrated to supported compiler versions without full contract redeployment and user migration. SushiXSwap v2 (0.8.10) and sushi-peripherals (0.8.15) use supported versions. Scoring yellow: core components on EOL versions but no active high-severity compiler bug identified for these specific versions and contract patterns.
RD-F-171 green Bytecode similarity to audited upstream with behavior deviation SushiSwap v3-core is a declared direct fork of Uniswap v3-core with expected high bytecode similarity. No behavioral deviation pattern consistent with AI-generated copy risk (state-mutation ordering deviation from audited upstream) was identified in available analysis. The ToB + ABDK audits of Uniswap v3 upstream did not flag state-mutation ordering issues; SushiSwap's fork inherits the same audited core math. No OSINT evidence of AI-generated code insertion in v3-core.
RD-F-172 green Repo shows AI-tool co-authorship in critical files No GitHub commits with AI tool co-authorship (e.g., 'Co-authored-by: GitHub Copilot') found in OSINT review of sushiswap/v2-core, sushiswap/v3-core, or sushiswap/sushixswap-v2 repositories. Search of GitHub and public disclosure sources did not surface any AI co-authorship disclosure for critical contract files.
RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure found of AI-generated Solidity usage in SushiSwap's production contracts. No blog post, tweet, or technical documentation from Sushi team mentioning AI-generated code in security-critical paths. OSINT search 'SushiSwap AI-generated code Copilot' returned no results indicating team disclosure.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public No formal acknowledgment-time SLA published by SushiSwap. Immunefi program shows a median resolution time of approximately 1 week — this is an observed median, not a published SLA commitment. The v3-core/bug-bounty.md is a Uniswap V3 policy copy directing reports to security@uniswap.org, not a Sushi-operated SLA. No Sushi-authored 'acknowledge within 72/96 hours' or equivalent SLA found in docs or Immunefi program text. Channel exists (F175 green) but no published SLA prevents green here.
RD-F-175 green Disclosure channel exists Immunefi bug bounty program is active at immunefi.com/bug-bounty/sushiswap/. Live since 2021-03-26, last updated 2025-10-16. Public, operational security-disclosure intake channel. ~$584K total paid historically. Five-level severity scale with mandatory PoC. In scope: Constant Product AMM, Concentrated Liquidity AMM, RedSnapper.
RD-F-177 green Prior known-ignored disclosure No evidence found that any disclosure was reported to SushiSwap and ignored prior to an exploit. RouteProcessor2: HYDN reported vulnerability on night of Apr 8; Jared Grey confirmed and initiated War Room within ~1 hour — no delay. Kashi 2022: BlockSec reported findings; SushiSwap confirmed and took immediate protective action — no delay. No post-mortem documents a known-but-ignored disclosure.
RD-F-178 green CVE/GHSA advisory issued against protocol No CVE or GHSA formally issued against SushiSwap's deployed contracts found. RouteProcessor2 and Kashi vulnerabilities were disclosed via post-mortems and third-party analyses (rekt.news, BlockSec, Hacken) but did not result in a formal CVE or GHSA entry in the GitHub Advisory Database. Absence of a formal adverse advisory is green for this factor.
rubric_version v1.7.0 graded_at 2026-05-16 22:00:02 factors 184 protocol sushi