NexFlow › Is Uniswap safe
Is Uniswap safe? The unexploited protocol with the most-attacked users
Uniswap is the unexploited pole of this entire safety family — trillions routed, zero contract-level losses, no custody in either direction. And its users get drained constantly, because every real attack lives one layer up: in the signature you sign, the frontend you trust, and the permissionless token you buy. The safest contract ever built cannot save you from an approval you clicked.
What Uniswap is
Uniswap is the largest decentralized exchange in crypto — a set of immutable smart contracts (v2, v3, and now v4 hooks) on Ethereum and its L2s, having routed trillions of dollars with zero contract-level losses of user funds. There is no company wallet, no deposit flow, no held keys: your wallet signs a swap transaction, the contract executes it, custody never leaves you. In this safety family — which has graded custodial bots, MPC wallets, held-key terminals and validator-trust chains — Uniswap is the reference pole: the venue that holds nothing.
And its users get drained constantly. That is the page.
The paradox: unexploited contract, most-attacked users
Split the claim 'is Uniswap safe' into its two halves. The protocol is the most battle-tested code in DeFi — audited, formally verified in places, bounty-backed, and across every market condition for years it has never been drained at the contract layer. The user experience is the single most-phished surface in crypto: everyone wants Uniswap's users, because every Uniswap interaction ends in a signature. The attacks never aimed at the contract — they aim at you, one signature at a time.
Permit2: the signature, not the contract, is the weapon
Uniswap's Permit2 is a shared approval layer: instead of sending an on-chain approve() transaction, you sign an off-chain EIP-712 message authorizing a spender. It saves gas — and it created the dominant modern phishing primitive:
- A cloned 'Uniswap' frontend (ads, SEO-poisoned domains, Discord links) shows a plausible 'Claim UNI', 'Migrate liquidity' or 'Approve' prompt.
- Your wallet displays the real, verified Permit2 contract address — the contract check you were taught to run tells you nothing, because the contract is genuine.
- You sign; the attacker (not you) submits the permit on-chain and pulls your approved tokens — you never sent a transaction, so transaction simulation sees nothing.
- Because Permit2 is a long-lived canonical contract, pre-existing allowances mean one phished signature can expose multiple tokens you approved long ago.
Uniswap Labs' own support documentation says it directly: a Permit2 signature is all that's needed for a spender to move your tokens — verify what you sign. The defense is signature literacy, not contract trust.
The frontend is the trust layer nobody audits
The contracts are trustless; you reach them through app.uniswap.org — a DNS name, a registrar, a hosting/CDN stack, a JavaScript supply chain. A DNS hijack or a poisoned mirror presents a pixel-perfect UI that routes approvals to attacker contracts. The March 2021 GoDaddy hijacks proved the class is real (PancakeSwap and Cream lost their domains the same night); Uniswap is the biggest target of the same pattern, and its users are drilled to click 'Sign'. The contract cannot protect the layer that delivers it to you.
Tokens, MEV, and the residue
Two more honest entries. Permissionless listing means anyone can deploy any token and any name — honeypots, look-alike tickers, and fake blue-chips are endemic on Uniswap's surface; the venue is neutral about what it routes, so vetting the token is entirely your job. MEV means your public mempool swap can be sandwiched — a real cost, not a custody loss; protected routing (UniswapX/private lanes) mitigates it. Both are categorically smaller than the signature problem but bigger than the contract problem.
The risk stack, ranked by actual losses
| Layer | Real-world frequency | Fix |
|---|---|---|
| Signature phishing (Permit2 / approve) | The dominant daily loss vector | You — read every signature's spender, scope and expiry |
| Malicious tokens | Endemic on permissionless listing | You — verify the contract address, not the ticker |
| Frontend/DNS compromise | Rare but demonstrated class-wide | You — bookmark the domain, distrust ads/short links |
| MEV extraction | Continuous, small per trade | Protected routing; sane slippage |
| Contract exploit | Zero documented user-fund losses to date | — |
What would change the answer
Uniswap's picture changes only at the extremes: a v4 hook-era contract incident (the new extensibility surface is the freshest code), or a major frontend compromise at scale. Neither has happened. The dated read: the safest venue in this corpus at the contract layer and the most-phished at the user layer — the two facts coexist and the second one is what actually costs people money.
The verdict in one line: Uniswap is the category's cleanest custody answer — it holds nothing — and its users are the category's most-phished, because every attack moved up one layer to the signatures the wallet asks for; it is as safe as your ability to read what you sign.
Frequently asked questions
Is Uniswap a legitimate exchange?
Yes — Uniswap is the largest and oldest major DEX, a set of immutable smart contracts (v2, v3, v4) that has processed trillions in volume with no contract-level exploit ever losing user funds. It is arguably the most battle-tested piece of DeFi software in existence. The paradox this page exists for: the safest contract in the corpus sits in front of the most-attacked user base — because the attacks were never aimed at the contract.
Has Uniswap ever been hacked?
The protocol contracts — no. Uniswap v2/v3 have never suffered a core exploit draining liquidity or wallets, across years and trillions of dollars. What does get 'hacked' is everything around the contracts: phishing frontends imitating app.uniswap.org, DNS/mirror attacks, Permit2 signature scams, and fake-token rugs on the permissionless listing surface. 'Uniswap is safe' is true about the contract and dangerously incomplete about the experience.
What is the Permit2 phishing attack?
Uniswap's Permit2 contract lets you authorize token spends by signing an off-chain message instead of sending a transaction. Attackers phish that signature: a cloned site shows a real-looking 'Claim'/'Migrate'/'Approve' request, your wallet displays the genuine Permit2 contract — so the address check tells you nothing — and the signed message lets the attacker transfer your approved tokens on-chain without you ever sending a transaction. It is the signature, not the contract, that is the weapon — and existing Permit2 allowances can expose multiple tokens at once.
Who holds your keys on Uniswap?
Nobody — Uniswap has no custody at all, in either direction: it holds no keys and holds no funds. Your wallet signs swaps directly against immutable contracts; there is no account, no deposit, no held-key pool, no company-operated balance to drain. The only things you ever give are approvals and signatures — which is exactly where every real Uniswap-area attack lives.
What are the real risks of using Uniswap?
Ranked by actual losses: (1) signature/approval phishing — Permit2 and approve() scams via cloned or hijacked frontends; (2) malicious tokens — anyone can list anything on a permissionless DEX; honeypots and look-alike tickers are endemic; (3) MEV — sandwich extraction on your swaps (partially mitigated by UniswapX/protected routing); (4) frontend trust — the contracts are trustless, but you reach them through a DNS/hosting layer that can be pointed at a clone. Contract risk itself is last.
Is Uniswap safer than a Solana trading bot?
Categorically — and it is the cleanest contrast in this corpus. A TG bot holds your key; Uniswap holds nothing and cannot lose it. But the protection is asymmetric: Uniswap eliminates the custodian while leaving you fully responsible for every signature you give. A bot can drain you without asking again; on Uniswap, the only path to your funds is a signature you sign — so the entire security model reduces to never signing what you have not read.