Skip to content
Financial Context Wiki

Wallet drainer

A wallet drainer is a phishing workflow that tricks users into signing transfers or reusable permissions. Learn its attack paths, warning signs, limits, and response steps.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A wallet drainer is an attack kit or workflow that presents a deceptive site or application and persuades a user to authorize asset theft. It does not gain control merely because a wallet is connected. A successful drain requires a consequential action: revealing a recovery phrase or private key, sending assets, signing a transaction, or signing a message that grants usable authority.

The requested authority may be a direct transfer, an ERC-20 spending allowance, an ERC-2612 permit, an ERC-721 token approval, or an operator approval such as setApprovalForAll. The attacker can execute immediately or wait until the wallet holds valuable assets. “Drainer” describes the theft workflow, not one contract, signature format, or malware family.

Wallet drainer
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

The lure usually imitates an airdrop, mint, migration, account warning, support page, or familiar decentralized application. After the wallet exposes its public address, the page inventories assets and proposes the most useful request it can obtain.

  • A direct transaction can send native currency or call a malicious contract.
  • ERC-20 approve records an allowance that lets a spender call transferFrom up to the approved amount.
  • ERC-2612 permit creates an ERC-20 allowance from a signature when someone later submits it on-chain. The signer does not have to pay that transaction’s gas.
  • ERC-721 approve authorizes one NFT, while setApprovalForAll authorizes an operator over all of the owner’s NFTs in that collection.
  • EIP-712 makes structured fields displayable and domain-separated, but the standard explicitly does not provide replay protection or prove that the request matches the user’s intent.

The drainer or an accomplice then submits the signed payload or uses the recorded approval, transfers accessible assets, and often swaps or bridges them. Permissions and balances are chain-specific. Disconnecting a site only ends the interface connection; it does not revoke on-chain authority or invalidate every outstanding signature.

Example

A fake mint page asks for setApprovalForAll, although minting should not require the site to operate the user’s existing NFTs. The wallet prompt names an unfamiliar operator. If the user confirms, that operator can transfer NFTs from the collection while the approval remains active.

The same page may request an ERC-2612 permit for an ERC-20 token. Nothing moves when the message is signed, so the victim closes the page and assumes no harm occurred. The attacker later submits the permit and calls transferFrom. Leaving the site did not cancel either permission.

The correct comparison is intent versus authority: chain, verifying contract, function, spender or operator, token address, amount or scope, recipient, nonce, and deadline must all match the action the user meant to take.

Risks and controls

  • Open applications from an independently verified official domain or bookmark; ads, unsolicited messages, QR codes, and support replies are untrusted entry points.
  • Read the wallet prompt and trusted-device display. Reject opaque data, unexpected networks, unfamiliar spenders, unlimited amounts, broad operator rights, and actions unrelated to the stated purpose.
  • Use finite, short-lived permissions where supported. Separate long-term holdings from a wallet used with unfamiliar applications and periodically review approvals on every active chain.
  • Treat simulation and wallet warnings as evidence, not guarantees: state can change, decoding can be incomplete, and a valid contract can still exercise harmful authority.
  • A hardware wallet protects key material but cannot make a malicious request safe if its owner confirms it.

If a recovery phrase or private key was exposed, create a new wallet from a new secret on a trusted device and move remaining assets; revoking approvals cannot repair secret compromise. If only an approval or signature is suspect, inspect the correct chain, revoke relevant allowances or operators through a trusted interface, and move exposed assets when an outstanding signature cannot be reliably invalidated. Revocation is an on-chain transaction and can lose a race to the attacker.

Preserve the domain, messages, signed data, addresses, transaction hashes, and timestamps. Report them to the impersonated service and appropriate authorities. Ignore “recovery” agents who request a secret, another signature, or an upfront fee.

Common misconceptions

  • Connecting a wallet gives the site custody. Connection normally reveals selected public addresses and lets the site propose requests; authorization requires a further action.
  • No gas means no risk. A permit or other off-chain signature can be executed by someone else who pays gas.
  • EIP-712 or a hardware wallet proves safety. They improve visibility and key isolation, not the trustworthiness of the spender, contract, or intent.
  • Disconnecting or revoking one approval ends the incident. Other chains, tokens, operators, signatures, or compromised keys may remain exposed.
  • A successful revoke recovers stolen assets. It limits future use after confirmation; it does not reverse completed transfers.

Sources

Navigation

Search the wiki...