Wallet scams rarely defeat the underlying cryptography. They persuade a legitimate user to reveal a recovery secret, install hostile software, or authorize an action whose meaning is disguised. The attacker succeeds because the wallet treats a valid secret or signature as authority, even when deception produced it.
Visual polish is a weak authenticity signal. Attackers can copy interfaces, buy advertisements, imitate support staff, and create look-alike domains. Durable defense comes from understanding the capability being requested, verifying the source through an independent path, and isolating valuable assets from unfamiliar interactions.
What you will learn
- Classify scams by the authority or information they seek
- Inspect approvals, signatures, destinations, and software sources before acting
- Contain damage quickly when a wallet may be compromised
Recovery-secret and support impersonation
A fake support agent may claim that a wallet needs validation, synchronization, migration, or security repair. The proposed fix leads to a form requesting the seed phrase or private key. Once submitted, the attacker can restore the wallet elsewhere and transfer assets without needing the original device or password.
No legitimate troubleshooting requires disclosing a self-custody recovery phrase to another person. Navigate to documentation from a saved official address, not a direct message or sponsored search result. Support can explain where to click, but the secret must remain under the user's exclusive control throughout the process.
Malicious transactions and token approvals
Some scams do not ask for a seed. A site asks the wallet to approve a token allowance, transfer an asset, change a contract owner, or execute several calls at once. The prompt may be described as login, verification, minting, or claiming even though the encoded action grants valuable authority.
An allowance can let a contract spend tokens later, so no immediate transfer may appear when it is signed. Review the spender, token, amount, chain, and expiration where available. Prefer limited permissions and separate application wallets. Transaction simulation can help reveal effects, but incomplete decoding and changing state make it evidence rather than a guarantee.
Deceptive signatures and fake login
A wallet signature may prove account control, accept terms, authorize an order, or permit a protocol action without immediately creating an onchain transaction. The absence of a network fee does not make it harmless. Structured signature standards can make fields easier to display, but the format does not make the request trustworthy. EIP-712 does not itself provide replay protection, so the application must enforce protections such as suitable nonces and scope.
Treat opaque messages and unexpected signature requests as security-sensitive. Check the requesting domain, account, chain, message text, nonce, expiration, and stated purpose. If the wallet cannot explain the content, stop. A legitimate service should make the authorization understandable enough for a user to distinguish it from a blank check.
Address poisoning, clipboard changes, and fake apps
Address poisoning places look-alike addresses in transaction history, hoping a user copies a previous entry and checks only a few characters. Clipboard malware replaces a copied destination. Counterfeit wallet software may generate attacker-controlled backups or alter transactions. These attacks exploit shortcuts around destination and software verification.
Obtain wallet applications through a known official route and verify signatures or publisher information when supported. Confirm a recipient through a separate trusted channel, compare the full address on the signing device, and use address books carefully. A small test transfer can catch some mistakes but does not prove every future copy is safe.
Containment after a suspicious action
First determine what may be compromised: a website session, one token approval, a device, a private key, or the seed root. Disconnect from the suspicious site, preserve transaction identifiers and screenshots, and use a known-clean device for analysis. Do not follow recovery links sent by people responding to the incident.
If only a token allowance is dangerous, revoke it through a trusted interface, recognizing that an attacker may act first. Moving the affected token can be another option, but transaction order, token behavior, gas, and the attacker's automation make every rescue a race. If a private key or enough recovery material to reconstruct the wallet is exposed, create fresh recovery material on clean equipment and move remaining assets without reusing the secret. Contract positions, staked assets, and nontransferable permissions may require protocol-specific steps.
Common misconceptions
“A professional-looking website with a secure connection symbol is probably legitimate.”
Encryption only protects the connection to that domain. Attackers can obtain certificates and reproduce polished interfaces on deceptive domains.
“A signature is harmless whenever the wallet shows no network fee.”
Offchain signatures can authorize orders, permissions, or later actions. Meaning depends on the signed data, not whether the signature is immediately broadcast.
Risks and limitations
- Seed disclosure gives an attacker broad control that revoking one application approval cannot repair.
- Unlimited token allowances can remain dormant until an attacker chooses to use them.
- Transaction decoding and simulation may omit effects, dependencies, or later state changes.
- Rushed incident response can lead victims into a second scam or expose an unaffected recovery secret.
Key takeaways
- Classify what a prompt can authorize before approving it.
- No genuine support agent needs a self-custody seed phrase.
- A fee-free signature can still grant valuable permission.
- Verify domains, software sources, contracts, and full destinations independently.
- Separate experimental wallets so one deceptive interaction has a limited impact.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.