Most crypto scam advice reads as a list — avoid this, never do that, watch out for X. Lists are fine as far as they go, but they share a structural problem: they're easy to add to and hard to remember.
The underlying patterns are simpler. Once you see them, specific scam variants become obvious applications rather than novel threats you need to memorize one by one.
Crypto scams fall into two broad categories, and they require different defenses.
Technical scams exploit the mechanics of blockchain directly. Token approvals grant access to your wallet; fake contracts look legitimate but aren't; phishing sites capture your seed phrase or get you to sign something malicious. These scams work because blockchain's core design — open, permissionless, irreversible — is also what makes it exploitable. Anyone can deploy a contract. Any approval you sign is binding the moment it executes.
Social engineering scams don't need to compromise your wallet at all. They compromise your judgment first. Investment schemes, impersonation attacks, romance scams, fake giveaways — these work because humans are susceptible to urgency, authority, and social proof regardless of technical sophistication. The most technically literate people in crypto have been social-engineered. The mechanism doesn't care how much you know.
The distinction matters because the defenses are different. For technical scams, you're protecting your signing behavior — what you approve, what you connect to, how you verify contracts. For social engineering, you're protecting your decision-making process — the conditions under which you move money or share information.
The most common technical exposure point is token approvals. When you interact with a DeFi protocol, you typically sign an approval granting the protocol's contract permission to move your tokens. Legitimate protocols need this to process your assets. Malicious contracts exploit the same mechanism.
Approvals persist. One you granted six months ago to a contract you've forgotten about is still active. If that contract is later exploited or was malicious from the start, your exposure exists until you revoke it. The practical defense is periodic review using an approval management tool — Etherscan's token approval checker, Revoke.cash, or similar. The goal isn't zero approvals; it's known approvals tied to protocols you still use.
Approval amounts matter too. Infinite approvals — granting a contract permission to move unlimited amounts — are convenient but widen your exposure. Some protocols set this as the default. You can usually set a custom amount equal to the transaction you're executing. Whether that tradeoff is worth the friction is a judgment call, but you should know you're making it.
Phishing attacks target this approval flow directly. A site that looks like Uniswap or a familiar wallet interface gets you to connect and sign. What you're actually signing may be an approval draining your wallet or a transaction sending funds to an attacker's address. The defense: check the URL carefully before connecting, use bookmarked links for protocols you use regularly, and — this sounds tedious but it matters — read what you're signing. Most wallets now display decoded transaction details. The number of people who've been drained while clicking "confirm" on something they didn't read is not small.
Social engineering in crypto typically uses one of a handful of pressure patterns.
Urgency: "This offer closes in 10 minutes." "You need to act before the snapshot." "Your account will be locked." Real protocols don't require you to move immediately. If something is good, it'll be good in an hour.
Authority and impersonation: Fake accounts impersonating known founders, exchange support teams, or celebrities. The giveaway prompt is almost always involved — "send X, receive 2X back." No legitimate entity in crypto runs this scheme. Ever.
Social proof: Telegram groups where everyone is posting returns. Twitter threads full of accounts confirming gains. Often these are coordinated, sometimes paid, sometimes bots. The appearance of consensus doesn't mean consensus exists.
Fake projects with real infrastructure: A project launches with a real website, a real audit (or a convincing fake one), real social accounts, real liquidity. The mechanism is a rug pull — liquidity is removed, the token collapses, founders disappear. Team anonymity combined with liquidity that isn't actually locked, or vesting schedules with short cliffs, are the leading indicators.
The underlying defense for all of these is the same: slow down. Urgency is the attack vector. Any situation where you're being asked to move quickly, where there's social pressure to act, where pausing feels costly — those are exactly the conditions where pausing is most important.
Blockchain's irreversibility isn't a bug, but it's a constraint that changes the calculus entirely. In traditional finance, disputed transactions can be reversed, fraud can be investigated, chargebacks exist. In crypto: once a transaction is confirmed, it's done. Customer support can't help. The project team can't help. There's no meaningful insurance for most situations.
This means the defense posture has to be front-loaded. Prevention is essentially the only tool you have. Recovery is rare.
Pseudonymity compounds this. Attackers are traceable on-chain — blockchain is public, addresses are visible — but identification is hard, jurisdiction is fragmented, and recovery through legal channels is possible in principle and slow in practice. Exchanges have frozen flagged funds in some cases. Law enforcement has recovered assets in long-horizon investigations. But counting on these as outcomes is not a realistic defense strategy.
Transaction simulation tools are becoming more accessible. Some wallets now show a preview of what a transaction will actually do before you sign it — tokens leaving, tokens arriving, contracts being called. This is genuinely useful because it converts the question from "do I trust this interface?" to "do these specific effects match what I intended?" Wider adoption would meaningfully reduce approval-based losses.
Scam sophistication is also increasing. AI-generated deepfakes of executives, voice cloning for customer support impersonation, increasingly convincing fake project infrastructure. The social engineering layer is getting harder to detect from surface cues alone.
The more durable defense — because surface cues will keep improving on both sides — is behavioral: what are the conditions under which you move funds or share credentials? If those conditions include urgency, social pressure, or authority from an unverified source, that's the exposure point regardless of how convincing the surface looks.
Your posture is adequate if: you know your active approvals and have reviewed them recently; you use bookmarked links for protocols you use regularly; you've established a personal rule about minimum verification before executing any significant transaction; and you can identify which pressure pattern is being used when something feels off.
Supply chain attacks on widely-used infrastructure, client-side compromises that occur without user interaction, entirely novel attack vectors — these exist and don't fit neatly into the technical/social distinction above. They're harder to categorize as "avoidable through individual behavior." Worth knowing about, but they're not where most losses happen.
Now: The most common threats — phishing, malicious approvals, fake projects, investment scheme impersonation — are active and ongoing. The defenses described above apply now.
Next: Pre-transaction simulation becoming standard across major wallets. Worth watching — meaningfully changes the technical layer when widely adopted.
Later: Regulatory frameworks requiring anti-fraud measures from centralized on-ramps and exchanges. Not a solution to DeFi exposure, but potentially reduces the scale of certain scam categories at the fiat-to-crypto entry point.
This covers the framework, not an exhaustive taxonomy. Individual scam types — rug pulls, wallet draining, phishing, flash loan attacks, replay attacks — have their own mechanics explored in separate posts in this series. The goal here was to identify the common denominators so that when something new appears, the underlying pattern is recognizable.




