Under the Hood: 27 Crypto Scams and How to Avoid Them

Cryptocurrency scams usually exploit trust, account access, or transaction permissions, not a broken blockchain.

That distinction is where I start.

After 25 years in traditional finance, I’m less interested in whether an investment dashboard looks sophisticated than in three practical questions: Who controls the money? What exactly am I authorizing? And what happens if the person on the other side is lying?

Crypto makes those questions especially important.

If an attacker steals your recovery phrase, persuades you to authorize a malicious spender, or convinces you to send funds to the wrong address, the underlying protocol may work perfectly. The signature is valid. The transaction executes correctly. The attacker gets paid.

A technically successful transaction can still be a financial disaster.

This guide breaks down 27 cryptocurrency scam patterns, starting with investment fraud and moving into wallet permissions, malicious contracts, account takeovers, malware, marketplace orders, and newer account-delegation risks.

For each one, I explain the psychological hook, what happens under the hood, how it compares with traditional financial fraud, and the defenses that matter at the moment of decision.

These are practical threat-model categories, not an official statistical classification. Criminal campaigns often combine them. A relationship scam can lead to a fake exchange, followed by a malicious wallet signature and then a recovery scam.

One more distinction matters: complaint statistics and blockchain analytics measure different things. The Chainalysis explanation of its illicit-activity methodology describes estimates based on identified addresses and other attribution work, with figures revised as more information becomes available. Those estimates are not interchangeable with losses people report to the FBI.

I would rather explain precisely how money leaves an account than blur several different datasets into one frightening headline.

How Most Crypto Scams Work

Most crypto scams move the victim through the same sequence: establish trust, obtain money or authority, and make the loss difficult to reverse.

The branding changes. The workflow is remarkably consistent.

1. An attacker finds someone through an advertisement, social platform, dating app, job offer, search result, or compromised account.
2. The attacker builds credibility using apparent expertise, borrowed authority, fabricated testimonials, or a small initial payout.
3. The victim buys cryptocurrency through a legitimate exchange or funds an existing wallet.
4. The attacker directs the money toward a fraudulent platform, attacker-controlled address, or malicious contract.
5. An interface displays invented profits, rewards, eligibility, or security warnings.
6. The victim is asked for another payment, a signature, a recovery phrase, or broader account access.
7. Withdrawals become conditional on a supposed tax, verification charge, security deposit, or additional task.
8. Once the victim stops cooperating, the account or communication channel disappears.
9. A supposed recovery specialist may then offer to fix the damage for another fee.

This sequence is more useful than a blacklist of suspicious domains. A domain can disappear overnight. The mechanism survives.

The FTC’s explanation of cryptocurrency scams and payment risks makes the central financial point: crypto payments generally do not provide the same dispute protections people expect from credit cards and other familiar payment methods.

That does not mean every bank transfer is reversible. ACH transfers, card payments, and Fedwire transfers have different rules. An authorized wire sent to a scammer can also be very difficult to recover.

The important difference is that a public blockchain generally has no universal customer-service department that can cancel a valid, confirmed payment.

Know What Your Wallet Is Asking You to Do

Connecting, signing, approving, and sending are different operations. A safe interface should not blur them together.

Wallet action	What it usually does	Main risk to understand
Connect a wallet	Shares selected public addresses and establishes a session	Reveals account information and enables later requests; ordinarily does not itself authorize spending
Sign a login message	Authenticates control of an address when properly designed	A misleading message may instead represent an order or financial authorization
Approve an ERC-20 spender	Sets a spending limit for one token and spender	The spender can later transfer that token within the allowance
Sign a permit	Creates a signature that can authorize token spending when submitted	No gas payment from you does not mean no financial consequences
Approve an NFT operator	Authorizes an operator for NFTs in a particular collection	The operator may transfer current and future NFTs in that collection
Sign a marketplace order	Authorizes a trade under specified terms	Another party may execute the order later
Install a wallet module or delegate account execution	Changes account-level execution authority	The consequences may extend beyond a single token
Send cryptocurrency	Authorizes a transfer or contract interaction	A valid transaction may settle without a general chargeback mechanism

I keep these distinctions in mind throughout the 27 scams below.

1. Fake Cryptocurrency Investment Platforms and Broker Call Centers

A fake crypto investment platform uses fabricated account balances to persuade people to deposit real money.

The opening pitch usually promises automated trading, institutional access, an exclusive investment program, or an unusually successful “AI trading system.”

The first request may not be a payment. It may be your name and phone number.

A supposed broker, account manager, or investment adviser then calls. The initial deposit is deliberately manageable, perhaps USD 250. Soon, the dashboard shows profitable trades. The account manager explains that a larger deposit would unlock better results.

The platform does not need to execute a single real trade.

Under the Hood

A convincing fraudulent platform can be built with:

• A registration and deposit form.
• A database containing customer records.
• A table of generated trades.
• A chart fed by invented or selectively presented data.
• An administrator panel that changes displayed balances.
• A mechanism for approving a small test withdrawal.
• A chat or telephone operation that pressures users to deposit again.

The victim sees a rising number and assumes an actual market position exists behind it.

That assumption may be completely wrong.

The California DFPI Crypto Scam Tracker contains consumer complaint narratives describing this pattern, including early withdrawals followed by demands for additional payments. The tracker also explains an important limitation: reported losses and narratives are not all independently verified by the department.

A small successful withdrawal is therefore evidence that someone authorized a small payment, not proof of solvency, legitimate trading, or honest management.

Banking comparison: This resembles a fraudulent brokerage statement or a fake online banking portal. The interface displays an accounting claim. It is not independent evidence that the claimed assets exist.

Red Flags and Defenses

If someone claims to be a registered broker or investment adviser, check the SEC’s investor verification resources and the FINRA BrokerCheck registration database independently.

Then check whether the caller actually belongs to that firm. Impersonators routinely borrow real registration details.

I would also ask:

• Does the domain match the independently verified company?
• Does the payment recipient match the entity offering the service?
• Are deposits and withdrawals supported by verifiable records?
• Can I withdraw without negotiating with a broker?
• Is remote-access software being requested?
• Am I being asked to send new money to release existing money?

A genuine centralized exchange may execute trades internally without producing an individual blockchain transaction for every trade. Missing trade-level transaction hashes are not, by themselves, proof of fraud.

On-chain deposits and withdrawals, however, should be checkable on the correct network.

A demand to send additional cryptocurrency to an outside “tax,” “compliance,” or “release” wallet is a much stronger warning.

Legitimate network costs and withdrawal fees should be disclosed and explainable. They should not become an endlessly changing ransom for access to your balance.

2. Telegram and WhatsApp Task Scams

A task scam pretends to pay people for simple online work, then requires them to deposit their own money to continue or withdraw.

The advertised work may involve liking videos, rating products, “optimizing” listings, or completing repetitive app-based tasks.

An early payment may actually arrive.

I would not treat that payment as proof of a real business. It can simply be the scammer’s customer-acquisition expense.

The FTC’s explanation of task scams describes the familiar sequence: an unexpected job message, simple tasks, an increasing earnings display, and a request to deposit cryptocurrency to unlock more work or withdraw supposed earnings.

Under the Hood

The application often has no connection to a legitimate employer’s revenue or payment system.

Instead:

1. An operator assigns tasks.
2. The application increases a fictional commission balance.
3. A “premium,” “combination,” or “negative balance” task appears.
4. The user must deposit money to complete it.
5. A new obstacle prevents withdrawal.
6. Another deposit is required.

The changing balance may be entirely administrative.

Technical warning signs include:

• Task status controlled by an administrator.
• No verifiable commercial client.
• No exportable account history.
• Deposits required to unlock additional work.
• Multiple users instructed to pay the same address or related collection addresses.
• Earned commissions mixed with deposited funds.
• Communication moved into private groups populated by supposed successful workers.

The psychological mechanism is a combination of sunk-cost pressure and apparent progress. The victim does not feel like they are making a new investment. They feel like they are finishing a job already underway.

Banking comparison: This is an advance-fee employment scam wrapped in a gamified interface. A legitimate payroll system pays workers. It does not normally require workers to buy access to their wages.

Red Flags and Defenses

My rule is straightforward: Do not deposit cryptocurrency to unlock employment income.

A generic unsolicited WhatsApp message is not a complete hiring process, regardless of how professional the application looks.

For developers building legitimate rewards or marketplace systems, the defensive controls are equally practical:

• Separate deposits from earned balances.
• Keep an audit record of every manual balance adjustment.
• Limit rewards for newly created accounts.
• Investigate suspicious clusters of devices, accounts, or funding sources.
• Use proportionate payout holds when activity changes abruptly.
• Never design a workflow that requires payment to receive ordinary earned compensation.

Those controls need privacy safeguards and false-positive review. Shared devices or funding sources can have legitimate explanations.

The essential question is not whether the application displays earnings. It is which verifiable business event created them.

3. Pig Butchering and Relationship-Investment Scams

A relationship-investment scam builds personal trust first and introduces the fraudulent investment later.

The term “pig butchering,” also called sha zhu pan, remains common. I prefer “relationship-investment fraud” because it describes the mechanism without dehumanizing the victim.

The first contact may be a wrong-number text, a dating profile, a LinkedIn message, or a friendly conversation in an investment group.

The attacker may spend weeks discussing work, family, meals, or travel before mentioning a successful trading strategy.

The investment recommendation arrives after the relationship feels established.

Under the Hood

The FBI’s cryptocurrency fraud report describing confidence-enabled investment fraud explains how personal confidence can become the entry point for fraudulent crypto investments.

The financial backend often resembles scam number one. The distinctive mechanism is the trusted relationship that delivers the victim to it.

A typical flow looks like this:

1. A contact develops emotional credibility.
2. They casually display apparent trading success.
3. They recommend a particular platform or “mentor.”
4. The victim purchases crypto through a legitimate exchange.
5. The victim transfers it to the recommended destination.
6. A small withdrawal reinforces trust.
7. Larger deposits follow.
8. Withdrawal demands trigger taxes, penalties, or security charges.

The contact may even claim to contribute their own money. A dashboard entry showing that contribution proves very little if the dashboard is controlled by the same operation.

Why KYC Does Not Solve the Problem

Know-your-customer checks identify an account holder. They do not establish whether that person is acting under manipulation.

The victim may:

• Use their own device.
• Pass identity verification.
• Purchase cryptocurrency with their own money.
• Enter the destination address themselves.
• Sign the transaction with their own key.

Everything can look technically authorized.

Banking comparison: This is authorized push-payment fraud. The problem is not necessarily a stolen identity or forged instruction. It is a genuine customer acting on a false story.

Red Flags and Defenses

I would pay attention to combinations of signals:

• A new recipient and an unusually large withdrawal.
• A first crypto purchase followed by an immediate full-balance transfer.
• A mentor who insists on one obscure platform.
• Pressure to borrow, liquidate retirement assets, or keep the opportunity secret.
• A supposed tax that must be paid to a cryptocurrency address before withdrawal.
• Resistance to independent verification.

No single behavioral signal proves fraud. A new address and a large payment can be legitimate.

A specific warning is more useful than “crypto is risky”:

If someone you met online selected this platform or address for you, verify it independently before sending. A successful small withdrawal does not establish that the platform is legitimate.

If you suspect someone close to you is being targeted, approach the conversation without ridicule. Shame makes isolation easier for the attacker.

4. Fake Support and Recovery-Phrase Theft

Fake support scams steal the secret that controls a self-custody wallet, usually by pretending that a technical problem requires “verification” or “synchronization.”

A user asks a public question: “Why is my transaction stuck?”

Minutes later, a branded account offers help.

The supposed agent sends a form asking for a recovery phrase, private key, screen-sharing session, or remote access.

That is not ordinary troubleshooting.

Under the Hood

For many wallets, a recovery phrase is an input used to derive the cryptographic material controlling the wallet’s accounts.

The BIP39 specification for mnemonic recovery phrases describes how a mnemonic and optional passphrase are converted into a seed. Wallet systems then derive keys from that seed.

A recovery phrase is not simply a website password that support can reset.

An attacker who obtains sufficient recovery material can recreate the relevant wallet and sign transactions elsewhere.

The MetaMask explanation of its official support channels explicitly warns that support will never ask for the Secret Recovery Phrase. It also explains which communication channels the company actually uses.

The psychological hook is relief. The victim has a problem, and someone appears to solve it immediately.

Banking comparison: This is closer to handing over the authority to sign payments than disclosing an account number. Changing the local wallet password does not invalidate keys the attacker has already reconstructed.

Why Counting Words Is Not Enough

A support form might attempt to detect 12-word or 24-word sequences. That can reduce accidental disclosure, but it is not a complete security control.

Problems include:

• An ordinary sentence can contain 12 words.
• BIP39 supports more lengths than just 12 and 24.
• Other recovery systems use different structures.
• An attacker can request one word at a time.
• A victim can upload a screenshot.
• The phrase can be split across messages.

For product teams, safer controls include:

• Warnings next to support input fields.
• Local detection before sensitive material is transmitted.
• Masking suspicious content.
• Preventing secret material from entering logs and analytics.
• Training agents never to request recovery material.
• Eliminating any internal support workflow that depends on a customer’s private key.

Do not turn seed-phrase detection into a new system for collecting seed phrases.

Red Flags and Defenses

Initiate support through a verified application or independently opened official support page.

Never enter a hardware wallet’s recovery phrase into a website or ordinary desktop application.

If recovery material has been exposed, changing a password is not enough. Create a genuinely new wallet on a clean device and move remaining assets where feasible.

A new account derived from the same compromised recovery phrase is not a fresh security boundary.

5. Wallet Drainers, Approval Phishing, Ice Phishing, and Permit Signatures

Approval phishing tricks a wallet owner into granting spending authority instead of directly stealing a private key.

“Ice phishing” describes this same broad authorization-abuse pattern. It should not be counted as an entirely separate mechanism simply because it has a different name.

The bait may be a reward, a mint, an eligibility check, a migration, or a routine-looking transaction on a compromised website.

The important question is what authority the request creates.

Under the Hood: ERC-20 Approvals

The ERC-20 token standard defines the basic spending relationship:

• approve(spender, value) sets an allowance.
• allowance(owner, spender) reports the remaining amount.
• transferFrom(from, to, value) transfers tokens using available authorization.

The spender may be a contract or another address.

An approval for one ERC-20 token does not automatically grant access to every asset in the wallet. But it can expose the approved token’s current balance and future deposits, within the allowance.

An effectively unlimited approval, often represented by the maximum uint256 value, increases the possible loss.

Closing a browser tab, disconnecting WalletConnect, or removing a site from a wallet’s connection list does not erase an on-chain allowance.

The Ethereum guide to revoking token access explains that distinction and the transactions required to cancel spending permissions.

Microsoft’s technical analysis of ice phishing on the blockchain also shows why a genuine website address is not a complete defense: a compromised frontend can insert malicious approval requests into an otherwise familiar workflow.

Under the Hood: EIP-712 and EIP-2612

The EIP-712 structured-data signing specification makes signed data more structured and potentially more readable.

It does not make every structured signature safe. It also does not, by itself, provide application-level replay protection.

The EIP-2612 permit specification allows supported tokens to change an allowance using an owner’s signature.

A simplified attack flow is:

1. A website requests a signature described as verification.
2. The actual payload authorizes a spender.
3. The attacker submits the signature to the token contract.
4. The contract validates it and updates the allowance.
5. The authorized spender transfers tokens.

The attacker or another relayer can pay the submission gas.

“No gas fee” is not the same as “no financial authorization.”

Here is an illustrative typed-data request. The addresses are placeholders, not recommended contracts or recipients.

{
  "types": {
    "EIP712Domain": [
      { "name": "name", "type": "string" },
      { "name": "version", "type": "string" },
      { "name": "chainId", "type": "uint256" },
      { "name": "verifyingContract", "type": "address" }
    ],
    "Permit": [
      { "name": "owner", "type": "address" },
      { "name": "spender", "type": "address" },
      { "name": "value", "type": "uint256" },
      { "name": "nonce", "type": "uint256" },
      { "name": "deadline", "type": "uint256" }
    ]
  },
  "primaryType": "Permit",
  "domain": {
    "name": "Example USD Token",
    "version": "1",
    "chainId": 1,
    "verifyingContract": "0x1111111111111111111111111111111111111111"
  },
  "message": {
    "owner": "0x2222222222222222222222222222222222222222",
    "spender": "0x3333333333333333333333333333333333333333",
    "value": "1000000000",
    "nonce": "7",
    "deadline": "1893456000"
  }
}

If this illustrative token has six decimals, the value represents 1,000 tokens.

Three details matter:

• verifyingContract identifies the token contract validating this permit, not necessarily the spender.
• nonce prevents reuse after the permit is consumed under the token’s rules.
• deadline limits when the permit can be submitted. It does not automatically make the resulting standard ERC-20 allowance expire.

Also, an EIP-712 domain is not automatically proof that the website requesting the signature is genuine.

Permit2 Adds Another Authorization Layer

The Uniswap explanation of Permit2 permissions distinguishes standing, time-limited allowances from one-time signature-based transfers.

Permit2 requires an underlying ERC-20 approval to the Permit2 contract before it can move that token.

That means a user may have two relevant layers to inspect:

1. The token’s allowance to Permit2.
2. The permissions or signatures used within Permit2.

A familiar, legitimate verifying contract does not make every spender or signed request legitimate.

Banking comparison: An approval resembles a payment mandate. The scammer is not necessarily forging your signature. They are obtaining a real authorization under false pretenses.

Red Flags and Defenses

Before approving or signing, identify:

• The network.
• The token contract.
• The spender.
• The amount.
• Any expiration or submission deadline.
• Whether the action moves assets now or enables later movement.
• Whether an NFT operator approval covers an entire collection.

For developers, translate these fields into consequences:

This address will be allowed to transfer up to 1,000 of this token from your wallet.

For technical readers using Foundry, this read-only command checks a standard allowance through a trusted RPC endpoint:

cast call "$TOKEN_ADDRESS" \
  "allowance(address,address)(uint256)" \
  "$OWNER_ADDRESS" \
  "$SPENDER_ADDRESS" \
  --rpc-url "$TRUSTED_RPC_URL"

It does not revoke anything or require a private key.

Finally, an unsubmitted malicious permit may not appear in an ordinary allowance list. Setting a current allowance to zero may not invalidate a still-valid unused permit. Use the token’s or permission system’s supported invalidation process, or move exposed assets to a fresh address when appropriate.

6. Address Poisoning and Vanity-Address Spoofing

Address poisoning contaminates transaction history with a look-alike address, hoping the victim will copy it into a later payment.

The attacker does not need your private key.

They need you to trust a shortened address display.

Suppose the recipient you intend to use appears as:

0x12a4...91bf

An attacker creates a different address that also appears as:

0x12a4...91bf

The omitted characters are where the difference lives.

Address role	Illustrative full address
Intended recipient	0x12a41111222233334444555566667777888891bf
Attacker-controlled look-alike	0x12a49999888877776666555544443333222291bf

These are illustrative addresses, not payment instructions.

Under the Hood

The attacker monitors public activity and generates an address sharing a recognizable prefix, suffix, or both.

They then create a history entry using a tiny payment, a zero-value transfer, or misleading token activity.

The MetaMask explanation of address-poisoning scams describes how this exploits the habit of copying addresses from transaction history.

An additional complication is that a malicious token can emit misleading transfer events. A displayed token-history entry is not always evidence that the apparent sender personally signed a transaction.

Banking comparison: Think of an altered beneficiary record or a fraudulent invoice with an account number that looks familiar. The failure occurs in recipient selection, not in the payment system’s cryptography.

Red Flags and Defenses

I use verified address-book entries rather than transaction history as my source of payment instructions.

Useful controls include:

• Showing the full address during verification.
• Confirming recipients through an independent channel.
• Warning when a new address resembles a trusted recipient.
• Clearly separating spam and zero-value activity.
• Requiring extra confirmation for newly added high-value recipients.
• Verifying the address on a hardware wallet’s trusted display.

A test transaction can help confirm a destination, but it is not a substitute for checking that the larger payment uses the same independently verified address. Malware can change a later paste.

Similarity scoring is useful for warnings, not a universal verdict. Legitimate addresses can share characters by chance, while attackers deliberately engineer those similarities.

7. Counterfeit Tokens, Fake Airdrops, and Pump-and-Dump Groups

A token’s name, symbol, logo, displayed balance, and price chart do not establish that it is legitimate.

I treat these as three related token-market deceptions: counterfeit identity, reward bait, and manufactured demand.

They often appear together, but their mechanics are worth separating.

Counterfeit Token Identity

Anyone deploying a token contract can generally choose familiar-looking names and symbols.

A token called USDT is not necessarily the USDT contract you intended to use. The network and contract address matter.

The Ethereum guide to identifying scam tokens explains several deceptive techniques:

• Copying a legitimate token’s name and symbol.
• Assigning balances to recognizable addresses.
• Sending tokens to well-known holders without their consent.
• Emitting transfer events that create an appearance of activity.

A famous address holding a token does not prove that its owner bought, endorsed, or even noticed it.

A malicious contract controls its own token accounting and event output.

Fake Airdrops as a Drainer Entry Point

An unfamiliar token or NFT appearing in a wallet does not ordinarily give its creator access to the wallet’s other assets.

The danger usually begins with the next action:

1. The user notices an unexpected asset.
2. Its name or metadata advertises a claim or redemption website.
3. The website promises value.
4. The user connects a wallet and receives an approval or signature request.
5. The attacker obtains spending authority or an advance payment.

The receiving event and the harmful authorization are different steps.

A wallet should not automatically treat every unsolicited token as valuable, nor should it turn untrusted metadata into prominent clickable instructions.

Pump-and-Dump Mechanics

A pump group uses a different deception: organizers buy before the public “signal.”

The sequence is simple:

1. Insiders accumulate a thinly traded token.
2. A group announces a coordinated buying opportunity.
3. Members purchase simultaneously.
4. The price rises because the group is buying.
5. Insiders sell into that demand.
6. Late participants are left with poor liquidity and falling prices.

The signal appears correct because participants themselves caused the price movement.

They were not early investors. They were exit liquidity.

Banking comparison: Counterfeit tokens resemble counterfeit financial instruments. Pump groups resemble traditional market-manipulation schemes. A real trading venue does not make every listed or tradable asset honest.

Red Flags and Defenses

Before buying, inspect:

• The correct contract address on the correct network.
• Where that address is independently documented.
• Liquidity depth, not just a displayed price.
• Expected price impact.
• Whether ordinary holders can actually sell.
• Contract age and upgradeability.
• Owner, administrator, minting, pausing, and fee-setting powers.
• Holder concentration, with care for exchange, bridge, and custody addresses.
• Whether volume appears dominated by related accounts.

A market-cap display is not cash available for sellers. A tiny trade can establish a dramatic quoted price in a shallow pool.

Hide unsolicited assets rather than visiting their advertised websites.

And if a private group promises that everyone can buy before everyone else, ask who is supposed to be on the other side of the trade.

8. Fake Crypto Recovery Services

A recovery scam targets someone who has already lost money and charges for a recovery capability the operator does not possess.

This is one of the cruelest patterns because the psychological hook is not greed. It is relief.

The supposed specialist claims to have located the funds, identified the owner, obtained a court order, or arranged a government-approved recovery.

A payment is needed first.

Then another payment is needed.

Under the Hood

Public blockchains can make transactions traceable. Traceability is not control.

An investigator may identify:

• Transaction paths.
• Related addresses.
• Deposits into a centralized service.
• Potential links between victims.
• Evidence useful to law enforcement.

None of that automatically grants the ability to sign a transaction from the attacker’s address.

The FBI warning about fictitious law firms targeting cryptocurrency victims describes impersonated lawyers, fraudulent documents, supposed government affiliations, and invented bank or regulatory procedures.

Knowing the exact date or amount of your earlier loss is not proof of legitimacy. That information may come from the original scammers or a traded victim list.

Banking comparison: This is an advance-fee recovery scheme. Real legal and forensic work may involve fees, but a professional engagement is different from a guaranteed refund supposedly unlocked by paying cryptocurrency to a stranger.

Red Flags and Defenses

Be especially cautious of:

• Guaranteed recovery.
• Unsolicited contact after you discuss a loss publicly.
• Claims of special government authorization.
• Demands for a recovery tax or release deposit.
• Requests for seed phrases or remote wallet access.
• Payments to unrelated companies or personal addresses.
• Fake court documents that cannot be verified independently.

Verify lawyers through the relevant licensing authority and contact the firm through independently established details.

Do not rely solely on a video call or scanned credential. Both can be manipulated.

If funds reach a cooperative centralized exchange, lawful requests may help identify accounts or preserve assets. Some token issuers also have specific administrative powers under particular circumstances.

Those possibilities do not create a universal blockchain reversal service.

9. Honeypot Smart Contracts and Sell-Tax Traps

A honeypot token allows victims to buy while preventing, restricting, or economically destroying their ability to sell.

The psychological hook is urgency: a rising chart, an apparently early opportunity, and visible buys that make hesitation feel expensive.

The contract is the trap.

Under the Hood

A token can distinguish transfers involving a liquidity pool from ordinary wallet transfers.

For example, its logic may:

• Permit transfers from a pool to buyers.
• Reject transfers from buyers back to the pool.
• Allow only selected addresses to sell.
• Apply an extreme sell fee.
• Blacklist accounts after purchase.
• Limit sales to impractically small amounts.
• Consult another contract controlled by the operator.
• Change behavior through an upgradeable implementation.

A normal-looking transfer between two wallets does not establish that a sale through a decentralized exchange will succeed.

Neither does a chart showing successful sells. Those sells may belong to whitelisted insiders.

A scanner can simulate a purchase and sale, but the result is a snapshot. It may depend on the caller, amount, block state, router, or administrator settings. The operator can sometimes change conditions after the check.

Banking comparison: This resembles a dishonest dealer willing to sell an investment but unwilling to honor the exit terms. It is different from a legitimate, clearly disclosed lockup or a temporary lack of market liquidity.

Red Flags and Defenses

I look for asymmetry:

• Many buyers but few independent sellers.
• Sell transactions repeatedly reverting.
• Mutable fees with little meaningful limit.
• Hidden or poorly documented administrator powers.
• A recommendation to increase slippage dramatically to “fix” selling.
• Verified source code that delegates important decisions elsewhere.

Source-code verification means the published code matches deployed code under the verification process. It is not an audit or an honesty certificate.

Before buying, examine the current implementation, proxy structure, privileged roles, and realistic sell simulation.

A small test sale can reduce uncertainty, but it cannot guarantee that the operator will not change the rules later.

Most importantly, do not keep increasing slippage against an unexplained sell restriction. Slippage tolerance does not cure malicious contract logic.

10. Liquidity Rug Pulls

A liquidity rug pull occurs when insiders remove or misuse the assets that make a token tradable, leaving holders unable to exit at anything resembling the displayed price.

The hook is often a reassuring phrase: “Liquidity added,” “LP locked,” or “community-owned token.”

I want to know who can remove the liquidity, how much is protected, and for how long.

Under the Hood

In a typical constant-product pool, liquidity providers deposit two assets and receive a claim on their share of the pool.

The Uniswap v2 explanation of liquidity pools and LP tokens explains how liquidity tokens represent those claims and can be redeemed for underlying assets.

If the project controls most LP tokens, it may remove most of the pool’s valuable asset.

The token still exists afterward. Its market may effectively disappear.

Different protocol versions use different position representations. Some concentrated-liquidity systems represent positions with NFTs rather than ordinary fungible LP tokens. Other architectures maintain position accounting differently.

“LP locked” is therefore not a complete technical description.

Reassuring claim	What I would verify
Liquidity is locked	Which pool, position, amount, and lock contract?
LP tokens were burned	What share of total relevant liquidity does that cover?
Ownership was renounced	Are proxy administrators or other privileged roles still active?
The project was audited	Which code version and exact deployed contracts were reviewed?
The team cannot rug	Can insiders mint and dump tokens or alter transfer rules instead?

A liquidity lock does not prevent every other form of value extraction.

Banking comparison: This resembles a dealer withdrawing the cash supporting its market while continuing to advertise a last-traded price. Ordinary market illiquidity is not automatically fraud, but concealed control and deceptive assurances materially change the picture.

Red Flags and Defenses

Inspect liquidity ownership, lock expiration, pool concentration, insider token supply, minting authority, and upgradeability.

Look for whether a small group controls both the token supply and the liquidity position.

Avoid treating a badge from a scanner or lock service as an unconditional safety guarantee. A real lock can protect the wrong pool, cover only a small percentage, or expire soon.

The question is not “Does this token have liquidity?”

It is “Which party can remove the liquidity or overwhelm it with newly created supply?”

11. AI Deepfake Giveaways and “Send Crypto, Get Double Back” Scams

A deepfake giveaway uses apparent celebrity or executive authority to convince people to send cryptocurrency to an attacker.

The offer is familiar: send one amount and receive a larger amount back.

The packaging has improved.

An attacker may use a cloned voice, synthetic video, a hijacked YouTube channel, a realistic livestream layout, and thousands of fabricated comments.

Under the Hood

The FBI advisory on generative AI in financial fraud explains how synthetic text, images, audio, and video can make impersonation schemes more believable.

In a giveaway scam, the blockchain component is usually simple:

1. A video or post presents a deposit address or QR code.
2. The victim sends cryptocurrency.
3. A fake transaction feed displays supposed matching payments.
4. The promised return never arrives.

The displayed feed may contain fabricated entries, attacker-funded transfers, or selective small payouts.

A genuine transaction to the advertised address only proves someone sent money there. It does not prove an executive authorized the campaign.

A verified social account is also not definitive evidence. Accounts and channels can be compromised.

Banking comparison: This is a counterfeit endorsement combined with an advance-fee prize scam. The financial instruction is fraudulent even if the famous person’s face looks convincing.

Red Flags and Defenses

Do not base the decision on whether you can detect a visual glitch.

Deepfake detection by casual inspection is unreliable, and ordinary recordings can also be edited misleadingly.

Instead:

• Open the organization’s established website independently.
• Look for the promotion through normal official navigation.
• Reject any requirement to send crypto to receive a multiplied return.
• Treat countdowns and “last chance” messages as pressure, not evidence.
• Report the impersonating account or hijacked channel.

Legitimate promotions can exist. They do not turn an unsolicited promise to double a direct crypto payment into a sensible transaction.

A hardware wallet will not save you if you knowingly confirm the attacker’s payment address.

12. Fake YouTube MEV Bots and Copy-Paste Trading Contracts

A fake MEV bot persuades the victim to deploy and fund a contract that sends the deposit to the scammer.

The hook is technical credibility.

A tutorial shows a polished development environment, plausible code, impressive earnings, and reassuring comments. The victim feels they are building a trading tool, not transferring money to a stranger.

Under the Hood

Real maximal extractable value strategies involve transaction ordering and execution opportunities. The Ethereum explanation of maximal extractable value provides the relevant background.

A deployed smart contract does not independently wake up, inspect every pending transaction, and generate guaranteed arbitrage profits.

Real strategies generally require off-chain search, transaction construction, infrastructure, execution opportunities, and competition.

The fraudulent contract may instead:

• Accept ETH.
• Construct an attacker address through confusing string operations.
• Use names such as start, withdraw, or mempool.
• Send its balance to the hidden recipient when called.

The code can compile successfully. The deployment can succeed. Every transaction can be valid.

None of that means a trading strategy exists.

Names such as callMempool are not proof that code actually accesses a mempool. Function names are labels chosen by the author.

Banking comparison: This resembles buying a supposed automated investment system whose deposit mechanism is actually a payment to the seller. Technical presentation substitutes for independent verification of the money flow.

Red Flags and Defenses

I would walk away from:

• Guaranteed daily profits.
• Instructions to fund an unaudited contract before understanding it.
• A warning that editing the code will “break the algorithm.”
• Hidden payout addresses or unnecessary obfuscation.
• Comments that discourage independent review.
• A deployment guide that never explains where revenue actually comes from.

Trace every path by which ETH or tokens can leave the contract.

Use an independent reviewer who did not supply the code. Do not assume a video creator’s “auditor” is independent.

Legitimate tools such as Remix are not the problem. They can deploy malicious code just as successfully as legitimate code.

And a cold wallet can still sign a transaction that voluntarily funds a scam contract.

13. SIM Swapping and Exchange Account Takeovers

A SIM swap moves a victim’s phone number to an attacker-controlled SIM or eSIM, allowing the attacker to intercept calls and text-based recovery codes.

The psychological opening may be invisible to the victim. The attacker targets the mobile carrier’s procedures instead.

The first symptom can be sudden loss of cellular service.

Under the Hood

The FBI explanation of SIM-swapping schemes describes social engineering, insider assistance, and other methods used to redirect a phone number.

After taking control, an attacker may:

1. Reset an email password.
2. Intercept an SMS code.
3. Recover an exchange account.
4. Add a withdrawal destination.
5. Transfer assets before the victim restores service.

A SIM swap does not, by itself, reveal an independently stored self-custody private key.

It becomes especially dangerous when phone-based recovery protects email, exchange access, cloud backups, or other paths leading to financial control.

Banking comparison: This is account takeover through a compromised recovery channel. Both banks and exchanges face it, but an attacker who converts access into an on-chain withdrawal can make the next recovery stage much harder.

Red Flags and Defenses

Use stronger authentication where supported:

• Phishing-resistant security keys or passkeys.
• Strong protection for the primary email account.
• A carrier account PIN.
• Port-out or number-lock protections.
• Withdrawal address allowlists.
• Delays for newly added withdrawal destinations.

An authenticator app reduces SIM-swap exposure, but ordinary one-time codes can still be phished. Not all multifactor methods offer the same protection.

Review fallback recovery options. A strong security key does less good if a weak SMS recovery path can bypass it.

If service suddenly disappears:

1. Contact the carrier through independently verified details, preferably from another device.
2. Secure email and financial accounts from a clean device.
3. Ask exchanges to restrict withdrawals.
4. Review sessions, recovery settings, and recent destination changes.
5. Preserve notifications and carrier records.

Do not trust an incoming “support” call that arrives during the incident. The attacker may be managing the confusion.

14. Clipboard Hijackers and Crypto-Stealing Malware

Clipboard hijackers replace copied wallet addresses, while broader crypto malware steals keys, wallet files, credentials, or authenticated sessions.

The hook is often unrelated to crypto: pirated software, a fake update, an attachment, a meeting application, or a development tool.

The attacker gets inside the device before the payment begins.

Under the Hood

A clipboard hijacker can watch for address-like strings and substitute an attacker-controlled destination.

More advanced malware may:

• Change a destination after pasting.
• Alter the page’s displayed address.
• Interfere with transaction construction.
• Steal browser wallet storage.
• Capture passwords or session cookies.
• Search for exported keys and recovery screenshots.
• Monitor the screen or clipboard for secrets.

An encrypted wallet file is not the same as an exposed plaintext private key, but stealing it can create an offline password-cracking opportunity.

The Ethereum security guidance on protecting recovery material explains why screenshots and internet-connected copies of secrets increase exposure.

Banking comparison: This resembles banking malware that changes payment instructions or steals sessions. In self-custody, however, stolen signing material can remain useful independently of the original device.

Red Flags and Defenses

For significant payments, verify the complete destination on a trusted hardware wallet display, not only the computer screen.

Also:

• Keep operating systems and wallet software updated.
• Avoid cracked software and unknown installers.
• Do not approve unexplained accessibility or administrator permissions.
• Separate routine browsing from high-value wallet activity.
• Avoid storing recovery phrases in screenshots, notes, or cloud drives.
• Recheck the recipient for every payment, including after a successful test.

A hardware wallet reduces private-key exposure, but it does not make blind signing safe. Malware can still present a harmful transaction for you to approve.

If malware may have accessed wallet secrets, create the replacement wallet on a clean device. Creating new keys on the same compromised machine can give the attacker a second set.

If only an address was substituted, the incident may not involve stolen keys. Investigate the actual scope rather than assuming either the best or the worst.

15. Cloned Wallet Apps and Counterfeit Download Pages

A cloned wallet app imitates a legitimate wallet while stealing imported recovery material or generating keys the attacker can access.

The psychological hook is familiarity: the correct logo, a recognizable interface, and apparently positive reviews.

The fake application may even perform ordinary wallet functions.

Under the Hood

There are two common failure paths.

Imported wallet theft:

1. The user downloads the counterfeit application.
2. It asks to restore an existing wallet.
3. The user enters the recovery phrase.
4. The application transmits the phrase or derived keys.
5. The attacker reconstructs the wallet elsewhere.

New-wallet compromise:

1. The application creates an apparent new wallet.
2. Its key generation is predictable, attacker-controlled, or secretly exported.
3. The user deposits assets.
4. The attacker transfers them out.

A wallet that successfully receives or sends a small payment is not necessarily honest. A malicious developer can preserve normal functionality until the balance is attractive.

The BIP39 explanation of mnemonic-to-seed derivation helps clarify why a counterfeit app that sees the recovery material can recreate the relevant accounts. A local app password does not undo that exposure.

Banking comparison: A fake banking app may steal login credentials. A fake self-custody wallet can steal the underlying authority itself, leaving no central password reset that invalidates the copied keys.

Red Flags and Defenses

Download through links reached from the project’s independently verified website.

Check:

• Publisher identity.
• Application identifiers and signing information where available.
• Whether the official project actually supports that operating system.
• Whether the download is being delivered through an advertisement or private message.
• Whether an “update” asks for recovery material unexpectedly.

App-store availability, reviews, and download counts are useful context, not guarantees.

Never type a hardware wallet’s recovery phrase into a companion desktop app merely because the app uses the manufacturer’s logo.

If you restored a wallet into a counterfeit app, treat that wallet’s recovery material as compromised. Uninstalling the app does not remove the attacker’s copy.

16. Malicious Browser Extensions and Wallet-Update Traps

A malicious extension abuses browser access to alter wallet interactions, steal information, or impersonate a wallet.

This differs from a counterfeit wallet app because the attacker may compromise the surrounding browser environment rather than ask you to install a replacement wallet.

The hook is convenience: a price tracker, coupon tool, portfolio assistant, “security extension,” or urgent update.

Under the Hood

Depending on granted permissions, an extension may be able to:

• Read or modify pages.
• Replace payment instructions.
• Inject misleading wallet connection prompts.
• Observe information entered into websites.
• Interfere with the wallet-provider interface.
• Redirect users to a counterfeit signing flow.
• Capture sensitive material entered during a fake restore process.

A previously legitimate extension can also become dangerous after a malicious update or ownership change.

That is a supply-chain problem. The original installation decision may have been reasonable.

The crucial trust boundary is broader than the address bar. A genuine website can be displayed inside a browser whose extensions are altering what the user sees.

Banking comparison: This resembles a malicious browser add-on modifying an online banking session. The account’s security controls may be intact while the browser lies about the instruction being approved.

Red Flags and Defenses

Be cautious when an extension:

• Requests access to every website without a clear need.
• Suddenly asks for broader permissions.
• Claims it must “repair” an existing wallet.
• Requires importing a recovery phrase.
• Arrives through a support message rather than the official update channel.
• Produces signing requests when you did not initiate an operation.

The MetaMask description of its real support channels is a useful model: support identity and software distribution should be independently verifiable.

For high-value activity, I prefer a dedicated browser profile with very few extensions, combined with hardware signing and clear transaction decoding.

Review installed extensions periodically. Removing unused extensions reduces the number of parties that can influence the browser.

If an extension may have captured secrets or sessions, removing it is only the first step. Investigate exposed keys, credentials, API access, and existing permissions.

17. Malicious QR Codes and WalletConnect Pairing Traps

A malicious QR code hides an attacker-selected destination or session request behind a familiar scanning action.

The hook is speed. People often scrutinize a typed link more carefully than a square they have been told to scan.

The FTC warning about harmful links in QR codes explains how attackers use urgent messages and substituted codes to move people into phishing workflows.

Crypto adds several possible payloads.

Under the Hood

QR payload	What it can lead to
Website address	A counterfeit login, recovery, or claim page
Cryptocurrency payment request	A payment to an attacker-controlled address
WalletConnect pairing information	A session in which an attacker-controlled application requests transactions or signatures
Exchange login approval	Authorization of a session the victim did not intend to create

Scanning alone does not ordinarily authorize unrestricted wallet spending.

The dangerous sequence is usually:

1. Scan.
2. Open or pair.
3. Accept a session or login.
4. Receive a misleading request.
5. Approve a payment, signature, or permission.

That distinction matters. Telling people “a QR code instantly drains your wallet” obscures the point at which authorization occurs.

Banking comparison: This is similar to scanning a substituted payment code or approving someone else’s banking login. The code is a transport format, not an identity certificate.

Red Flags and Defenses

Before acting, inspect what the code decoded:

• A website?
• A payment destination?
• A connection request?
• An account login?

Do not assume a code printed on a physical object is trustworthy. Stickers can cover genuine codes.

For WalletConnect, verify the application identity and network, then inspect every subsequent request. A session label is not a spending guarantee.

Reject unexpected transaction requests even if the initial pairing looked harmless.

After an incident, disconnecting the session can stop further requests through that session. It does not revoke approvals, orders, permits, or other authority already created.

For product teams, the scanning screen should explain the request type before the user reaches a generic confirmation button.

18. Dusting Attacks and Blockchain Deanonymization

A dusting attack sends tiny amounts to addresses and analyzes later activity to connect wallets or support targeted fraud.

Dusting is primarily a privacy attack. It is not automatically a wallet-draining event.

That distinction is important because exaggerated warnings can push users into unnecessary transactions.

Under the Hood

On a UTXO-based network such as Bitcoin, a payment creates transaction outputs.

An attacker may send a small output to many addresses and watch what happens when those outputs are later spent.

If a wallet spends a dust output together with other outputs, analysts may infer a relationship between them. Such clustering is a heuristic, not mathematical proof of common ownership, and some transaction structures complicate it.

An attacker might combine those observations with public posts, exchange information, leaked data, or known payment activity.

The resulting identity or wealth profile can support phishing, extortion, or other targeting.

Account-based systems such as Ethereum do not use the same UTXO-consolidation mechanism. Unsolicited ERC-20 spam may instead serve as phishing bait or history contamination.

Those are related abuses, but they should not all be described as the same technical attack.

Banking comparison: A tiny bank payment can help confirm that an account is active. Blockchain dusting adds public transaction-graph analysis, but it still does not magically reveal a private key.

Red Flags and Defenses

An unexpected tiny receipt does not require you to “clean” the wallet by sending it back.

For supported UTXO wallets, knowledgeable users can use coin control to avoid spending suspicious outputs. The exact feature names and behavior vary.

Also:

• Avoid unnecessary public links between identity and wallet holdings.
• Do not follow links embedded in unsolicited token metadata.
• Do not pay a service to “remove dust.”
• Do not sign a transaction merely because a message claims the wallet is contaminated.
• Separate payment contexts when privacy matters.

Address poisoning tries to make you choose the wrong recipient. Dusting tries to learn about relationships or activity.

Neither requires you to respond simply because an unsolicited transfer appeared.

19. P2P and OTC Chargeback Fraud

P2P chargeback fraud exploits the mismatch between a potentially reversible fiat payment and a difficult-to-reverse crypto release.

The hook is a favorable exchange rate, quick settlement, or a buyer willing to pay a premium.

The seller sees money arrive and releases crypto.

The fiat payment is later disputed, reversed, frozen, or connected to a stolen account.

Under the Hood

Escrow on a P2P platform generally controls the cryptocurrency leg.

It does not necessarily guarantee the finality or legitimacy of the external payment rail.

Attack patterns include:

• Forged bank-payment screenshots.
• Pending transfers presented as settled funds.
• Payments from stolen accounts.
• Card-funded payments exposed to disputes.
• Third-party payments that violate platform rules.
• Triangular fraud.

In a triangular scheme, the scammer may arrange for a separate victim to pay the crypto seller. The seller then releases crypto to the scammer.

The incoming payment is real, but its apparent purpose and counterparty are not.

ACH, card payments, and wires must not be treated as interchangeable. Fedwire settlement is generally final under its governing framework, unlike a routine card chargeback process. Fraud can still lead to investigations, freezes, attempted recalls, or legal claims.

Banking comparison: This is settlement-risk arbitrage combined with payment fraud. The attacker wants the seller to exchange an asset with practical finality for a payment carrying unresolved fraud risk.

Red Flags and Defenses

Before releasing crypto:

• Confirm receipt inside your own bank or payment account.
• Match the payer’s identity to the verified trading counterparty.
• Follow the platform’s payment rules.
• Reject unexplained third-party payments.
• Keep communication and evidence inside the platform.
• Do not release assets because a buyer sends a screenshot or threatens a complaint.

Be suspicious of a premium that makes no commercial sense.

Even a visible available balance may not eliminate the consequences of an unauthorized payment. The payment method’s rules matter.

For substantial OTC transactions, use appropriately regulated counterparties and documented settlement procedures. A stranger’s reputation score is not a substitute for understanding which side bears reversal, fraud, and compliance risk.

20. Fake Web3 Jobs, Recruiters, and Coding Tests

A fake Web3 recruitment process persuades a candidate to run code or install software that steals assets or workplace access.

The hook is professional opportunity, not an investment pitch.

This is why experienced developers can be excellent targets.

The FBI warning about sophisticated social engineering against the crypto industry describes tailored employment and investment scenarios, impersonation, unfamiliar software, and code-execution requests.

Under the Hood

A supposed recruiter may send:

• A GitHub repository.
• A Node.js or Python assessment.
• A game or wallet demo.
• A custom meeting application.
• A script that allegedly fixes microphone or camera access.
• A request to debug a dependency problem.

The malicious behavior may live outside the obvious application code.

Potential execution points include package installation scripts, dependencies, workspace tasks, and setup tooling.

The payload may search for:

• Browser wallet data.
• Exchange credentials.
• Session cookies.
• .env files.
• SSH keys.
• Cloud access tokens.
• Production secrets.
• Recovery material.

A professional-looking repository is not proof of safety. Neither is fluent technical conversation.

Banking comparison: This resembles a fraudulent vendor or recruiter persuading an employee to install software on a machine connected to payment systems. The difference is that a developer laptop may simultaneously hold personal wallets and access to an organization’s financial infrastructure.

Red Flags and Defenses

Independently verify the recruiter through the employer’s established channels.

For code assessments:

• Do not use a production workstation.
• Do not expose wallets, browser profiles, or workplace credentials.
• Use an isolated, disposable environment.
• Avoid shared folders and credential forwarding.
• Review installation and execution behavior, not only the main source file.
• Restrict network access when appropriate.
• Ask your security team to review unusual tooling.

A container is not automatically an adequate security boundary. Its safety depends on configuration, mounts, privileges, and the host environment.

Disabling installation scripts can reduce one execution path, but it is not a complete malware defense.

If someone insists you must weaken your security controls to qualify for a job, that is useful information about the opportunity.

21. Public Seed-Phrase Bait and Gas-Sweeper Wallets

A seed-phrase bait scam publishes access to a seemingly valuable wallet, then steals the gas people deposit while trying to move its tokens.

The attacker is not asking for your recovery phrase.

They are offering you theirs.

The hook may be a plea for help, an “accidental” screenshot, or the suggestion that someone found an abandoned wallet.

Under the Hood

The visible wallet may appear to contain valuable tokens but lack the native asset needed for network fees.

The victim imports the public phrase and deposits ETH or another gas asset.

An automated sweeper controlled by the attacker moves the fresh gas deposit out immediately.

The supposed valuable balance may be:

• A counterfeit token.
• A frozen asset.
• Subject to transfer restrictions.
• In a wallet with additional account-permission constraints.
• Otherwise unavailable to the person importing the phrase.

Even if the balance is genuine, the attacker still has the same keys and can compete for control.

The BIP39 description of deterministic recovery explains why sharing the same recovery material does not transfer exclusive ownership. Multiple people can reconstruct the same wallet.

Banking comparison: This resembles being offered a safe that supposedly contains money, then paying repeated “access charges” to a person who still controls it. Possession of a credential is not proof of exclusive authority or lawful entitlement.

Red Flags and Defenses

Do not import publicly shared recovery phrases into your normal wallet environment.

Do not deposit gas into a wallet merely because its token balance looks large.

Do not assume that racing the sweeper is a sensible recovery strategy. Attackers may use automation and infrastructure specifically designed to win that race.

If the story is “I have the seed but need a small fee to access a huge balance,” stop.

For legitimate support questions, a public address is usually enough to inspect on-chain activity. Sharing a recovery phrase should never be the normal way to ask for assistance.

The safest response to exposed keys is not to investigate with your own money.

22. Fake Staking, Cloud Mining, and Crypto Ponzi Programs

A crypto Ponzi program pays earlier participants with later participants’ deposits while claiming the money comes from staking, mining, lending, or trading.

The hook is steady income.

Terms such as “staking,” “validator,” and “cloud mining” can make an old financial fraud sound like protocol revenue.

The SEC investor explanation of Ponzi schemes describes the underlying structure: payouts depend on continued new money rather than sufficient legitimate earnings.

Under the Hood

A fraudulent program may run through a centralized database, a smart contract, or both.

Real payouts can occur.

That is what distinguishes this mechanism from a dashboard that invents everything. Money may actually be paid to early users, but its economic source is misrepresented.

A blockchain record proves a payment occurred. It does not prove the payment came from productive activity.

The operator may advertise:

• Fixed daily returns.
• Guaranteed principal.
• Referral bonuses.
• Higher yields for longer lockups.
• Bonuses for reinvesting rather than withdrawing.
• A secret trading or mining process.

Legitimate staking involves protocol-specific rewards and risks. It does not automatically produce a guaranteed USD return.

Real mining also has variable economics: hardware, network difficulty, energy, uptime, asset prices, and contractual rights matter.

Banking comparison: The wrapper has changed, but the cash-flow problem is the same as in a traditional Ponzi scheme. A payment history is not proof of sustainable earnings.

Red Flags and Defenses

Ask:

• What independently verifiable activity generates the return?
• Who owns the underlying assets or equipment?
• Are liabilities and customer claims disclosed?
• Can the operator demonstrate more than wallet balances?
• Why are returns unusually consistent?
• How important is recruiting new participants?
• What happens if deposits stop?

Proof of reserves alone does not establish solvency. It may omit liabilities, encumbrances, ownership disputes, or off-chain obligations.

An audit of code also does not audit the entire business model.

If the explanation of revenue becomes less clear as the promised return rises, I stop there.

23. Exchange API-Key and Copy-Trading Bot Abuse

API-key scams obtain exchange access through a trading tool, portfolio application, or copy-trading service, then misuse the granted permissions.

The hook is efficiency: let a bot trade for you without sharing your password.

That can be legitimate. The danger lies in the scope and use of the authority.

Under the Hood

Exchange APIs commonly distinguish permissions such as:

• Read account information.
• Place and cancel trades.
• Transfer assets internally.
• Withdraw assets.

Exact permissions vary by platform.

A scammer with withdrawal access may simply remove funds.

But “withdrawals disabled” is not a complete safety guarantee.

A malicious trader may use trading permissions to:

• Buy an illiquid asset from attacker-controlled sell orders.
• Execute unfavorable trades.
• Generate excessive fees.
• Open risky leveraged positions.
• Destroy account value without withdrawing directly.

The attacker extracts value through the market or leaves the victim holding the loss.

This is different from an ERC-20 allowance. The authority exists inside the exchange’s account system rather than a public token contract.

The FBI warning about cryptocurrency-exchange impersonators is another reason to verify who is requesting account access instead of trusting a message bearing an exchange’s logo.

Banking comparison: This resembles granting a third-party investment mandate. Keeping custody at a familiar institution does not make an untrusted trading agent harmless.

Red Flags and Defenses

For portfolio tracking, read-only access is usually the relevant starting point.

For any trading integration:

• Understand the exact permission scope.
• Use a limited subaccount where available.
• Keep exposure small.
• Disable unnecessary transfers and withdrawals.
• Consider supported IP restrictions.
• Avoid leverage unless you fully understand the mandate.
• Review access regularly.
• Revoke keys when the relationship ends.

IP restrictions are a control, not proof of honesty.

Never send an API secret to a supposed support agent in chat.

After compromise, changing the account password may not invalidate every API key, OAuth grant, or authenticated session. Revoke the actual access mechanisms and inspect trade history as well as withdrawals.

24. NFT Offer, Listing, and Marketplace-Order Scams

An NFT order scam persuades a holder to sign a trade whose actual terms differ from the offer they think they are accepting.

The hook is often an unusually generous bid.

A supposed buyer says the seller must validate ownership, update a listing, or sign a gas-free confirmation.

The dangerous request may be an order, not a direct token approval.

Under the Hood

The ERC-721 NFT standard defines token-specific approvals and collection-level operator approvals.

Marketplace systems can combine those permissions with signed orders.

A holder may have already approved a legitimate marketplace operator. An attacker then seeks a signed order allowing that infrastructure to execute a harmful trade.

Important order terms include:

• Which NFTs are offered.
• How many assets are included.
• Which payment asset is received.
• The payment token’s actual contract address.
• The amount.
• The recipient.
• The execution window.
• Any restrictions or cancellation state.

A displayed symbol such as WETH is not enough to identify a payment token.

The FBI warning about criminals impersonating NFT developers also describes compromised or cloned accounts advertising urgent mint opportunities. That delivery channel can lead into approvals, orders, or direct transfers.

The authorization step determines the actual loss mechanism.

Banking comparison: This resembles signing a sale contract with substituted consideration or extra assets included. The signature may be authentic while the understood deal is not.

Red Flags and Defenses

Read both sides of the proposed exchange.

Be suspicious of:

• A private buyer who insists on a separate validation site.
• A signature described vaguely as ownership verification.
• More NFTs listed than you intended to sell.
• Payment in an unfamiliar token contract.
• An excessively long execution window.
• A request that cannot be explained by the marketplace’s documented workflow.

A zero-gas signature can still create an executable order.

Disconnecting the wallet does not cancel an existing order. Use the marketplace protocol’s supported cancellation or counter mechanism where available.

Revoking operator approval may prevent execution while the approval is absent, but it does not necessarily erase the signed order. Reapproving later can matter if the order remains valid.

25. Fake RPC Endpoints and Spoofed Wallet Balances

A malicious RPC endpoint lies about blockchain data so the wallet displays a false balance, transaction status, or network condition.

The hook may be a cheap token purchase, a “faster network,” a bridge setup, or instructions to add a custom RPC server.

This attack targets the information the wallet consumes.

Under the Hood

Wallets often ask RPC services for data such as:

• Native balances.
• Token balances through contract calls.
• Transaction receipts.
• Gas estimates.
• Nonces.
• Contract state.

An attacker-controlled endpoint can return dishonest answers to those requests.

For example, a victim pays for a token, then sees an apparently large balance because the configured endpoint fabricates the response to a balance query.

The actual public chain may contain no such balance.

A malicious RPC service does not automatically learn a locally held private key, and it cannot simply change the recipient inside an already signed transaction without invalidating that signature.

Its power is primarily to mislead, selectively relay, withhold, or otherwise manipulate the information and submission path available to the user.

Banking comparison: This resembles trusting a fake account statement or payment-confirmation screen instead of the bank’s independently verified records. The display is lying; the underlying settlement system may be functioning normally.

Red Flags and Defenses

Be cautious when a stranger insists that a trade will only work after you add a particular endpoint.

Verify important activity using independent infrastructure:

• The correct network.
• A separate, established explorer.
• The genuine token contract.
• The transaction receipt and relevant state.
• A trusted RPC configuration.

Two websites are not independent confirmation if both obtain their information from the same attacker.

A reported chainId is useful for configuration and signing context, but a dishonest server claiming the correct value does not become trustworthy.

For developers, distinguish “the endpoint reports this” from “the application independently verified this.” High-value operations may justify cross-checking multiple providers and detecting inconsistent responses.

26. Malicious Smart-Account Delegation and Wallet Modules

A malicious account-delegation request grants execution authority at the account level, rather than only allowing a spender to move one token.

The hook is often a useful real feature: gas sponsorship, one-click upgrades, batching, or a smarter wallet experience.

The danger is accepting an implementation or module whose authority you do not understand.

Under the Hood

The EIP-7702 account-code delegation specification allows an externally owned account to designate code for account execution through signed authorization.

That capability is not inherently malicious.

A well-designed implementation can enforce appropriate authentication and enable useful smart-account behavior.

A malicious or badly designed implementation can expose the account to unauthorized execution.

Important distinctions include:

• The delegated implementation address is a security-critical choice.
• Delegation can persist beyond the transaction that introduced it.
• The core authorization format does not itself contain a general expiration timestamp.
• The account’s execution behavior can matter across multiple assets.
• Gas sponsorship says who pays transaction fees, not whether the operation is safe.

Existing contract wallets can also support modules, plugins, owners, guardians, or session keys through their own architectures. Those systems are not all EIP-7702, but they create related account-authority risks.

This is broader than signing an EIP-2612 permit. A permit changes a token allowance. Account-level delegation can change how the wallet itself executes actions.

Banking comparison: The closest analogy is adding a payment signatory or granting a broad power of attorney, not authorizing one ordinary debit.

Red Flags and Defenses

Pause when a request involves:

• Delegating account execution.
• Installing a module or plugin.
• Adding an owner or signer.
• Changing guardians or recovery settings.
• Granting a session key broad asset or time access.
• An implementation that cannot be independently identified.

Verify the implementation, module permissions, upgradeability, initialization, and intended signer rules.

A hardware device confirming an opaque authorization is not the same as understanding that authorization.

After a suspected compromise, use the wallet’s documented process to remove or replace the delegation, module, or signer. Revoking ERC-20 approvals alone does not necessarily repair account-level authority.

If you cannot establish who currently controls execution, stop using the account for new deposits and obtain qualified assistance through independently verified channels.

27. Government Impersonation, “Safe Account” Transfers, and Bitcoin ATM Scams

A safe-account scam convinces someone that their money is in danger and must be moved to a cryptocurrency address for protection.

The supposed authority may be a bank fraud department, government agency, law-enforcement officer, or technical support team.

The hook is fear, not investment ambition.

A legitimate Bitcoin ATM can become the payment channel.

Under the Hood

The FTC analysis of Bitcoin ATM fraud describes how kiosks are used in government, business, and technical-support impersonation schemes.

The sequence often looks like this:

1. A caller claims the victim’s accounts are compromised.
2. The victim is told not to speak with anyone else.
3. The caller instructs them to withdraw cash.
4. A QR code specifies the cryptocurrency destination.
5. The victim deposits cash at a kiosk.
6. The purchased crypto is sent toward an attacker-controlled address.

The kiosk may operate exactly as designed.

A genuine receipt does not make the caller’s story genuine.

Scammers may coach victims to lie to bank staff about the withdrawal. That instruction is a particularly strong warning.

Banking comparison: This is an authorized payment induced by impersonation. Moving from cash to crypto helps the attacker escape the controls that might still exist around the bank account.

Red Flags and Defenses

No caller’s claim of authority should bypass independent verification.

If instructed to move money for safety:

• Stop the call.
• Contact the institution through a number you already know is genuine.
• Do not use the caller’s number or supplied link.
• Do not deposit cash at a kiosk using the caller’s QR code.
• Do not keep the transfer secret from trusted people.

A real bank does not need you to send cryptocurrency to an outside “safe wallet” to secure your checking account.

If a kiosk payment has already occurred, contact the operator immediately using verified information from the receipt or the operator’s established website. Intervention may depend on timing and the transaction’s state.

Preserve the receipt, destination, transaction details, caller information, and messages. Do not pay a second party who promises an immediate reversal.

What a Reasonable Crypto Risk Engine Looks Like

An effective first-line risk engine can begin with explainable rules tied to specific decisions, not a mysterious score labeled “safe” or “unsafe.”

I do not think every wallet or exchange needs to begin with an expensive analytics platform.

A first version can use events the product already observes, combined with clearly identified user disclosures and external indicators.

The following TypeScript example preserves a deliberately simple architecture:

type RiskContext = {
  unsolicitedContact: boolean;
  firstTimeRecipient: boolean;
  unusualAmount: boolean;
  depositRequiredForWithdrawal: boolean;
  unlimitedTokenAllowance: boolean;
  remoteAccessRequested: boolean;
  seedPhraseRequested: boolean;
  addressResemblesKnownRecipient: boolean;
};

const weights: Record<keyof RiskContext, number> = {
  unsolicitedContact: 10,
  firstTimeRecipient: 10,
  unusualAmount: 15,
  depositRequiredForWithdrawal: 35,
  unlimitedTokenAllowance: 20,
  remoteAccessRequested: 30,
  seedPhraseRequested: 100,
  addressResemblesKnownRecipient: 30,
};

function calculateRisk(context: RiskContext): number {
  return Object.entries(context).reduce((score, [signal, active]) => {
    if (!active) return score;
    return score + weights[signal as keyof RiskContext];
  }, 0);
}

function riskAction(score: number) {
  if (score >= 100) return "block-and-escalate";
  if (score >= 50) return "step-up-confirmation";
  if (score >= 25) return "show-contextual-warning";
  return "allow";
}

This is not a validated fraud model. The weights are illustrative, the score is not a probability, and the thresholds are not universal.

It also matters where each signal comes from.

A blockchain does not tell you that someone received an unsolicited WhatsApp message. That information might come from a voluntary user answer, a support conversation, or another properly authorized source.

Likewise, a product cannot infer “deposit required for withdrawal” merely because two transfers occurred.

What the Architecture Gets Right

The useful principles are:

• Each signal has an identifiable origin.
• A decision can be explained.
• A rule can be tested.
• Thresholds can be calibrated.
• An event can be reviewed later.

In production, signals should include time, provenance, confidence, and rule version.

Correlated signals need attention. A new recipient and a look-alike recipient may describe overlapping evidence. Adding weights does not automatically make the score more accurate.

The strongest controls should also respect the product’s authority. A self-custody interface may refuse to facilitate an operation, but that does not mean it can globally stop the user’s address from transacting through other software.

And detecting a recovery-phrase request should never require uploading the recovery phrase itself.

Preserve Evidence Without Preserving Secrets

An event record might look like this:

{
  "eventId": "risk_evt_example_001",
  "observedAt": "2026-10-18T14:30:00Z",
  "subjectId": "pseudonymous-user-42",
  "chainId": 1,
  "ruleId": "recipient-similarity",
  "ruleVersion": "3.1.0",
  "source": "verified-address-book-comparison",
  "confidence": 0.82,
  "action": "step-up-confirmation",
  "userDecision": "paused",
  "engineVersion": "1.4.0",
  "txHash": null
}

Here, confidence refers to the signal’s supporting evidence under the product’s definition. It should not be presented as an 82% probability that a person is committing fraud.

Do not store seed phrases, private keys, session secrets, or unrestricted support transcripts in a risk log.

A Five-Layer Security Workflow for Wallets and Exchanges

A good crypto-security workflow gathers relevant signals, normalizes them correctly, explains the finding, applies proportionate friction, and records the outcome.

The strongest product design puts the explanation at the point where authority changes.

1. Collect Relevant Signals

Depending on the operation, useful signals include:

• Session origin.
• Account age.
• Recent device changes.
• Recipient history.
• Contract type.
• Token and amount.
• Requested allowance.
• Transaction-simulation results.
• Known compromise indicators.
• Recently changed account recovery settings.
• Newly granted API access.
• Prior warnings shown during the same flow.

More data is not automatically better.

A product should know why it collects each field, who can access it, how long it is retained, and how it helps prevent a particular loss.

Indiscriminate telemetry increases privacy exposure and the consequences of a breach.

2. Normalize Without Destroying Meaning

Normalize the identifiers before comparing them:

• Network and chainId.
• Chain-appropriate address encoding.
• Checksummed display where applicable.
• Unicode and Punycode domain representations.
• Time zones.
• Token units and decimal counts.
• Contract and implementation addresses.

Do not blindly lowercase every address format across every blockchain. Address rules differ.

A checksum can help catch certain entry mistakes. It does not prove the recipient is honest.

Domain normalization should expose suspicious differences, not silently treat a look-alike as trusted.

For tokens, use the network and contract identity rather than a symbol alone. Store on-chain amounts using suitable integer representations, not floating-point arithmetic that can silently alter values.

3. Explain the Finding

A warning should identify the assumption the user needs to verify.

Better:

This destination has not been used before and closely resembles a saved recipient. The middle characters differ. Verify the complete address through your trusted source.

Worse:

Risky transaction detected.

For approvals:

This spender will be able to transfer your approved token later, including after you disconnect this website.

For a supposed withdrawal tax:

Sending another payment to this address will not technically unlock funds held by a different party. Verify the platform independently before continuing.

Clear language is a security control.

4. Use Proportionate Friction

Possible responses include:

• An informational message.
• A detailed confirmation screen.
• A full-address review.
• Confirmation on a trusted second device.
• A short delay for a new withdrawal destination.
• A support conversation.
• A temporary restriction where the provider has authority.
• Security-team escalation.

Not every unusual transaction should be blocked.

Excessive warnings train people to click through. Overly broad restrictions can also trap legitimate users during genuine emergencies.

Measure whether the intervention reduces losses, not merely whether it produces more clicks.

5. Maintain an Audit Trail

For significant risk decisions, retain an appropriately protected record of:

• A user or pseudonymous subject identifier.
• Event time.
• Network and relevant addresses.
• Transaction hash, if one exists.
• Triggered rules.
• Signal provenance.
• Warning text shown.
• User decision.
• Engine and rule versions.
• Subsequent outcome where it can be established.

Limit access and retention.

A good audit trail supports investigations, but it also answers a product question: Did the warning prevent harm, or merely inconvenience people?

What Crypto Scam Protection Actually Costs

The cost depends on which failure you are trying to prevent.

Basic recipient checks, clear approval screens, contextual warnings, and audit logs can often be built into an existing application.

The main expense is engineering, design, security review, and ongoing operations.

Protection layer	Typical cost driver	Important limitation
Recipient history and explainable rules	Product and engineering time	Requires calibration and false-positive review
Token balances and allowance checks	RPC access, indexing, and maintenance	Data quality and network coverage matter
On-chain revocation	Network transaction fees	Does not undo completed theft
Transaction simulation	Infrastructure or vendor usage	A simulation is a state-dependent prediction, not a guarantee
Domain and contract reputation	Intelligence feeds and analysis	New attacks may not yet be labeled
Blockchain tracing	Specialist tools and investigative work	Tracing does not create control over funds
Human review and incident response	Trained staff and procedures	Quality and response time materially affect outcomes

Building internally can reduce reliance on one vendor, but it creates responsibilities for nodes, indexers, rule maintenance, and data quality.

Buying a service can accelerate deployment, but it does not remove the need to understand its blind spots.

The most expensive mistake is often not infrastructure spending. It is a product decision that creates false confidence.

I prefer “No known malicious indicators were found in these checks” to an unconditional green badge reading “Safe.”

Those statements are not equivalent.

What to Do in the First Hours After a Crypto Scam

The first response should match the compromise: a payment, a spending permission, an account takeover, exposed keys, or an infected device.

Do not keep interacting with the scammer while trying to diagnose the problem.

Stop additional payments. Preserve evidence. Work from a clean device when device compromise is possible.

If You Sent Money but Did Not Expose Wallet Access

Save:

• Transaction hash.
• Network.
• Recipient address.
• Token contract, where applicable.
• Amount.
• Date and time.
• Messages and call records.
• Website addresses and account names.
• Deposit and withdrawal records.
• Exchange purchase receipts.
• Kiosk receipts, if relevant.

A screenshot is useful, but structured transaction details are easier to investigate.

Notify the sending exchange or service immediately. If the destination appears to be a centralized service, report it there as well through independently verified channels.

If a bank transfer funded the scam, contact the bank’s fraud department immediately and ask what recall, restriction, or dispute procedures may apply.

Do not assume that a wire can be reversed or that an authorized payment receives the same treatment as an unauthorized one.

If You Approved a Malicious Spender

Inspect the actual authorization layer:

• ERC-20 allowances.
• NFT operator approvals.
• Permit2 permissions.
• Marketplace orders.
• Smart-account modules or delegations.

Use independently verified tools and official wallet guidance.

The Ethereum walkthrough for revoking contract access explains ordinary token-approval revocation, but revocation is not a universal remedy for every signature type.

An unused permit may remain valid until its nonce or other validity condition changes. A signed order may need cancellation through its own protocol.

Disconnecting the website is not enough.

If Your Recovery Phrase or Private Key Was Exposed

Treat the relevant signing material as compromised.

Where feasible:

1. Use a clean device.
2. Generate genuinely new recovery material.
3. Verify the new wallet and backup process.
4. Move remaining assets.
5. Review other accounts and chains derived from the same compromised material.

Do not simply create another account under the same seed.

If a sweeper is removing every gas deposit, do not repeatedly add more gas without a plan. That can feed the attacker.

Specialized rescue methods may exist in some circumstances, but they are not guaranteed and should not become an excuse to trust an unsolicited recovery agent.

If an Exchange Account or API Key Was Compromised

Secure the primary email account as well as the exchange.

Then review:

• Passwords.
• Active sessions.
• API keys.
• Connected applications.
• Recovery methods.
• Withdrawal addresses.
• Recent trades.
• Internal transfers.
• Pending withdrawals.

Ask the provider to restrict activity when appropriate.

A password change may not revoke all other access.

If the Device Was Compromised

Do not generate the replacement wallet on that device until it has been appropriately remediated.

Depending on the incident, that may involve isolation, forensic review, or a trusted reinstall.

Also rotate exposed workplace, cloud, SSH, exchange, and application credentials.

For organizational incidents, coordinate evidence preservation with the security team before wiping systems.

Report Through Verified U.S. Channels

You can submit an internet-crime complaint to the FBI’s Internet Crime Complaint Center and file a consumer fraud report with the FTC.

California consumers can also submit a complaint through the DFPI’s official process.

Outside the United States, report through the appropriate national cybercrime, police, and financial-regulatory channels.

Reporting does not guarantee recovery. It creates evidence that can connect victims, addresses, platforms, and operators.

Be alert to follow-up impersonation. Someone claiming to represent an agency should still be verified independently. A complaint does not make later payment demands legitimate.

Quick Answers to Common Crypto Scam Questions

The safest answers distinguish access, authorization, and settlement rather than treating every wallet interaction as the same event.

Can Someone Steal Crypto Without My Recovery Phrase?

Yes. An attacker may exploit a token approval, permit signature, marketplace order, account delegation, exchange login, API key, or malware-assisted payment substitution.

Can Connecting a Wallet Drain It?

Ordinary wallet connection generally does not authorize spending by itself. The danger usually comes from a subsequent transaction, signature, permission, or account-level change. Software vulnerabilities remain a separate risk.

Does Disconnecting a Website Revoke Its Permissions?

No. Disconnecting usually ends a session. On-chain allowances, executable orders, valid permits, and account-level authority can remain.

Can an Unknown Token Automatically Hack My Wallet?

Receiving an unsolicited token ordinarily does not reveal your private key or authorize other spending. The main risk is following its instructions or interacting with a malicious claim, trade, or approval flow.

Does a Hardware Wallet Prevent Every Crypto Scam?

No. It can protect key material from many device attacks, but it can still sign a harmful payment or authorization you approve. Verify the destination and the actual action on the trusted display.

Can Stolen Cryptocurrency Be Recovered?

Sometimes, through timely intervention, cooperative custodians, issuer-specific controls, lawful seizure, or other case-specific routes. There is no universal chargeback or guaranteed private recovery service for confirmed blockchain transfers.

The Security Standard I Want Crypto Products to Meet

The best crypto scam protection explains what authority is changing before the user approves it.

I do not want another generic modal telling me that cryptocurrency is risky.

I want a product to help at the precise moment when:

• I send to a new recipient.
• An address resembles a trusted one.
• A contract requests unlimited spending.
• A signature creates financial authority rather than a login.
• A marketplace order includes assets I did not intend to sell.
• A wallet upgrade changes account-level execution.
• A token’s identity or liquidity cannot be established.
• A platform demands another deposit to release funds.
• A support agent requests information legitimate support should never need.

Education matters. But education cannot be the only control.

A well-designed system does not assume every user will recognize every social-engineering script, inspect every address character, or decode every typed-data field.

It makes the important difference visible before the transaction becomes an expensive lesson.

That is the standard I apply as a former banker looking under the hood of crypto: not whether the interface looks trustworthy, but whether the user can understand and verify who gets control of the money.

---

Sponsored Partner: Volet.com

Looking for a simple, everyday way to buy, hold, and sell cryptocurrencies alongside your traditional currencies and payment cards?

• Read my full breakdown: Complete Volet Review on DoraMilen.com
• Get started right away: Open your free Volet account using my referral link