Why a Hardware Wallet Cannot Stop a Token Approval

A hardware wallet guards one thing, the private key. A token approval is dangerous because, once signed, it no longer needs that key. Figures compiled by DeepStrike put wallet-drainer losses at $494 million across more than 332,000 wallets in 2024, and $83.85 million across 106,106 wallets in 2025. The drainers behind those numbers rarely asked for a seed phrase. They asked for a signature, and a device of any quality will produce one on request.

This matters to anyone who has swapped on a DEX or supplied to a lending market, because both routinely ask for an approval first. The device decides whether the key signs. It has no say over what the resulting permission does afterward, for how long, or for whom.

An ERC-20 approval is a record kept inside the token's own contract. It lets a named spender call transferFrom() and move up to an approved amount of that one token with no further confirmation from the owner, as MetaMask's explainer on token approvals sets out. Most apps request the maximum value, 2^256 minus 1, to spare users a second transaction. The result covers the owner's entire current and future balance of the token, and it never expires on its own.

The owner signs once. Every later withdrawal is initiated by the spender, which means the hardware wallet is never consulted again. If the spender is a router or vault that is later exploited, or a contract that was malicious from the start, the attacker can drain the full approved balance "without any additional user interaction or signature". NFTs work the same way through setApprovalForAll, which drainer kits abuse alongside approve, Permit and Permit2.

Two newer mechanisms move the grant off-chain. An EIP-2612 permit is a signed message containing the owner, spender, value, nonce and deadline. SecureWorld notes that no balance changes when a permit is signed, that an attacker can hold it and submit it weeks later, and that an allowance checker showing a clean record cannot prove an unsubmitted permit does not exist. Permit2, deployed by Uniswap Labs in November 2022, asks users to approve the Permit2 contract once and then authorize individual actions by signature. Those signatures carry deadlines and nonces, which is an improvement. They also appear as generic "sign this message" prompts, which are easier to disguise. By 2025, 3.1 million Ethereum addresses had authorized it.

The device's own screen often makes things worse. Without decoding support, Trezor's guide explains, a hardware wallet shows only a hash or "Data Present", so verification falls back to the browser, the one screen an attacker can control. The gap between the two displays is what separates blind signing from clear signing.

CYFIRMA documented a campaign aimed at Trust Wallet users on BNB Smart Chain. Victims scanned a QR code that led to a cloned "Send USDT" page. The page presented a transfer, but the transaction it built was an approve() granting an attacker's contract a MaxUint256 allowance over their USDT. A Telegram bot reported at least 52 transactions to the operators. The researchers found no bug in the wallet. The approval mechanism did what it was designed to do.

Speed is the second lesson. In one stETH case recorded by security researcher Max Avery, 5 minutes and 24 seconds passed between the approval and the drain. Avery also describes three signers, each holding a hardware wallet, who "produced three valid signatures over a payload their screen never showed them." Owning three devices did not stop the theft.

Law enforcement now treats the approval itself as the vector. Operation Atlantic, led by the U.S. Secret Service with British and Canadian agencies, identified more than 20,000 victim addresses in over 30 countries and froze $12 million that had already left victims' wallets. The Secret Service notes that assets moved under a signed approval are typically unrecoverable.

The sources here contain no post-mortem of a legitimate router or vault being exploited through its users' standing approvals, so this article gives no figure for that route. The mechanism is the same one MetaMask describes. Only the identity of the attacker differs.

The strongest objection is that the industry has addressed this problem. It has made real progress. Trezor rolled out Clear Signing on September 8, 2026, for the Safe 7, Safe 5, Safe 3 and Model T on firmware 2.12.4 or later. It is built on ERC-7730, a standard whose stewardship Ledger handed to the Ethereum Foundation on May 12, 2026. A supported device now decodes the spender, token and amount on its trusted screen. For phishing pages that rely on the display mismatch, this is a genuine defense.

It does not change the conclusion, for three reasons. Coverage depends on a registry: contracts without a published descriptor fall back to blind signing, and Trezor's launch list names 13 providers. Ledger's documentation states that clear signing "never modifies transactions". An unlimited approval to a genuine router, displayed perfectly, is still an unlimited approval. And clear signing applies to the next signature, not to any of the approvals granted before the firmware update.

The practical consequences follow from the mechanism. First, approve the exact amount a transaction needs, not the default maximum. Second, audit standing approvals periodically. Trezor's revocation guide points to Revoke.cash, which has handled more than 20 million revocations for over 2 million users, and block explorers offer their own approval checkers. A revocation is an on-chain transaction. It costs a few dollars on Ethereum mainnet and fractions of a cent on Layer 2 networks, and it stops future transfers without recovering past ones. Permit2 sub-allowances can be cut with lockdown() or invalidateNonces().

For off-chain permits, SecureWorld suggests confirming six fields before signing: action, token, spender, amount, deadline and network. If any of the six is unclear, the safest move is to let the request expire. A separate wallet holding little, used for unfamiliar contracts, limits what any single approval can reach.

When a deposit is at risk, the useful question is not which device signed the approval. It is which contracts still hold one.