A Trezor user receives a notification that an airdrop of a new ERC-20 token is available. The offer appears legitimate, includes a contract address, and asks the user to approve a transaction. The user connects their Trezor hardware wallet, sees their Ethereum address displayed correctly on the device screen, approves the transaction, and watches the confirmation appear on the blockchain. Two minutes later, the wallet balance drops by several thousand dollars. The hardware wallet performed exactly as designed—it verified the address, signed the transaction, and prevented malware from stealing the private key. Yet the user lost funds to a token scam anyway. The gap exists not in the device’s security, but in what address verification actually covers.
This scenario reveals a critical distinction between protecting a private key and protecting against transaction approval attacks. Trezor’s offline architecture, transaction signing on the device itself, and screen-based address verification provide genuine protection against certain threats: malware cannot extract keys, phishing cannot trick the device into revealing secrets, and keyloggers cannot compromise signing. But those protections apply specifically to the asset and address directly involved in a transaction, not to the broader consequences of approving a token contract interaction. When a user signs an ERC-20 approval or transfer, Trezor can confirm the Ethereum address is correct; it cannot and does not verify that the underlying transaction is not a scam, that the counterparty is legitimate, or that the token itself has any actual value.
What address verification actually protects
The primary function of Trezor’s screen-based address verification is to prevent a specific attack: malware on the user’s computer attempting to silently redirect funds to a different destination than the one the user intended. When a user initiates a payment, the Trezor device displays the receiving address and amount directly on its own secure screen, isolated from the computer. The user must visually confirm that this address matches their intended destination before physically pressing the device button to sign. If malware has altered the address in the computer’s interface, the mismatch becomes visible, and the user can cancel.
This protection works because it enforces a requirement that the user’s intention (shown on the potentially compromised computer) must match what Trezor displays (from an isolated device). For straightforward payments—moving Bitcoin to a known address, or sending Ethereum native tokens to a verified recipient—the threat model is clear and the control is effective. The hardware wallet cannot be fooled into sending funds to the wrong place because the user performs the final address check on an uncompromised screen before signing.
The protection has a natural boundary, however. Address verification prevents redirecting funds to a different address. It does not prevent the user from approving a transaction that is itself malicious. If the user intends to sign a transaction that transfers all their tokens to an attacker, address verification may confirm that the Ethereum address being used is genuinely their own, but it cannot distinguish between a legitimate token operation and one designed to extract assets. The address is correct. The transaction is legitimate from a cryptographic perspective. The outcome is simply not what the user thought they were approving.
Trezor Suite, the software interface through which users interact with the hardware device, can display additional context—such as warnings about unusual transactions or unfamiliar contracts. However, these warnings depend on what the Suite software knows and chooses to show. If the interface does not recognize a contract as suspicious, or if it displays the contract address but not its actual function, the user may not realize they are approving an unlimited token transfer or a complex smart contract interaction that will drain their balance.
Why ERC-20 approvals create a verification blind spot
The Ethereum token standard (ERC-20) requires a two-step process for many interactions. First, the user must approve a contract or address to spend their tokens up to a specified amount. Second, the contract performs the actual transfer. This design reflects Ethereum’s permissioning model: tokens cannot move automatically; they require explicit approval. In practice, this means that an approval transaction is signed separately from the transfer it enables, often across different blocks and at different times.
When a user signs an approval, Trezor can verify that the approval is being broadcast from their Ethereum address. The device can confirm that the transaction is directed to the token contract address specified in the approval. But the Trezor screen does not typically display what the approved address or contract will actually do with the permission it receives. The user sees something like “Approve 1,000 USDC to 0x1234…”—but may not see that 0x1234 is a malicious contract designed to immediately transfer the entire balance to an attacker. The address verification confirms that the transaction is real and coming from the user’s account. It does not verify the legitimacy or intent of the receiving contract.
More subtly, some approval attacks use unlimited amounts. A user might approve a contract to spend “unlimited” tokens to simplify future interactions, only to have the contract drain the wallet on the first call. Address verification works as intended: the user’s Ethereum address is confirmed, the transaction is signed, and the blockchain shows exactly what was approved. But the user may not have understood the consequence of “unlimited” versus a specific amount, and the hardware wallet’s verification process does not flag this distinction. The signature is cryptographically valid, which is what the device is designed to ensure.
The trust gap between confirmation and comprehension
A common misconception is that if Trezor has signed a transaction and verified an address, the transaction must be safe. This conflates two separate properties: authenticity and safety. A transaction can be cryptographically authentic—truly signed by the user’s key, recorded on the blockchain, and verified to originate from the claimed address—while still being harmful to the user’s interests. Trezor protects authenticity. It does not protect against the user’s own approval of a transaction that turns out to be a scam.
Trezor is designed around offline key storage and transaction signing on the device itself, preventing malware from extracting the key or forging signatures. But these protections work only if the user is aware of what they are signing. If a user reads a phishing email, misunderstands a contract interface, or mistakenly approves a scam token offering, the hardware wallet’s security measures do not prevent the signature. They ensure the signature is real, which is exactly the problem: the attacker receives a legitimate, verified transaction signed by the user’s own key.
This distinction matters operationally. A user who loses private keys to malware has been compromised in an ongoing way—the attacker can continue to sign transactions indefinitely. A user who signed one bad approval has signed only that one bad transaction, but the damage is complete. The difference is not that hardware wallets fail to protect against the second scenario; it is that no device can protect against a user who knowingly or unknowingly approves a malicious transaction. The approval is, from the blockchain’s perspective, exactly what the user signed.
Why transaction decoding in Trezor Suite remains incomplete
Trezor Suite can display transaction details before the user approves them, including the contract address, function name, and parameters. This is valuable context, but its completeness depends on whether the Suite has been updated with the contract’s ABI (Application Binary Interface)—the definition of what functions a contract offers and what parameters they accept. For mainstream contracts like major token exchanges, well-known bridges, and popular DeFi protocols, this information is often available and up-to-date.
For new tokens, lesser-known contracts, or scam projects, the ABI may be unknown to Trezor Suite, resulting in a raw display of the contract interaction. The user sees something like “Interact with 0x5678… with data 0xa9059cbb…” but not what function is actually being called. Even worse, a scam token might publish a false or misleading ABI that makes a draining contract look like a harmless interaction. The user reads “Transfer 100 tokens” when the actual encoded transaction approves unlimited spending or calls a custom function that empties the wallet.
The verification problem compounds with complexity. A simple ERC-20 transfer is relatively transparent. A signature on a DEX swap, a liquidity pool interaction, a contract upgrade, or a bridge operation involves multiple steps and encoded parameters. Trezor can verify that the user’s address is signing, that the transaction is going to the address specified, and that the signature is cryptographically valid. It cannot verify, from a device with limited screen space and no network access, whether the encoded function parameters are safe or whether the contract being interacted with has been updated in a way that changes its behavior.
Real-world consequences of approval scams
The scam workflow typically unfolds as follows. An attacker creates a token contract with a misleading name (such as “Official XYZ Token” when it is not affiliated with XYZ) or launches a phishing website that claims to distribute an airdrop. The user receives a notification or email directing them to connect their wallet and claim the tokens. The user opens Trezor Suite, signs an approval transaction, and sees the transaction confirmed on the blockchain. At this point, the attacker’s contract now has permission to transfer the user’s actual tokens—usually something more valuable than the scam token itself.
The attacker then calls the approved contract, which immediately transfers the user’s real token balance (such as USDC, USDT, or WETH) to the attacker’s wallet. The entire sequence is recorded on the public Ethereum ledger, fully transparent and irreversible. The user’s Trezor device successfully signed both the approval and any subsequent transactions; it worked exactly as designed. The address verification prevented no harm because the user approved a contract they did not understand.
Some variations involve legitimate-looking DeFi protocols that have been compromised or have contained unfixed vulnerabilities. Others use flashloans or sandwich attacks that exploit transaction ordering to steal from the user’s balance mid-transaction. In each case, Trezor’s address verification and offline signing do not prevent the loss because the scam exploit involves the user’s own cryptographic approval. The hardware wallet provides no additional defense beyond what a software wallet would provide: it is the user’s judgment about whether to approve the contract that determines the outcome.
How users can reduce approval scams without relying on address verification
The practical defense requires a shift in user habits rather than additional hardware features. First, never approve unlimited token spending unless there is an explicit operational reason. Many DeFi protocols request unlimited approval for convenience, but the security cost is high: if the contract is later compromised or if the user mistakenly interacts with a malicious contract, the entire balance becomes vulnerable. Approving only the specific amount needed for a transaction requires an extra step but limits exposure to that transaction.
Second, verify contracts before interacting with them using independent sources. If claiming an airdrop, visit the official project website directly (not a link in an email or social media post) and use the address and instructions provided there. Use blockchain explorers such as Etherscan to inspect the contract code and check whether it is verified, whether it has been audited, and whether other users’ recent interactions with it look normal or suspicious. If the transaction encoding is hidden and the contract is unverified, do not approve it.
Third, test with small amounts before large approvals. Approve a test contract with a minimal balance, confirm the behavior in Trezor Suite, and verify that the transaction executed as expected before repeating the operation with a larger amount. If something unexpected happens during the test, the loss is contained. This is slower than a single approval for everything, but it is more reliable for unfamiliar contracts.
Fourth, use separate wallets for different purposes when feasible. A wallet for active trading or DeFi participation may have a lower security stance (more approvals, frequent interactions) because it carries less total value. A wallet holding long-term savings can maintain a stricter approach: fewer approvals, less frequent activity, and higher verification rigor. Trezor supports multiple accounts and can be used in this segregated way.
The wider lesson about hardware wallet guarantees
Trezor’s value is real and substantial for a specific threat model: protecting private keys from compromise, preventing malware from stealing signatures, and ensuring that payments go to the intended address rather than one altered by malicious software. But hardware wallets do not protect users from their own mistakes or from sophisticated attacks that work by requesting legitimate approvals of illegitimate contracts. They do not prevent phishing, they do not decode complex smart contracts, and they do not determine whether a token or DeFi protocol is legitimate.
The boundary between what a hardware wallet secures and what it does not is therefore critical. A user with a Trezor who receives a phishing email and clicks a link has the same vulnerability as a user with a software wallet: they can be socially engineered into approving a malicious contract. The difference is that if the phishing attempt also involved malware designed to steal keys, the Trezor user would be protected while the software wallet user would be compromised. For approval scams specifically, the device provides no additional defense.
Anti-malware protection is essential and valuable. Protecting against a user’s own approval of a scam transaction is fundamentally a problem of judgment, verification, and user education, not of cryptographic security or device design. Trezor Suite can be improved with better contract decoding, warnings about unlimited approvals, and integration with contract reputation databases. But no amount of hardware security can prevent a user who has chosen to approve a malicious contract from successfully sending their tokens to an attacker. The signature is legitimate because it came from the user themselves.
What to examine before approving any Ethereum contract
Before signing any approval on Trezor, the user should adopt a checklist. First, confirm the contract address independently. If claiming an airdrop or using a DeFi protocol, visit the official website directly and compare the contract address shown in Trezor Suite to the one published there. A single character difference in an address can be the only difference between a legitimate contract and a scam replica.
Second, check the contract on a block explorer. Etherscan provides the contract source code (if verified), comments from the community, recent transactions, and any warnings. If the contract is unverified or if recent transactions involve accounts sending tokens to unknown addresses, do not approve it. Third, understand what permission you are granting. “Approve 1,000 USDC to X” is safer than “Approve unlimited USDC to X” because the second permits the contract to take the entire balance, not just what you intended to use.
Fourth, if the transaction is complex or involves an unfamiliar DeFi protocol, approve a tiny amount first and confirm that the transaction behaves as expected before increasing the approval. This is not foolproof, but it catches most cases where the contract does not work as advertised or where the encoding is misleading. Finally, assume that if you do not understand what you are approving, you should not approve it. Trezor’s security comes from you using it carefully, not from the device magically preventing all mistakes.
Frequently asked questions
Does Trezor’s address verification protect me from ERC-20 token scams?
Trezor’s address verification confirms that a transaction is being signed by your account and sent to the address you see on the device screen. For ERC-20 approvals, this means the approval is going to the contract address you approved. However, it does not verify that the contract is legitimate, that an approval is unlimited, or that the contract will use the permission for its intended purpose. Address verification prevents redirect attacks but not scams where you approve a malicious contract yourself.
Why can’t Trezor display what an ERC-20 approval will actually do?
Trezor can only display transaction details if it has the contract’s ABI (Application Binary Interface), which is not always available for new or malicious contracts. Even with the ABI, Trezor has no network access to verify whether a contract has been updated or compromised, or whether the actual function being called will have the effect shown on screen. The device is isolated for security; that isolation limits its ability to decode and verify complex contract behavior in real time.
What’s the best way to approve tokens on Trezor safely?
Verify the contract address independently on the official website or block explorer before approving. Approve only the specific amount you need, not unlimited. For unfamiliar contracts, approve a small test amount first to confirm behavior. Inspect the contract on Etherscan for verification status and recent activity. If you do not understand what you are approving, do not approve it. Trezor’s offline signing makes the signature secure, but only your judgment can determine whether the approval is safe.