HostHostDeFi › Is SushiSwap safe
Is SushiSwap safe? The day an approved router became the attacker
SushiSwap contributes this family's sharpest approval-layer lesson: in April 2023 its promoted RouteProcessor2 router shipped with a validation bug, and every user who had approved it became drainable — ~$3.3M out of one wallet before whitehats front-ran the rest and rescued over $600K. Non-custodial, fully 'safe' by custody math — and users still got drained by the contract they approved.
What SushiSwap is
SushiSwap is one of the oldest names in DeFi — the community-run 2020 fork of Uniswap that grew into a multi-chain AMM plus aggregation stack. Custody-wise it is the same shape as every real DEX in this family: no held keys, no deposits, wallet-signed execution. What earns it its own page is that it produced the clearest documented case of the failure mode the whole approval model carries.
April 8–9, 2023: RouteProcessor2
SushiSwap had just shipped RouteProcessor2, a new aggregation router, and made it the default path in the frontend. It contained a validation flaw: crafted route parameters let the router execute arbitrary calls — including transferFrom — on any token a user had approved it to spend. The exposure set wasn't 'SushiSwap users' in the abstract; it was precisely 'everyone holding a live RouteProcessor2 allowance' — and because the router was the promoted default, that set was exactly the venue's most active users.
The most visible single drain was ~1,800 WETH (~$3.3M) from one prominent wallet. Security researchers flagged the exploit live on social channels; whitehats — led by HYDN — began intercepting and front-running attacker transactions mid-event, ultimately rescuing over $600K for return. SushiSwap's response: pull the router from the frontend, publish the incident, and tell every user the one fix that mattered — revoke the approval.
Why this incident is the canonical approval lesson
Every non-custodial venue in this family tells users 'we never hold your funds.' RouteProcessor2 showed the asterisk: your approvals are standing authorization, and the contract holding them only needs to be buggy once. No phishing was involved — users had approved the real, official, promoted contract. The attack surface wasn't a fake SushiSwap; it was the true one. That is what makes it the purest case study in the family:
- The trusted path became the weapon — the official router, approved exactly as designed.
- Exposure = live allowances — no approval, no loss; the blast radius was enumerable on-chain.
- Speed beats treasury — the meaningful rescue was whitehat interception (~$600K+), not a refund program.
Compared to the venue refund playbook
This family has graded the held-key venues' refund records — Banana Gun and Unibot treasury make-wholes, Maestro's CertiK-verified 610 ETH. SushiSwap's was different: there was no blanket treasury refund; victims kept what whitehats couldn't intercept. An honest read isn't 'Sushi is cheap' — it's that approval exploits fragment the loss surface across many wallets and many attackers, making full remediation structurally harder than a single treasury-vs-exploit event.
The risk stack, ranked
| Layer | Frequency | Fix |
|---|---|---|
| Approval-layer contract bugs (RP2-class) | Rare but demonstrated — here | You — approve minimally, revoke stale allowances |
| Signature/approval phishing | Dominant daily vector | You — read every signature |
| Malicious listed tokens | Continuous on a permissionless AMM | You — verify contract addresses |
| Frontend trust | Class-wide | You — verified domain only |
| Core AMM contract drain | None documented | — |
Allowance hygiene as the actual security model
RouteProcessor2 converts 'non-custodial' from a slogan into a discipline. The practical version: every DEX interaction ends with a token approval standing against a named contract — and that approval does not expire when you close the tab. The exposure set at any moment is the union of your live allowances; the RouteProcessor2 victims' mistake was not signing a bad transaction but holding a live allowance to a contract that shipped buggy days earlier. The disciplines that follow are mechanical: approve what the trade needs rather than max, treat any promoted-new-router prompt as fresh trust rather than routine, and revoke allowances to contracts you no longer use — revocation is a one-click transaction and it reduces your drainable surface to whatever you are currently trading. None of this makes SushiSwap uniquely dangerous; it makes the approval model itself the thing being managed, on SushiSwap and everywhere else.
What the incident left behind
The durable artifact of April 2023 is not the loss total — it is the checklist. SushiSwap's own post-incident guidance told users to verify and revoke RouteProcessor2 allowances, and security tooling across the ecosystem treated 'promoted router + fresh approval' as a standing risk class thereafter. For this corpus it becomes the citation for a claim that otherwise sounds paranoid: on a non-custodial DEX, the most dangerous contract is not a fake one — it is a real, official, newly shipped one that everyone was told to approve.
Where SushiSwap stands now
RouteProcessor2 was replaced, the bug is closed, and three years on there's no comparable event. The dated read: a standard-tier DEX whose history includes the family's clearest approval-layer exploit — and whose lesson is the one every DeFi user still needs: your real exposure is the sum of your live approvals, so audit and revoke them like they're open orders.
The verdict in one line: SushiSwap holds nothing — yet users lost millions through a buggy router they were told to approve; it's as safe as the contracts you authorize, which makes allowance hygiene, not venue trust, the actual security model.
Frequently asked questions
Is SushiSwap legitimate?
Yes — SushiSwap is one of the oldest major DEXes (the 2020 Uniswap fork), still operating across many chains. Its defining security event: the April 2023 RouteProcessor2 exploit, an approval-layer bug where the router itself became the drain vector for users who had approved it. Not a fake SushiSwap — the real router contract, doing attacker work.
What happened in the RouteProcessor2 exploit?
On April 8–9, 2023, SushiSwap's new RouteProcessor2 aggregation router shipped with a validation flaw: attacker-supplied parameters let the router make arbitrary calls — including transferFrom — against tokens users had already approved it to spend. Security researchers flagged it live; the most visible drain was ~1,800 WETH (~$3.3M) from a single prominent wallet. Whitehats (led by HYDN) front-ran attacks and rescued over $600K. Sushi pulled the router from the frontend and told users to revoke approvals.
Who actually lost money — and who didn't?
Only users who had approved RouteProcessor2 — it had shipped days earlier and was default in the frontend, so a limited set of active users held live allowances. Sushi liquidity providers and users who never approved the router were untouched. That is the precise mechanism of approval-layer risk: the exposure set is 'everyone who approved this contract', which for a promoted default router is exactly the venue's most active traders.
Did SushiSwap refund the stolen funds?
Partially, through rescue rather than treasury: HYDN-led whitehats intercepted attacker transactions and recovered ~$600K+ for return to victims; Sushi coordinated the whitehat fund return. There was no blanket treasury make-whole as with Banana Gun/Unibot/Maestro — the losses that whitehats couldn't intercept stood. A fair reading: the incident response was fast and honest, but the refund story is 'what the whitehats caught'.
Who holds your keys on SushiSwap?
Nobody — same non-custodial shape as Uniswap: wallet-signed swaps, no deposits, no held keys. RouteProcessor2 showed the subtlety: non-custodial doesn't mean non-exposed. Your approvals are standing authorization, and a promoted router you approved is a trusted path that a fresh bug can turn into a drain — the contract you let spend your tokens only needs to be buggy once.
Is SushiSwap safe to use now?
RouteProcessor2 was replaced and the incident is over; SushiSwap has had no comparable event since. The residual risks are the class-standard ones — signature/approval phishing on clones, malicious listed tokens, and the standing rule this incident proved: your token exposure equals your live approvals. Use verified domains, revoke stale allowances periodically, and its safety profile is standard-DEX-tier with an honest scar.