TL;DR

  • ERC-20 tokens let an owner grant a spender contract an allowance via approve(); the spender can then call transferFrom() up to that allowance at any time until it is changed. NFT collections use setApprovalForAll(), which grants an operator control over every token in the collection.
  • EIP-2612 permits and Uniswap's Permit2 create or authorise allowances with an off-chain signature instead of an on-chain transaction. The victim pays no gas, sees no transaction, and the signed message can sit unused until the attacker submits it.
  • Since Pectra activated in May 2025, an ordinary account can delegate its execution to a contract by signing an EIP-7702 authorization tuple, which is then carried in a type-0x04 set-code transaction. Attackers use this both to install sweepers on wallets whose keys already leaked, and to phish intact wallets into signing malicious delegations dressed up as upgrades.
  • A lure delivers traffic to a cloned site; the site fingerprints the connected wallet and generates the highest-value request it can; the victim signs; automated infrastructure extracts and launders. The kit is rented, and the operator pays the developer a commission of the take.
In one block

A wallet drainer is criminal infrastructure, typically rented as a service, that steals through usable authority: a new authorisation the owner is deceived into signing, a signature made with an already-stolen key, or a permission granted long ago to a spender that later turns hostile.

How do token approvals actually work?

Quick answer

ERC-20 tokens let an owner grant a spender contract an allowance via approve(); the spender can then call transferFrom() up to that allowance at any time until it is changed. NFT collections use setApprovalForAll(), which grants an operator control over every token in the collection.

Allowances exist because decentralised exchanges, lending markets and marketplaces need permission to move your tokens as part of a trade you initiate. The mechanism is sound; the risk lives in two properties that users consistently underestimate. First, an allowance persists. It does not expire when you leave the site, close the browser or forget the application existed. Second, an allowance can be unlimited. Many applications historically requested the maximum possible value for convenience, so one approval in 2023 can still authorise a transfer in 2026.

A malicious site exploits exactly this machinery. The claim, verify or migrate button triggers an approve() call with the attacker's contract as spender, or setApprovalForAll() with the attacker as operator. Nothing moves at that moment, which is part of the deception: the wallet may show a harmless-looking permission request rather than a transfer, and the draining transferFrom() arrives minutes or months later, when the balance is worth the gas.

What do permit and Permit2 signatures change?

Quick answer

EIP-2612 permits and Uniswap's Permit2 create or authorise allowances with an off-chain signature instead of an on-chain transaction. The victim pays no gas, sees no transaction, and the signed message can sit unused until the attacker submits it.

Signed permits were designed to improve user experience: one signature replaces a two-step approve-then-act flow, and the application can submit it on your behalf. For attackers the properties are even better. A permit request looks like an inert message signature in many wallet interfaces, historically rendered as hexadecimal or a structured blob that few users could read. Nothing appears on-chain when you sign, so nothing warns you. The attacker submits the permit whenever convenient, then calls transferFrom().

Permit2 generalises the idea across tokens that never implemented EIP-2612, routing allowances through a shared contract. That indirection means a Permit2 signature can govern many tokens through one interface, and drainer kits lean on it heavily. ScamSniffer's 2025 data shows permit-family signatures remained the dominant technique among large thefts, including the year's single biggest at 6.5 million dollars in staked ETH and wrapped BTC from one September signature.

Incident response differs from the approve() case in one crucial way. Revoking an on-chain allowance does nothing to a signed but unsubmitted permit: that signature stays live until its nonce is consumed or its deadline passes. If you may have signed a malicious permit, racing to revoke is not enough; consuming the nonce or moving the assets to a fresh wallet is the reliable end state, and Permit2 provides explicit nonce invalidation for exactly this reason.

How does EIP-7702 change the attack surface?

Quick answer

Since Pectra activated in May 2025, an ordinary account can delegate its execution to a contract by signing an EIP-7702 authorization tuple, which is then carried in a type-0x04 set-code transaction. Attackers use this both to install sweepers on wallets whose keys already leaked, and to phish intact wallets into signing malicious delegations dressed up as upgrades.

EIP-7702 lets an externally owned account behave like a smart contract: batching operations, sponsoring gas, adding programmable logic. Within four weeks of Pectra going live, Wintermute's researchers reported that more than 97 percent of mainnet delegations pointed to a handful of near-identical sweeper contracts, installed on wallets whose private keys had already been stolen. Because the sweepers shared identical bytecode, Wintermute was able to reverse-engineer that code into readable Solidity, inject a plain-language warning that the contract exists to steal any incoming ETH, and publicly verify it so block explorers would flag it; the firm named this defensive intervention CrimeEnjoyor, and its warning now appears inside most of these malicious contracts. The sweeper itself automates what a thief with your key could always do, instantly forwarding anything that arrives. That first pattern is a key-compromise problem wearing new clothes: the delegation is a symptom, and no amount of revoking fixes a leaked key.

The second pattern is the genuinely new one. Drainer campaigns, including the Inferno Drainer operation whose kit remained active even after its operators claimed retirement, present a malicious delegation as a wallet security upgrade or feature enrolment. The victim's key is never stolen. In a case ScamSniffer flagged in May 2025, a wallet lost roughly 146,000 dollars through a batch authorisation executed via a delegated contract; by late that summer a single victim lost 1.54 million dollars to a 7702 batch-transaction phish. Because the delegation persists until changed, an attacker-controlled delegate quietly outlives the phishing session that created it.

Defence therefore has to distinguish the two patterns. Sweeper-after-leak means the key is gone: migrate everything to a freshly generated wallet and abandon the address. Delegation phishing with an intact key means auditing what your account delegates to, clearing or replacing anything you cannot explain, and treating any unsolicited upgrade prompt as hostile. Wallets increasingly display delegation targets; read them the way you would read a recipient address.

wallet drainer approval permit EIP-7702 attack paths and defences diagram.
Figure 1. Three ways a signature hands over spending power, and the remediation that matches each.

What does a drainer campaign look like end to end?

Quick answer

A lure delivers traffic to a cloned site; the site fingerprints the connected wallet and generates the highest-value request it can; the victim signs; automated infrastructure extracts and launders. The kit is rented, and the operator pays the developer a commission of the take.

Many of the attackers who steal with a drainer did not write it themselves. Drainer-as-a-service suppliers provide the signing payloads, the cloned front-ends, the wallet fingerprinting and the extraction automation, typically in exchange for a share of stolen assets. The renter's job is traffic: search adverts impersonating real projects, hijacked project and influencer accounts, replies under genuine support posts, airdrop and mint announcements, and increasingly AI-generated site copy varied across thousands of disposable domains to dodge blocklists.

The request builder is the clever part. After connection reveals the address, the kit inventories tokens, NFTs and balances across chains, then selects the payload with the best expected value: an unlimited approval for the richest token, a Permit2 batch, a marketplace order that sells valuable NFTs for nothing, or a 7702 delegation. High-value wallets can get manual attention from the operator. Extraction is scripted and fast, with proceeds swept through mixers, cross-chain bridges and mule addresses within minutes.

The 2025 numbers show a maturing arms race rather than a victory. Within ScamSniffer's tracked EVM phishing dataset, losses fell 83 percent year on year to 83.85 million dollars, victims fell 68 percent to 106,106, and million-dollar thefts dropped from 30 to 11. Wallet warnings, clearer signing prompts and blocklists earned part of that decline. Part of it is displacement: criminal effort migrated toward infostealer malware, social engineering and supply-chain compromises that drainer statistics never capture. The Bybit theft of February 2025, at roughly 1.5 billion dollars, dwarfed the entire year of signature phishing seventeen times over, and it began by compromising the signing interface a team trusted, which is the same idea aimed at an institution instead of an individual.

Why do simulations and wallet warnings fail?

Quick answer

Simulation previews what a transaction would do at the moment of checking, and drainers exploit the gap between checking and execution, use logic that behaves differently after signing, or route theft through mechanisms simulation does not model, such as off-chain permits and marketplace orders.

Transaction simulation is genuinely useful and genuinely incomplete. Time-of-check to time-of-use gaps let a contract present harmless behaviour in preview and hostile behaviour on-chain, flipped by state the attacker controls. Obfuscated payloads defeat the parser rather than the chain. And whole categories of signature never touch simulation at all: a permit is just a message until the attacker submits it, and a signed marketplace listing looks like commerce, because it is, at a price of zero. Modern kits ship with simulation evasion as a feature, and they A-B test their prompts against popular wallets the way marketers test advertisements.

The engineering conclusion is that previews and warnings are one layer, never the layer. A warning that fires on nine drainers and stays silent on the tenth still loses everything to the tenth if it is your only control.

How do you engineer real defences?

Quick answer

Assume every signature is a live-fire decision. Grant exact allowances, sign on a display you trust, separate wallets by purpose so one signature cannot reach everything, review permissions and delegations on a risk basis, and rehearse the response before you need it.

  • Scope every allowance. Where the application allows it, approve the exact amount for the exact action. Unlimited approvals are a convenience the blockchain never required, and each one is a standing invitation.
  • Make the trusted display the decision point. A hardware or wallet screen that renders the spender, operator, delegate or order in human-readable form is worth more than any browser plugin. If the device cannot tell you what will move, to whom, under what standing authority, decline.
  • Separate custody by blast radius. A long-term wallet signs nothing new, ever. A daily wallet holds working balances. A burner interacts with mints, airdrops and unaudited contracts. The drainer's request builder can only spend what the connected wallet can reach.
  • Review on risk, not on schedule. Audit allowances, operator approvals and 7702 delegations after every new application, after any security incident, and before moving a wallet into cold storage. A calendar habit helps active users, but events should trigger reviews.
  • Control the route in. Bookmarks and typed domains only; treat search adverts, direct messages, QR codes and replies under support posts as hostile by default. The lure is the only step of the kill chain that needs your cooperation twice.
  • Prepare the response. Know your revocation tool, keep a clean device available, and pre-generate an emergency destination wallet whose seed has never touched a computer that browses.

What should you do after signing something malicious?

Quick answer

Diagnose which authority you granted, because each has a different fix: revoke on-chain allowances, invalidate or outrun live permits, clear hostile delegations, and migrate everything if the key itself may be exposed. Speed matters, and so does acting from a clean device.

What you signedCorrect responseCommon mistake
approve() or setApprovalForAll()Revoke that allowance or operator immediately; move the exposed asset if the attacker is faster than youRevoking everything except the one that mattered
EIP-2612 or Permit2 permitConsume or invalidate the nonce where the standard allows it; otherwise move the assets before the permit is submittedAssuming an on-chain revoke kills an off-chain signature
EIP-7702 delegationClear or replace the delegation; if a sweeper is installed, treat the key as compromised and migrateSending fresh funds to the address, straight into the sweeper
Marketplace order or listingCancel the order on the marketplace and revoke its operator approvalWatching the collection instead of cancelling the listing
Anything, from a device you distrustMove to a clean device before touching keys; a hijacked clipboard can redirect your rescue transferPerforming the rescue on the infected machine

Preserve the artefacts while they exist: transaction hashes, the phishing domain, the signature prompt, timestamps. Blockchain forensics has become genuinely effective, and rapid reports give exchanges a chance to freeze funds in flight. And expect the recovery scammers: a fresh drainer victim is the most valuable lead in fraud, and the person who contacts you offering to get it back is almost certainly act two.

Frequently asked questions

Can a wallet be drained just by connecting to a website?

No. Connection exposes your address and lets the site prepare a targeted request, but spending power requires a signed transaction, permit, order or delegation. Every drain has a signature at its centre.

Does revoking approvals protect me from permit-based attacks?

Only partially. Revocation kills existing on-chain allowances, but a signed, unsubmitted permit stays valid until its nonce is consumed or its deadline expires. If a malicious permit may exist, invalidate the nonce where possible or move the assets.

Is EIP-7702 itself a security flaw?

No. The incidents since Pectra were not bugs in the proposal; they were abuse of a legitimate delegation mechanism, either installed by attackers who already held stolen keys or phished from users as fake upgrades. The feature moved the attack surface, and wallet interfaces and habits are catching up.

Do hardware wallets stop drainers?

They reduce remote key-extraction exposure under safe device, firmware and verification assumptions, and a good trusted display defeats payload swapping. They cannot stop an owner approving a malicious request that the display faithfully renders. Clear signing plus a habit of actually reading it is the combination that works.

Why did drainer losses fall so sharply in 2025?

A mix of better wallet warnings, blocklisting, user education and market conditions, minus a measurement caveat: drainer statistics only count what drainer tracking sees. Some criminal effort moved to infostealers, social engineering and supply-chain attacks, which land in different columns.

Sources and further reading

Key references for this article, current as of July 2026. Volatile figures are re-checked at each quarterly review.

Quick quiz: did it stick?

Five questions for the technically minded. Answers below.

1/5 question
What does connecting a wallet to a malicious site give the attacker?

Was this helpful?