Everyone tells you to buy an ERC-20 token. Almost nobody tells you what that means or how it goes wrong.

I remember staring at Ethers can at around 1 a.m., refreshing the page like it would change something. Green checkmark. Transaction successful. And my tokens, about $400 worth [YOUR DETAIL: amount and year], sitting in a contract that had no idea what to do with them.

I wrote to support. I posted on Reddit. A kind stranger explained, politely, that the money was gone. Not lost, not delayed. Gone.

That night I realized I’d been buying and sending “ERC-20 tokens” for months without knowing what the term meant. So I went and learned. This is what I wish somebody had told me first.

ERC-20 is just a set of rules

That’s all it is. No mystery.

In 2015, Fabian Vogelsteller and Vitalik Buterin put forward a proposal for how tokens on Ethereum should behave. Before then, every project built its tokens however it liked, and a wallet that supported one coin might choke on the next. Think of a drawer full of chargers that all almost fit.

The ERC-20 rules fixed it. If a token follows them, any wallet or exchange on Ethereum can handle it without special code. The rules are six functions and two events. Check a balance, send tokens, see the total supply. And one slightly scary pair, approve and transferFrom, which let someone else spend your tokens. Hold that thought, because it comes up again below.

The reason this mattered so much is that it made launching a token almost embarrassingly easy. You didn’t need your own blockchain anymore. A developer with a free afternoon could write a small contract, deploy it, and have a coin that showed up in MetaMask by dinner. That’s how we got the 2017 ICO craze, and honestly, a lot of garbage along with the good stuff.

Today the big names you probably already hold work this way. Tether and USD Coin on Ethereum, Chainlink, Uniswap. When people say “the crypto ecosystem,” a big chunk of it is just contracts following this one old rulebook.

The approve button

Now the part that actually costs people money.

When you swap on a decentralised exchange, your wallet asks you to approve a token. You click it. Everybody clicks it. I did for a year without thinking.

What you’ve done is give a smart contract permission to take tokens out of your wallet. And many apps ask for an unlimited amount by default, so you never have to approve again. Convenient. Also, a loose key under the doormat.

If that app gets exploited six months later, the attacker doesn’t need your password. The permission you gave is still sitting there. A lot of “my wallet got drained, and I didn’t do anything” stories are exactly this. They did do something. They clicked approve in March and forgot.

So I do three boring things now. I set a custom amount instead of unlimited when the wallet lets me. Every month or so I open Revoke. cash, look at the list of contracts I’ve approved, and cancel the ones I’m not using. And I keep a second wallet for experiments, so the one holding real savings never touches a sketchy site.

Ten minutes. Genuinely worth it.

Back to my $400

Here’s what happened to me, and it’s baked into the standard itself.

The transfer function in ERC-20 doesn’t check whether the receiver can handle tokens. It subtracts from your balance, adds to theirs, and moves on. If you send tokens to a regular wallet, fine. If you send them to a smart contract that wasn’t built to receive and return them, they sit there forever, because the contract has no function to send them back out.

Developers have complained about this for years. Over time, huge amounts of tokens have ended up stranded in contracts this way, and nobody can touch them. Newer standards like ERC-223 tried to patch it. They didn’t take over, because by then the whole industry was built around ERC-20. Wallets, exchanges, lending apps. Replacing it would be like trying to replace the QWERTY keyboard. Flawed, familiar, and not going anywhere.

There’s a cousin of my mistake that catches even more people: the wrong network. USDT exists on Ethereum, Tron, and other chains, and the addresses can look similar. Send it over the wrong network to an exchange that doesn’t support it and you can be in for a long, painful support ticket, or no recovery at all. Always check which network you’re sending on, and send a tiny test amount first. I know it feels silly. Do it anyway.

Before you buy any ERC-20 token

Here’s something that surprised me. Calling a token “ERC-20” says nothing about quality. Anyone can make one in a few minutes, for free, with no approval from anyone. A scam coin and a serious project use the same standard.

So I run a short check every time.

First, the contract address. Scammers copy the name and logo of real tokens, and fake versions pop up constantly. I get the address from the project’s official site or Coin Gecko, never from a reply under a tweet.

Second, who owns the supply? Etherscan has a holders tab. If three wallets own 80% of everything, those three can crash the price whenever they feel like it. Not always a scam, but it should make you think.

Third, whether the code is verified on Etherscan and whether a known firm audited it. An audit isn’t a guarantee. Plenty of audited projects have still been hacked. But a big project with neither? I walk away.

I’m not a financial advisor, and this isn’t financial advice. It’s just the checklist I wish I’d had at 1 a.m. staring at that checkmark.

What this taught me

I used to think crypto was either genius or fraud, depending on who was shouting. ERC-20 changed my mind a bit. It’s a tool. A clever, simple, slightly flawed tool that lets anyone create digital money without asking permission.

That freedom is the whole appeal, and it’s also exactly why nobody is going to save you when you slip. The code does what it says, not what you assumed it said. No one picks up the phone.

You don’t have to become a developer. You just have to know what you’re clicking, and slow down for a few seconds before you do.

I paid $400 to learn that. If this post saves you the tuition, good.

Have you ever been burned by an approval or a wrong-address transfer? Tell me in the comments. Somebody scrolling by might dodge the same hole.

I Sent Crypto to the Wrong Address and Nobody Could Help Me. Learn From My Mess (ERC-20 Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you take card payments, even five a day, read this before your bank emails you first.

The mistake is simple. You think your payment provider takes care of PCI DSS for you.

It doesn’t. Some of it, sure. But if your checkout page looks like most checkout pages, a big chunk of the responsibility is still sitting on your desk.

[Add two or three sentences of your own here. A time you or a client assumed “Stripe handles it” and found out otherwise. Real beats polished.]

I’ll get to the gap in a second. First, the title.

Is it actually illegal?

Mostly no, and I’d rather say so now than have someone say it for me in the comments.

PCI DSS isn’t a federal law. The card brands wrote it, and you agreed to it when you signed your merchant agreement, probably without reading page nine. Break it and your bank can fine you, raise your fees, or close your account.

But a few US states have pulled PCI DSS into their own law. Nevada is the best known. Minnesota and Washington have versions too. And after a breach, nobody asks whether the standard was legally binding. They ask whether you followed it. A lawyer on the other side will enjoy that question.

So “breaking the law” is a little strong, and “breaking your contract” is accurate nearly everywhere. Either way, you don’t want to be there.

Who’s living on your checkout page?

Open your checkout page. Right-click, view source, and search for “script.”

Go on. I’ll wait.

Analytics. A chat widget. Maybe a heatmap tool somebody trialled once. A font library. A retargeting pixel from a campaign in 2022 that nobody turned off. Every one of those is code written by a stranger, running in the same window where your customer types a card number.

Attackers love this. It’s called web skimming, and you’ll also see the name Magecart. They don’t bother attacking your bank. They compromise one small third-party script, add a few lines of JavaScript, and copy card details as people type. Your site looks fine. Your processor sees normal transactions. It can go on for weeks.

This is the gap. Your provider secures its side. It has no control over the fifteen scripts you invited onto your side.

What changed, and why old blog posts will mislead you

The old version, 3.2.1, was retired in March 2024. Version 4.0 replaced it, and a batch of requirements that started out as “best practice” became mandatory on March 31, 2025. The current release, 4.0.1, only clarifies wording. It doesn’t relax anything.

Two of the new rules hit online sellers hardest.

Requirement 6.4.3 says you need an inventory of every script on your payment pages. You have to confirm each is authorized and write down why it’s there.

Requirement 11.6.1 says you need a way to detect unauthorized changes to those pages and be alerted when something shifts.

So if nobody on your team can name every script on your checkout, you have a compliance problem and a security problem. They happen to be the same problem, which is almost funny.

What it costs when it goes wrong

The card brands don’t bill you directly. They penalize your acquiring bank, and the bank passes it along, usually with a little extra for its trouble. Figures commonly reported run from about $5,000 to $100,000 a month of non-compliance, depending on your size and how long it drags on.

That’s the fine. A real breach is its own bill: forensic investigators, reissuing cards, lawyers, notifying customers, and the quiet loss of people who just stop buying from you.

Target in 2013 is the example everyone uses, because it’s true. Attackers got in through a third-party vendor (an HVAC contractor, of all things) and left with around 40 million payment card records. A company that size absorbs it. A small shop usually can’t.

What to do this week

None of this is glamorous. That’s sort of the point.

Start by asking your bank or processor which Self-Assessment Questionnaire applies to you. It depends on how card data touches your business, and plenty of merchants fill out the wrong one. They end up compliant on paper and exposed in practice.

Then shrink your scope. If you use a fully hosted payment page or tokenization, card numbers never touch your servers, and that’s less for you to secure and explain. Do an audit of your payment page scripts while you’re at it, and delete anything that isn’t earning its spot. Your heatmap tool doesn’t need to sit next to the card field.

Never store the CVV after authorization. Ever. Turn on multi-factor authentication for any account that can reach card data. If you’re required to run quarterly external scans, use an Approved Scanning Vendor and put the dates in your calendar, because PCI DSS is yearly, not once and done.

And write a security policy. One page is fine. One page your team has read beats sixty pages nobody opened.

The honest takeaway

I don’t think PCI DSS exists to make your life miserable, though it can feel that way around audit time. It exists because card fraud is automated and endless, and small merchants are favorite targets because they assume nobody’s watching.

The businesses that stay out of trouble mostly aren’t the ones with big security budgets. They just ask three dull questions early. What touches card data? Who has access to it? What’s running on my checkout page?

Ask them this week. Your future self will be grateful, and so will your bank.

Do you know which SAQ applies to your business? Tell me in the comments. [Add your own honest answer here.]

This is general information, not legal or compliance advice. Confirm your requirements with your acquiring bank or a Qualified Security Assessor.

Your Payment Page Is Probably Breaking the Law. Here’s the PCI DSS Mistake Nobody Tells You About was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.