Timelock on sensitive actions
Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap's assessment for RD-F-033 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
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.
Sources #
- DocsBentoBoxV1 — Etherscan sourceBentoBox source via Etherscan — setStrategy has 2-week hardcoded delay; all other admin functions are directretrieved 2026-05-17
- 00-profile.md §6 Governance TopologyProfile §6: No active on-chain timelock wired to current governance flowretrieved 2026-05-17
Methodology #
For each sensitive action category (mint / pause / rescue / setOracle / upgrade), determine whether execution requires going through the declared timelock.
See the full factor methodology and distribution across all protocols →