How to protect crypto transactions from phishing

Phishing is the main cause of losses in the crypt. Attacks have become smarter: fake wallet sites, "drainers" in DApp, fake airdrop's, subscriptions to endless write-offs (approve/permit), spoofed QR codes and "address poisoning." The good news: Simple operational discipline almost completely obscures these vectors. Below is a practical system that protects transactions before and after clicking "Send/Sign."

1) Three protection whales: address → network → signature

1. Recipient's address: check at least the first and last 4-6 characters, use only QR/details from your personal account, and not from chats/searches.

2. Network/Asset: The token network (ERC-20/TRC-20/BEP-20/Arbitrum/Optimism/Solana/TON, etc.) must be the same at the sender and receiver. For XRP/XLM/BNB/EOS, check Memo/Tag.

3. Signature/transaction: read what exactly you are signing: 'transfer', 'approve', 'permit', 'setApprovalForAll', 'swap', 'bridge', 'mint'. If you don't understand, don't sign.

2) Basic phishing vectors (and how to close them)

Fake sites and homograph domains. Work only from your own bookmarks; do not follow advertisements and "support" in instant messengers.

Clipboard stylers and QR substitution. Scan QR from the official page, check the address characters. Any discrepancy is a cancellation.

Address poisoning. Do not copy addresses from your inbox history. Use the address book/whitelist.

Drainer scripts in DApp. Never import seed on websites. Before signing, see what rights DApp requests (limit, token, term).

Fake airdrop/NFT. Do not interact with gift NFTs/links. Any "claim" button outside of trusted sources is prohibited.

Social engineering (mail, Telegram/Discord). Support never asks for seed/private key/key export. Anti-phishing phrase in exchanges must be included.

WalletConnect integrations. Check the DApp name and domain in the session request. If it does not match the open site, reject it.

Bridges/breeches. Use only official; verify the target network and token contract.

Lightning/QR invoices. One-time invoice, lives for minutes. Overdue - generate a new one, do not "refresh" the old one.

3) Hardware wallet and "confirmation on the screen"

A hardware wallet dramatically reduces the risk of phishing: it shows the real signature data in your hands. Habits:

Confirm the address/amount/method on the device screen.
Never enter seed on a PC/phone/site - only on the device itself.
For large amounts - the policy of "four eyes": the second person/second key in the multisig.

4) Secure signatures in EVM networks (ETH, BSC, Polygon, etc.)

Approve/Permit:

Give access only to the desired token, set a minimum limit, not "∞."
Periodically revoke (revoke) old permissions through reliable wallet revok services/DApp.
EIP-2612/Permit2/Off-chain orders: read the text. A "free signature" can give long-term access to spending.
Transaction simulation: Use wallets/extensions that show what will change after execution (where the tokens will go from/to).

5) Browser and device hygiene

Separate browser profile for crypto, minimum extensions.

Wallet auto-updates - only from official sources; check the signature/hash of desktop builds.

2FA TOTP/U2F on exchanges; download backup codes and a second token key.

Do not conduct large operations in public Wi-Fi.

Keep a transaction log: date, network, address, amount, TxID.

6) Check list before sending/signing (1 minute)

The address is taken from the bookmark/official application, the first/last 4-6 characters match.
Network/asset and (if necessary) Memo/Tag checked.
I understand the type of operation: 'transfer '/' approve '/' permit '/' swap '/' bridge'.
The authorization limit is limited to the amount of the transaction, not "∞."
For Amount> $200 - Test Transaction and Pending Credit.
Hardware wallet: address/amount/contract confirmed on device screen.

7) Protocol for suspected phishing (actions per minute)

0-5 minutes:

Immediately disable the internet/extension, stop further signatures.
On exchanges - freeze outputs, change passwords, turn off active sessions.

5-30 minutes:

Check the latest approve/permit and recall suspicious ones.
Transfer assets from a vulnerable wallet to a clean wallet (sweep), start with the most liquid tokens/coins.
Save TxID, screenshots, logs.

Reinstall the wallet on a clean device, with new keys.
Report to services where the attacker's assets (exchanges/bridges) could be.
Analyze: where did the link come from, who requested the signature, what extensions are installed.

8) Frequent "red flags"

Urgency and deficit: "do now, otherwise we will freeze the bonus/account."

Please enter seed/private key "to check/activate/airdrop."

There is a mismatch between the domain in WalletConnect and the public site.

Request "approve for all tokens" or "unlimited forever."

Fake "speed up/claim/verify" buttons on clone sites.

9) Mini-FAQ

Is the last 4 characters of the address enough? Better - the first and last 4-6: some attacks pick up the same "tail."

Do I always need to limit approve? Yes I did. Permission to "∞" is convenient for an attacker and drainers.

How often to make a roar of rights? After each session with a new DApp and regularly scheduled (for example, once a month).

Does a hardware wallet solve everything? It greatly reduces the risk, but will not protect against your signature on a harmful operation - read what you sign.

Is it possible to "cancel" the transfer? No, it isn't. Maximum - have time not to sign a harmful operation or revoke rights before writing off.

Protection against phishing is not an "anti-everything" software, but a procedure: your bookmarks, verification of address/network, reading signatures, limited approve/permit, hardware wallet, roar of extra rights and test translations. Make a routine out of this - and the chance of losing funds due to phishing will become statistically insignificant, even if you actively use DApp, bridges and exchanges.