Crypto security and crypto scams
A crypto payment has no undo button: a transaction that has settled on the network does not come back, and no authority exists to bring it back. Nearly every habit in this lesson comes out of that single property, and any advice that does not take it seriously is worthless.
- Lesson 5 of 8
- Beginner
- Free, no signup
Four ways the money leaves without anything being broken
-
The words you typed
A recovery phrase in a form, in a chat, or in a fake app. From that moment the wallet has two owners.
-
The approval you signed
Nothing leaves your balance at the moment of signing, which is what makes reading it so easy to skip.
-
The payment you sent yourself
To an address that came in a message or a QR code. The transaction is entirely valid, which is why nobody stops it.
-
An account that is not yours
A deposit into an unknown investment site or exchange. The number on their screen goes up, and that number is only a number.
In none of these four is any cryptography broken. In all four, a person was convinced to do something.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
Why one property decides every habit
When you make a mistaken payment with a bank card there is a route to complain, and in many cases the money comes back. The US Federal Trade Commission, on its own guidance page about cryptocurrency scams, has two short sentences that carry the whole difference: cryptocurrency payments typically are not reversible, and cryptocurrency payments do not come with the usual legal protections.
Irreversibility means that once a transaction is confirmed on the network, nobody, not an exchange, not the network, not us, has anything to take it back with. This is neither a defect nor a marketing feature; it is the same thing that makes a payment without an intermediary possible, and you are the one paying for it.
The practical result is that all of the security moves to before the button is pressed. In the card world some of the security happens after payment; here nothing happens after payment. Every habit you are about to read is really doing one job: opening a few seconds between being convinced and signing.
The six shapes that take the money, and the structural tell of each
This list is for recognition and not for fear. All six share one skeleton: a plausible pretext, an urgency, and at the end an action with no way back. What separates them is exactly what they ask of you at that end.
| Shape | What it claims | What it wants | The structural tell |
|---|---|---|---|
| Fake airdrop | free tokens have been allocated to you | a wallet connection and a signature | a thing that is free does not need a signature |
| Recovery phrase phishing | your wallet must be synced or verified | twelve or twenty four words | no service ever needs those words |
| Fake support | it is the support team of your wallet | the words, or remote access | real support does not message you first |
| A project that vanishes overnight | a new token or investment site | money, to buy in or deposit | they came to you, you did not go to them |
| Guaranteed returns | a fixed return with no risk | a deposit, usually followed by larger ones | the guarantee is itself the tell |
| A QR code instead of an address | it makes paying simpler | you to scan their code | you cannot see the destination unless you read it |
Three of these are stated outright on that same FTC guidance page, and the bluntness is worth quoting: only scammers demand payment in cryptocurrency, only scammers guarantee profits or big returns, and in many cases they direct you to scan a QR code they give you, which sends the payment straight into their own wallet.
Let us also bury an old tell here. For years people were told to spot these by bad language and spelling mistakes. That tell no longer works, because fluent error-free writing is effectively free today and the fake site can be just as clean and professional. The tells above are structural and do not fade as the surface improves: that you did not start the conversation, that something is being asked for which no real service asks, and that the action wanted from you cannot be undone. The more general forms of these same attacks have their own lessons in the security track.
The four demands every shape ends at
-
The recovery words
On any pretext: syncing, verification, recovery, support. There is no valid pretext for this request.
-
A signature, right now
To claim something free or to fix an urgent problem. The urgency is part of the tool, not part of the story.
-
A payment to an address they gave
As a text address or a QR code. The destination has to be read inside your own wallet, not on their page.
-
Access to your screen
A remote control app or screen sharing, to help. No real support desk asks for this for a wallet.
The outward look of each keeps changing. These four demands do not, which is why you memorise these rather than a list of scams.
The signature that does not send money but permits it
Some of the money lost in this field is not lost through a transfer; it is lost through a permission. The wallet does show you the difference, but it is rare for anyone to stop and read it.
The ERC-20 documentation on the Ethereum site lists, among the things the standard provides, this one: approve whether an amount of token from an account can be spent by a third-party account. The function is approve(address _spender, uint256 _value) and another one called allowance shows how much of that permission remains. Which means a contract can be allowed to spend from your address without anything leaving your balance at the moment you sign.
Three consequences follow, and all three matter in practice. First, connecting a wallet to a site is not the same as granting an approval: the first usually just reveals your address, the second grants an authority. Second, an approval stays where it is until you change it yourself; closing a browser tab does nothing to it. Third, an approval has a ceiling, and that ceiling can be a number so large it is unlimited in practice, which is exactly where the distance between use it once and use it whenever it likes disappears.
What follows from this is simple, and the fast path section of this page spells it out: before confirming, read the few fields the wallet is showing you; the function name, the address being granted, and the amount. If the amount is unlimited and what you want is one specific purchase, there is no reason to sign it.
The first hour: what you do and what you do not
If something has just happened, the order of what you do matters, and the first thing most people do is the wrong one: connecting to that same site again.
First work out which of the two happened, because the response is not the same. If a recovery phrase was entered somewhere, that wallet is no longer yours and changing a password means nothing; a completely new wallet with new words has to be created and whatever remains moved into it. If you signed something that was a spending approval, the wallet is still yours and the job is to set that approval back to zero from the same address.
Two things not to do. Do not get into a conversation with anyone offering help in a private message, because the news of your loss is visible in the same place where the loss happened, and that is what brings them. And do not trust any fund recovery service: somebody who says they will bring back what is gone for a percentage or an upfront payment is doing exactly what was done to you the first time. Irreversibility has no exceptions, and it has none here either.
And at the end one task that looks pointless and is not: write down everything you saw, the transaction hash, the addresses, the time and the text of the message. For your money it usually does nothing. For reporting to the service where it happened, and for whoever walks into that same page after you, it does something.
The first hour, in the order that actually makes a difference
-
1
Disconnect
Close the page and do not reconnect, not even to see what happened.
-
2
Work out which one happened
The words leaked, or only an approval was signed. The response is not the same.
-
3
Set the approval to zero
If it was an approval, set the ceiling to zero from the same address. Closing a tab does not remove it.
-
4
Build a fresh wallet
If the words leaked, new words are needed and whatever remains has to move.
-
5
Write it down
The transaction hash, the addresses, the time. Needed for reporting, usually not for your money.
-
6
Refuse the uninvited help
Private messages after a loss are the second wave of the same thing. A fund recovery service does not exist.
None of these steps brings back what is gone. What they do is stop the next step.
The habits that actually work and never make the lists
Security lists usually start with the big things. The things that actually prevent a loss are small and repetitive.
Keep a separate wallet for connecting to sites you do not know, and do not keep much in it. Every approval you give belongs to that wallet, and the worst case stays capped at that amount. The wallet holding the real money never connects to any site at all.
Before a large transfer, send one small test transfer and wait for it to arrive. You pay the fee and in exchange you learn that the address and the network are right, before the whole amount travels the same route.
Read the address off the device or wallet screen rather than off the website, and compare the destination in full rather than the first few characters. If you were handed a QR code, the address that appears inside your wallet after the scan is the one to read.
And the rule that pays more than all of these: if an offer came to you, it is not an offer. Opportunities somebody introduces in a private message, in a comment or in a group are worth, without exception, the few seconds it takes to close the window.
The fast path, with AI
Everybody says read before you confirm, without saying what exactly to read. A wallet confirmation screen shows a handful of fields written in the language of contracts, and an ordinary user walks past them. What a language model does well here is turning those few fields into one sentence: what this signature permits and what it does not. Nothing confidential moves in the process either, because what you copy is the public information already on the screen. A fast, cheap model of the Flash class is enough, and our current pick is listed in the AI section of this site.
- On the wallet confirmation screen, instead of pressing the button, open the transaction details. Most wallets have an option to see the full data.
- Copy four things: the function name, the address being granted, the amount or ceiling, and the network name. Your own address is not needed.
- Send the prompt below with those four values and ask it only what this signature makes possible.
- The last decision is yours and is not handed to the model: is the permission just described the size of the job you wanted done, or larger than it.
Copy-ready recipe
The prompt, with the four values you took off the confirmation screen:
A transaction on {network name} is on my wallet confirmation screen and
is not signed yet. Answer only from these values and guess nothing:
function name: {for example approve}
address being granted: {address}
amount or ceiling: {the number exactly as displayed}
token: {token name}
1) Does this signature move money now, or does it only grant permission?
2) If it is a permission, what can that address later do, and up to
what ceiling?
3) Is that ceiling bounded or effectively unlimited? If the number is
the largest possible value, say so.
4) How long does this permission last and what action removes it?
5) What cannot be known from these values?
Do not comment on whether that address is trustworthy; that is my job.Before you trust the output: Here is the main limit, and without it this exercise gives you misplaced confidence: understanding what a signature permits says nothing about the intent of the other side. A completely standard, perfectly valid request from a malicious contract looks exactly like this. So this path answers one question, what you are signing, and leaves the second one where it was: who is this address and why is it here. The second limit is simpler. A recovery phrase and a private key never enter this conversation; the four values above are everything needed and all of them are on the confirmation screen in front of you. And if the model writes a number or a name that was not among those four values, throw that sentence away.
AI in this kind of work
On this topic AI has two sides and both are real. The useful side is reading what an ordinary user never reads: the fields of a confirmation screen, a long English text, a long address. The other side is that the same capability has made a flawless scam message and a clean, professional-looking site cheap to produce, and has disabled the one tell we spent years teaching people.
Tools that actually help
- Gemini For turning the fields of a confirmation screen into one sentence, on its fast, cheap model. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
- Claude For when you want a terms text or a project page explained piece by piece with its claims separated out. Iran is on neither of Anthropic two supported-countries lists, and we read that on their own page.
- ChatGPT The same two jobs. We make no claim about access from Iran: OpenAI supported-countries page returns 403 to this server.
Where it backfires
The first risk has to be said without softening: the bad writing tell is dead. For years people were taught to spot a scam by broken language and clumsy translation, and today fluent text and a clean site are effectively free. If your detection rests on the quality of the writing, you have staked it on the cheapest thing to fix; the tells in this lesson are structural and do not fade as the surface improves. The second risk is asking a model is this project legitimate? or is this address safe? The model has no live data, has checked no address on any chain, and produces something with the shape of analysis and nothing behind it; in a field where every decision is irreversible, that is the most dangerous form an empty sentence can take. The third risk is links: do not take a download address or an official site address from a model, because a wrong link here means a fake app or a fake page. And the fourth is yours: a recovery phrase and a private key never go into any chat, and everything else you copy goes to another company too; whether content is retained or feeds training depends on the plan and settings of that service, which the companies write down, including on Google privacy page for the Gemini apps.
Sources: Google: Gemini Apps privacy Where you can use the Gemini web app Anthropic supported countries
Where this advice stops
The six shapes in this lesson are the common ones today and are not a complete list; their surface changes every few months, which is why we wrote the structural tells rather than sample texts. Where this lesson falls short is a targeted attack: a message that knows the name of your real project and comes from the genuine account of somebody who was compromised first. That message carries none of the tells above, and the only thing left in that situation is confirming through a second route before any signature and any transfer. The second boundary is the approvals section: what we wrote is conceptual and applies to contract-based networks; on networks without that concept the section does not apply. The third has to be said plainly: this page gives no advice about buying, selling or holding any asset, and offers no opinion on the legal status of crypto in Iran; we are not lawyers and the rules change.
From our own work
We run a crypto payment gateway on this site and we wrote it ourselves, and that same code taught us a few things that never appear on a security list. First, nowhere on that path, from the form to the chain watcher, is there a place to take a recovery phrase or a private key, and none is needed; the site shows an address and waits. Which means any request for those words on behalf of a service is false at the root, because services have no use for them. Second, we do not match an invoice by transaction hash, we match it by unique amount: the last digits of the amount are randomised so that an incoming payment binds to an invoice with no reference code at all. A picture of a transaction is worth nothing to us and never was; what is worth something is a record anybody can see on the chain. Third, the wait depends on the network and we fixed that in code: on the Tron network only finalised transactions are read and one confirmation is enough, while on the BNB network fifteen confirmations are required. And fourth, the most important: that code contains no path for sending money back, because the protocol contains none either. All it has is a seventy two hour window for claiming a transaction hash by hand and a twenty four hour grace period for a late payment, and both of those find money that arrived rather than recall money that left. When the party that wants to help has no button either, the first sentence of this lesson stops being a slogan.
Real follow-up questions
My money is gone; is there any way to get it back?
A transaction confirmed on the network does not come back, and no authority exists to bring it back. What remains is reporting to the service where it happened and recording the details. And a warning: anybody promising to recover the money for a percentage or an upfront payment is the second wave of the same scam.
I entered the wrong address; what happens?
If the address is malformed, most wallets refuse to send at all. If it is well formed but belongs to somebody else, the money went there and its return depends solely on that owner decision. And if it was sent on a network the recipient does not read, it usually does not exist for the recipient at all.
I only connected my wallet to a site and signed nothing; is there a risk?
Connecting on its own usually just gives that site your public address and moves no money by itself. What moves money, or permits it, is a signature. So if you approved no confirmation dialog, you are usually fine; what remains is to look through the approval list for that address once and set to zero whatever is not needed.