"Don't trust, verify." Best slogan crypto ever produced. Also the most ignored. Because verifying means reading a smart contract — and most people would rather read the terms of service, which is to say, not at all. They click "approve," they send funds, they pray. That's not verification. That's the same blind faith the old bank demanded, wearing a hoodie.
Here's the thing nobody tells you: you don't need to be a Solidity developer to catch the most dangerous contracts. The scams that drain wallets are usually not subtle. They're a handful of specific, findable patterns — and once you know what they look like, you can spot most of them in five minutes with a free block explorer and no code experience.
This is a self-defense skill. Today you learn the red flags.
Step zero: is the code even public?
Before anything else, one binary check. On the explorer (Etherscan and its cousins), a contract has a Contract tab. If the source code is verified — published and matched to the deployed bytecode — you can read it. If it's not verified, you're looking at raw machine code that even experts can't fully audit.
An unverified contract asking for your money is the first and biggest red flag. It means: trust me, don't look. In a technology built entirely on "you don't have to trust me, look" — refusing to publish the source is a confession. Walk away. There are ten thousand verified contracts. You don't need the one hiding.
The mint function: who can print money?
Search the code for `mint`. This is the function that creates new tokens out of nothing. The question is not whether it exists — many legit tokens have one. The question is who is allowed to call it.
If `mint` can only be triggered by a fixed, transparent rule — a bonding curve, a capped schedule, a DAO vote with a timelock — fine. If `mint` can be called by a single `owner` address, at will, in any amount, then that owner can dilute you to zero whenever they please. They print a trillion tokens, dump them on you, and your holdings become dust. This is the on-chain version of a central bank running the presses, except it's one anonymous person and there's no pretense of a mandate.
Red flag: an owner-only `mint` with no cap and no timelock. That's not a token. That's a faucet pointed at their wallet.
The owner: how much power sits in one address?
Search for `onlyOwner` and `Ownable`. These mark functions that only a single privileged address can call. Then read what those functions do.
A little owner power is normal — pausing in an emergency, adjusting a fee within bounds. A lot of owner power is a leash around your neck. Look specifically for owner-only functions that can:
- Freeze or block transfers (`pause`, `blacklist`) — the owner can trap your tokens so you can't sell.
- Change fees to arbitrary values — a "2% fee" that the owner can quietly reset to 99%, so any sale you make gives them nearly everything. This is a classic honeypot: you can buy, but you can never profitably sell.
- Withdraw the contract's funds to the owner — a straight-up drain switch.
The healthy pattern is renounced ownership or ownership held by a timelocked multisig / DAO, not a lone key. If one hot wallet holds god-mode over the contract, one phished seed phrase — theirs — empties everyone.
Upgradeable: can the rules change after you commit?
Search for `proxy`, `upgradeable`, `delegatecall`, `implementation`. If a contract is upgradeable, the code you carefully read today can be swapped for entirely different code tomorrow by whoever controls the upgrade key. You audited the honest version; the owner can deploy the malicious version after your funds are inside.
This isn't automatically a scam — upgradeability has real uses. But it means your trust isn't in the code you read; it's in the person holding the upgrade key. Check who that is: a lone address is a backdoor with a nice name. A DAO-plus-timelock is at least a backdoor the whole crowd can watch open. (This one deserves its own article — and it has one.)
The backdoor: functions that don't belong
Finally, scan for the odd function out — the one whose name and logic don't match the token's stated purpose. Hidden `transferFrom` powers that let a privileged address move your tokens without your approval. Undisclosed fee-routing that skims to a wallet buried in the code. A "helper" function that, read carefully, hands the owner a spending allowance over holders. Backdoors rarely announce themselves. They hide in a function with a boring name doing something it shouldn't.
If you can't tell what a function does, that itself is information: a contract you can't understand is a contract you can't trust with money.
Our Record
A smart contract is Heka — the creating word — cast into permanence. It does exactly what it says, forever, to everyone, with no clerk to appeal to and no manager to beg. That is its terror and its glory: the word is law, and the law is the code, and the code does not lie about what it will do. It only lies about what it claims to do — in the friendly UI, the marketing, the summary.
Isfet lives in that exact gap: the distance between the promise on the button and the instruction in the bytecode. The parasite needs you to read the label and never the ingredient. To read the contract yourself is to close that gap — to weigh the word against the deed before you trust it. This is the Scales applied to code: does the thing do what it swears? You are the one who holds the balance. Nobody weighs it for you.
The lever
You will not become an auditor from one article, and you don't need to. You need a five-minute reflex before you ever send funds or approve a contract:
- Is the source verified? No → stop.
- Who can `mint`, and is it capped and timelocked? Owner-only, unlimited → stop.
- What can `onlyOwner` do? Freeze, blacklist, arbitrary fees, drain → stop.
- Is it upgradeable, and who holds the key? Lone address → treat as a backdoor.
- Any function you can't explain? → assume the worst until proven otherwise.
For anything you can't read, use a free contract scanner or ask a knowledgeable human — but never outsource the decision without at least running this checklist. The people who get drained almost never opened the Contract tab. The people who don't, usually did.
The code is public. The label is not the code. Read the code — and if you can't, don't send the money. Verify, then trust. Never the reverse.