What Is Wallet Draining and How Does It Work?

Wallet draining refers to the unauthorized emptying of a crypto wallet — typically through signatures or approvals the wallet owner didn't fully understand they were granting. It's not the same as a direct hack. In most wallet draining cases, the victim technically authorized something. The authorization just wasn't what they thought it was.

This distinction matters because it changes what protection looks like. A drained wallet usually isn't the result of someone "breaking in." It's the result of a signature being weaponized.

The Core Mechanism

The Ethereum token permission model is the foundation of most wallet draining attacks. When you interact with a DeFi protocol, you're often granting that protocol — technically, a smart contract address — the right to transfer tokens from your wallet. That permission is stored on-chain in the token contract itself, not in your wallet software.

Two functions are central to how this works:

approve(spender, amount) grants an ERC-20 contract the right to move a specified number of tokens on your behalf. setApprovalForAll(operator, true) hands over permission to move an entire NFT collection.

A wallet drainer exploits this by getting you to grant approval — or sign a message that functions like approval — to a malicious address instead of a legitimate protocol. The drainer contract then calls transferFrom (for tokens) or safeTransferFrom (for NFTs), moving assets out of your wallet to theirs.

Here's why this works at scale: the blockchain validates the instruction correctly. You signed something. The contract called the function it was authorized to call. From the network's perspective, nothing went wrong.

The Two Primary Attack Paths

Approval-based draining. This is the older method. A phishing site mimics a legitimate protocol — a fake Uniswap, a fraudulent NFT mint, a spoofed airdrop claim — and presents a transaction for you to sign. What looks like "connect and claim" is actually approve(drainer_address, max_uint256), granting unlimited permission to move your tokens. Once approved, the drainer executes transferFrom in a follow-up transaction, moving everything they're entitled to.

Signature-based draining (the modern variant). Signature-based attacks are more dangerous because they don't require the victim to pay gas, and many wallets don't clearly display what's being signed.

EIP-2612 introduced permit() — a way to approve token spending through a signed message rather than an on-chain transaction. This was designed to improve UX. Drainers weaponized it. Instead of asking you to submit a gas-costing approval transaction, they ask you to sign a message. Your wallet shows a wall of hexadecimal or a barely-formatted summary. You sign. The drainer submits the permit, then immediately calls transferFrom.

Seaport — OpenSea's underlying smart contract — introduced a similar vector for NFTs. A signed Seaport order is a valid listing: you agree to sell NFT X for Y ETH. A malicious site gets you to sign an order listing your NFTs for near-zero ETH to an address they control. The drainer fulfills the order. The transaction completes. You received 0.0001 ETH for what was worth considerably more.

What both paths share: the victim technically authorized the action. The attack surface is the signature, not the key.

What Gets Drained and What Doesn't

A wallet drainer can access:

• Any ERC-20 tokens you've previously approved to a contract (existing approvals), or that you approve during the attack
• Any ERC-721 or ERC-1155 NFTs covered by a setApprovalForAll grant
• ETH itself, if the attack tricks you into a direct transfer or a payable contract call
• Anything covered by a permit signature the drainer holds and submits immediately

What a wallet drainer can't do:

• Access tokens you've never approved to any contract and haven't signed anything for
• Touch assets in separate wallets with no connection to the compromised one
• Modify blockchain history or reverse prior transactions
• Drain a wallet where no approvals exist and no signatures have been captured

The scope of what's lost depends entirely on what was authorized — either in the past through standing approvals from previous DeFi interactions, or in the moment through the malicious transaction or signature.

Why Draining Completes So Fast

Speed is a design feature of the attack. Permit signatures often carry an expiry, and even without one, attackers know that time allows victims to notice and revoke. Most wallet draining operations execute the full sequence — verify signature validity, call transferFrom on each asset, route funds to an intermediary — within a single block or a handful of blocks.

The MEV infrastructure that exists to front-run ordinary DeFi transactions gets repurposed here. Some draining operations bundle multiple asset transfers into a single transaction to save gas and minimize the detection window.

This is the critical limit of post-compromise responses: by the time most victims realize something went wrong, the transaction is confirmed and irreversible. There's no customer service call that gets it back.

Where Constraints Live

The core constraint on wallet draining is that it requires victim interaction. You have to sign something. This means the attack surface lives in the UX gap between "what you're shown" and "what you're authorizing."

Wallets that simulate transactions before signing narrow this gap. Hardware wallets create friction that gives users more time to notice something off. But neither fully closes it: simulation can be defeated by contracts that behave differently when observed versus when executed, and friction doesn't help if the victim doesn't know what to look for.

Gas costs on Ethereum mainnet impose a minor constraint on the drainer — they need ETH to submit transactions. On L2s, this is negligible.

What's Changing

Transaction simulation is becoming a default feature across major wallets. Simulation runs the transaction against current chain state before asking for your signature, surfacing what assets will leave your wallet. This catches most approval-based attacks and many permit attacks.

EIP-4337 account abstraction enables spending limits and session keys — mechanisms that would restrict what any contract can do with your wallet regardless of what you've signed. This changes the model from "any signed permission is absolute" to "signed permissions operate within wallet-level guardrails." That shift, if broadly adopted, would make the current drainer toolkit significantly less effective.

Hardware wallet firmware is slowly adding explicit warnings for permit signatures, which previously looked identical to routine unsigned messages.

The core mechanism hasn't changed. The tooling around identifying what you're signing is improving. Whether that's fast enough to stay ahead of attack evolution is genuinely uncertain.

Confirmation and Invalidation

Confirmation that defenses are working: declining wallet draining losses relative to growing DeFi TVL; hardware wallets reaching meaningful market share for DeFi users who also use permit signing; wallets defaulting to simulation with clear, plain-language asset impact summaries.

Invalidation: continued high draining losses despite UX improvements; attackers successfully defeating simulation through deferred execution (contracts that behave safely during simulation but dangerously on actual execution); phishing campaigns pivoting to seed phrase compromise via fake support channels, which bypasses the on-chain mechanism entirely.

Timing

Now: Active risk for anyone interacting with DeFi protocols or NFT platforms. Existing token approvals are standing attack surfaces. Any signature request from an unverified source is a potential attack vector.

Next: Transaction simulation and clearer signing UX reducing the gap between what you see and what you're authorizing. Hardware wallet firmware improvements in progress.

Later: Account abstraction could shift the permission model fundamentally — spending limits and session keys would constrain what a captured signature can actually authorize, independent of what you signed.

Boundary Statement

This post covers the mechanism of wallet draining attacks based on the Ethereum permission model. It doesn't cover private key compromise (which bypasses the approval mechanism entirely), exchange hacks, or SIM-swap attacks — those involve different threat models and different responses.

One thing is clear from the mechanics: a drained wallet can't be restored through any blockchain mechanism. The irreversibility is built into the design. The only practical response to draining risk is pre-event — understanding what you're authorizing before you authorize it.