On 19 February 2022, the NFT economy got its comeuppance lesson in signing hygiene. Seventeen users of OpenSea — then the world’s largest NFT marketplace — were induced through a coordinated phishing campaign to sign a malicious WETH (wrapped ether) listing contract pushed via the platform’s own API-matching flow; by the time the dust settled, attackers had walked away with roughly $1.7 million worth of tokens including high-profile pieces from the Bored Ape Yacht Club and Mutant Ape collections. Two details made the incident a permanent fixture in Web3 security canon alongside the era’s misleading early narratives. First, the attack abused the victim’s own hands: every transfer was an authorised signature by the wallet owner, executed through standard marketplace mechanics — no contract exploit, no chain failure, no key theft. Second, the platform’s scale made it systemic: OpenSea’s imminent migration to a new smart contract (Seaport predecessor Wyvern-era systems) gave phishers a perfect pretext — emails and sites mimicking the migration flow harvested signatures at scale in a 12-hour window. The marketplace’s response (compensating victims, redesigning listing flows, and a race to teach users that signatures are blood oaths) set template behaviour for the entire consumer-crypto industry: when your UX makes dangerous signing feel routine, the eventual breach is your product’s fault as much as the phisher’s.
On 2022-02-19, a phishing campaign against OpenSea users induced at least 17 victims to sign a malicious listing transaction (wrapped-ETH priced listing contracts) mimicking OpenSea’s contract-migration flow; the attacker then bought the underpriced “listings” (Bored Apes, Mutant Apes, and other high-value NFTs) and resold for roughly $1.7M total. Mechanics: victims received emails/sites imitating OpenSea’s official communication about migrating listings to a new smart contract; the fake flow requested a signature on a contract partially matching real OpenSea interfaces; once signed, the attacker could fulfil the listing and take possession at attacker-controlled prices. No OpenSea smart contract was exploited; the chain worked exactly as designed — the attack ran on user trust and signature UX. Response: OpenSea confirmed the incident (32 victims per internal review initially reported; 17 confirmed primary), compensated affected users, added listing/anomaly reviews, and later shipped Seaport-era redesigns with clearer signing flows and stronger default protections. Security meaning: (1) transaction-signature phishing is the Web3 password-phishing equivalent and scales via platform-pretext lures (migrations, airdrops, gas claims); (2) marketplaces own the safety of their signing UX — human-readable intent display, listing price sanity checks, and cooldown/allowance design are security features; (3) user education (“read what you sign”) failed at scale, pushing the industry toward wallet-side simulation and blind-signing warnings.
What happened
The setup was ecosystem-perfect. OpenSea dominated NFT trading and had announced migration of on-chain listings to a new smart contract — a rare, urgent, time-boxed action every seller had to take. Phishers built lookalike sites and email templates hijacking that pretext (“migrate your listings or lose them”), and used a partial-contract trick: the malicious contract shared function signatures/interfaces with genuine OpenSea contracts, so victim wallets displayed familiar-looking approval requests.
Attack window: roughly 12 hours starting late on 19 February (UTC). During it, victims signed wrapped-ETH-priced listing offers for valuable NFTs. The attacker(s) — whose wallet addresses were tracked in real time by on-chain sleuths — then completed purchases at the phished floor prices and moved assets to fresh addresses for resale. On-chain analysis tied at least one prominent suspect wallet series together; no prosecution ever materially closed the case.
OpenSea’s public posture moved from initial confusion ( was it an API issue? a contract bug?) to clarity: this was phishing, the platform’s contracts were not exploited, and victims would be made whole — which the company did for confirmed primary victims. The bigger artefact was the industry-wide signing-UX soul-searching that followed: wallet providers added intent-decoder displays, marketplaces added listing provenance checks, and “never sign blind” entered every crypto onboarding checklist that had previously omitted it.
How the attack worked
OpenSea phishing chain (2022-02-19):
PRETEXT
- OpenSea's announced migration of
listings to a new smart contract
- phishing emails / clone sites:
"migrate now or your listings
break"
LURE FLOW
1. victim connects wallet to the
fake site (standard connect -
low alarm)
2. site presents a listing request
whose contract interface mimics
OpenSea's (shared function
selectors; familiar names)
3. wallet shows an approval-ish
signature request that users
had signed hundreds of times
before during normal listing
HARVEST
4. signature captured -> attacker
now holds a valid underpriced
listing authorization
5. attacker fulfils the listing
(buys the Bored Ape for the
fleld-set wrapped-ETH price)
6. assets consolidated -> resale
via fresh wallets; ~$1.7M
realised across 17 victim
accounts
WHY IT WORKED
- legitimate mechanics end-to-end
- no contract exploit to detect
on-chain
- platform migration urgency +
fatigue: users were primed to
sign migration-shaped things
without deep readingImpact and numbers
| Metric | Value | Source |
|---|---|---|
| Attack window | 2022-02-19 (≈12h) | on-chain record/OpenSea |
| Confirmed victims | 17 primary (32 reported in first review) | OpenSea statements |
| Losses | ~US$1.7M in NFTs (BAYC/MAYC + others) | on-chain tracking |
| Mechanism | Phished listing signatures (WETH-priced offers) | on-chain + reporting |
| Contract exploited | None — platform contracts intact | OpenSea confirmation |
| Pretext | Listings migration to new contract | OpenSea communications |
| Restitution | Victims compensated by OpenSea | company statement |
| Follow-on | Signing-UX overhauls across wallets/marketplaces | industry roadmap record |
Timeline
| Date | Event |
|---|---|
| 2022-02-18/19 | OpenSea announces/continues listing migration; phishers launch pretext campaign |
| 2022-02-19 (night) | Signing spree: 17 users sign malicious WETH listings; drain begins |
| 2022-02-20 | On-chain sleuths surface attacker wallets; OpenSea investigates “possibly phishing” |
| 2022-02-21→23 | OpenSea confirms phishing; shares attacker addresses/IOCs; compensation pledged |
| 2022-03→05 | Seaport roadmap; signing-UX warnings; industry-wide listing-safety features |
Why it still matters in 2026
Because signature-social-engineering remains undefeated, and it industrialised. The OpenSea pattern — dangle a platform-shaped pretext, obtain an authorised transaction, harvest — reappears in every subsequent era of consumer crypto losses: the 2023–2025 airdrop scams, fake-mint sites seeded through sponsored search results, and the persistent drain of “approve” permissions granted years earlier by users who forgot what blind-signing costs. Wallets responded with simulation previews and risk-scoring on signature requests (now table stakes), and marketplaces layered provenance and price-anomaly checks — exactly the OpenSea-era checklist matured. Meanwhile the deeper lesson decayed least: legality of mechanics is not safety. Every hop in this attack was a valid transaction the chain validated perfectly; the failure lived in the gulf between what users thought they authorised and what they authorised. Closing that gulf — human-readable intent, spend caps, revocable allowances, cooldowns on dangerous approvals — is permanent product-security work, and the 2026 generation of smart-contract wallets (account abstraction with policy engines) is the furthest extension of the thinking this incident forced. For security practitioners outside crypto, the translation is one-to-one with the enterprise equivalent: OAuth consent screens and API scopes are signatures too, and their UX is your attack surface.
Detection and hardening takeaways
- Assume signatures will be phished; design for it. Listing/approval flows should include price-sanity thresholds, destination checks, and optional cooldowns so a single phished signature cannot drain a vault of assets.
- Make intent legible. Wallet and dapp UIs must decode the transaction’s human meaning (“You are selling X for price Y to address Z — newly created, no history”) before confirmation; the era of hex-first displays ended with incidents exactly like this one.
- Treat platform events as phishing weather. Contract migrations, token airdrops, and deadline-driven actions are attackers’ best pretexts; time-boxed elevation of warnings and comms-channel verification around such events is now standard practice this incident inspired.
- Reduce standing permissions. Old approvals are latent risk: allowance-expiry, per-listing permits (Seaport-style order-scoped signatures came from this lineage of thinking), and periodic revocation hygiene shrink the blast radius of any future phish.
- Monitor marketplace-side anomalies. Sequential underpriced-listing fulfilments, fresh-wallet buying patterns, and signature-origin clustering are detectable centrally — marketplaces that shipped such detections after this incident turned 12-hour sprees into minutes-long ones.
FAQ
Was the OpenSea smart contract hacked?
No. Every transaction executed exactly as the contracts intended: the victims’ wallets signed valid listings, and the attacker validly bought them. The compromise was social — signatures induced under a migration pretext. This is why the incident mattered beyond its $1.7M size: it located the vulnerability in the space between user intent and signed payload, a gap no on-chain mechanism can bridge by itself.
Did victims get refunded?
Yes — OpenSea compensated the confirmed primary victims, positioning the payout as goodwill rather than obligation (the transactions were, technically, authorised). That posture set an industry norm: marketplaces with signing-UX exposure to mass phishing routinely make victims whole when their flows’ usability contributed, and the norm itself is now priced into platform risk models.
Why did wallets show familiar-looking requests?
Because the malicious contract deliberately mimicked OpenSea’s interfaces — matching function selectors and naming — so wallet displays rendered it recognisably. Combined with migration urgency and users’ habituation to signing routine marketplace transactions, the display-level familiarity overcame the scrutiny that a novel request might have received. Wallet-side intent decoding and contract-identity warnings (unverified/new contracts) were the direct UI responses.
