The thing I keep coming back to about drained wallets is that almost none of them involve a cracked private key. The cryptography holds up fine. What gets people is the layer above it, the part where a human reads a transaction, decides it looks normal, and signs. Every serious loss I have looked at over the past couple of years traces back to a decision that felt reasonable in the moment. The attacker did not break math. They broke the reader.
That reframing matters because it changes what you defend. You cannot out-secure a wallet drainer by choosing a longer seed phrase or a hardware device alone. The attacks target the moment of approval, and the moment of approval happens no matter what hardware you hold. So the useful skill is not paranoia, it is a small set of verification habits that you run before you sign anything. Let me walk through the common patterns and the tell that gives each one away, because once you can name the pattern you stop falling for it.
Address poisoning, the copy-paste trap
Address poisoning is the cheapest attack in the set and it works on muscle memory. Here is the mechanism. You send a payment to some address. Shortly after, an attacker sends a tiny transaction, often a zero-value token transfer or a dust amount, from a wallet whose address looks almost identical to the one you just used. Same first four characters, same last four, garbage in the middle. Now that lookalike address is sitting in your transaction history.
The next time you want to pay that counterparty, you do what most people do. You scroll your history, grab the address that looks right from the ends, copy it, and send. Except you grabbed the attacker's poison entry, and the money is gone. Nothing was hacked. You verified the address the lazy way, by its endpoints, and the attacker engineered an entry that passes the lazy check.
The tell is that the address came out of your own history rather than a source you control. That is the whole trick, it borrows your trust in your own records. The habit that kills it is to never source an address from transaction history. Keep a saved contacts list inside your wallet, or paste from a note you wrote yourself, and verify the full string or at least a middle chunk, not just the ends. If you are moving a meaningful amount, send a small test transfer first and confirm it landed before sending the rest. It is slower. It is also the difference between a five dollar test and a total loss.
Approval and permit phishing, the signature that does the damage
This is the expensive one. Token approvals let a smart contract spend your tokens on your behalf, which is how every DEX and lending protocol works. The problem is that an approval is just a signature, and a malicious site can ask you to sign one that grants an attacker's contract permission to move your entire balance of a token. You do not send funds anywhere. You sign, and later the attacker's contract pulls the tokens out whenever it wants.
The nastier modern version uses gasless signatures, the permit and Permit2 style messages. These do not even show up as an on-chain transaction when you sign them, so there is no gas prompt to make you pause. A fake airdrop page or a spoofed protocol frontend puts up a signing request that reads like harmless boilerplate, and if you sign, you have handed over spending rights. People who would never send funds to a stranger sign these all the time, because a signature does not feel like sending money.
The tell lives in what the wallet is actually asking you to sign. Learn to read the request. If a signing prompt names a token, a spender address you do not recognize, and an amount, especially an unlimited amount, that is an approval, and you should treat it with the same seriousness as sending the full balance. A few habits that hold up:
- Read the spender. If you did not intend to authorize a specific contract, do not sign. Legitimate approvals happen when you initiate a swap or deposit, not when you land on a page.
- Be suspicious of unlimited amounts. Setting a finite approval capped near what you actually need limits the blast radius if the contract turns out to be malicious.
- Treat any signing request that arrives with a fake airdrop, a surprise claim, or an urgent deadline as hostile by default.
- Periodically review and revoke old approvals. Stale unlimited approvals to contracts you no longer use are free money sitting out for anyone who later compromises that contract.
The habit worth building is a mental separation between a transaction that moves value and a signature that grants a permission. Wallets have gotten much better at decoding these prompts into plain language, so read the decoded summary every time instead of clicking through it.
Fake support and the human channel
The social attacks do not touch your keys at all, they get you to touch them. The pattern is consistent. You post a problem somewhere public, or you interact with a project, and someone who looks like official support reaches out. A helpful account in your replies, a message in a project chat, a slick support portal. They walk you toward a page that asks for your seed phrase to "validate" your wallet, or toward a signing request dressed up as a fix.
The tell is the direction of contact and the ask. Real support does not slide into your messages first, and no legitimate service ever needs your seed phrase. None. A seed phrase is the wallet, so anyone asking for it is asking to be you. The rule I hold without exception is that the seed phrase never gets typed into anything except the wallet itself during setup or recovery, and never into a website, a form, a chat, or a support tool. If a flow asks for it, the flow is the attack, full stop.
Blind signing, where hardware wallets stop helping
Blind signing is the trap that catches careful people. A hardware wallet protects your key, but it can only show you what it can decode. When you sign a complex contract interaction, the device often shows an unreadable hash rather than a human summary of what you are approving. You confirm because you trust the site that queued it up, and if that site is malicious or compromised, you just signed something you could not read.
The tell is the request to confirm something your device cannot describe in plain terms. Treat an opaque hash as a stop sign, not a formality. Where the wallet or device supports clear signing that decodes the payload, keep it on and actually read it. For high value actions, slow down and cross-check what the site claims you are doing against what the prompt says you are doing, because that gap is exactly where the loss hides.
The habits that generalize
If you strip these attacks down, they share one requirement. You have to approve something without fully understanding it. So the defense generalizes into a short routine you run before signing anything: know what you are signing and whether it moves value or grants a permission, source addresses from your own saved records rather than history, cap approvals and revoke stale ones, and refuse any flow that wants your seed phrase or arrives with manufactured urgency. Keep a separate wallet with almost nothing in it for connecting to new or sketchy sites, so a bad signature costs you the contents of a throwaway rather than your holdings.
None of this is exotic. It is the on-chain version of reading a contract before you sign it, and it gets faster with practice until the checks are automatic. When I am watching wallet activity for signals on Blockcircle, the losses that show up almost always trace back to a skipped one of these checks rather than anything clever. The attackers are not smarter than the people they drain. They are just betting that the reader will not look, and most of the time the bet pays because looking takes ten extra seconds nobody wants to spend. Spend the ten seconds.