3 Red Flags in Smart Contracts I Look For Before Investing (A Solidity Dev’s Perspective)

I have been auditing smart contracts and developing in Solidity for years now. I spend my days staring at lines of code, looking for the one weakness that could drain a protocol or the one "backdoor" a developer left open to rug their community.

If you browse this subreddit, you know the game. You see a token, it has a cool name, a hype website, and "Devs Doxxed" plastered all over the Telegram group. You get FOMO, you buy in, and 12 hours later... the chart looks like a cliff, and the liquidity is gone.

Most people blame "whales" or "bad market conditions." But 90% of the time, the scam was written directly into the code before the token even launched.

The good news? You don't need to be a master coder to spot the worst offenders. You just need to know where to look on Etherscan or BscScan.

Here is a deep dive into the Top 3 Red Flags that I check instantly when I open a contract. If I see any of these, I don’t care how good the website looks—I run.

Red Flag #1: The "Honeypot" Switch (Hidden Trade Restrictions)

You’ve probably heard the term "Honeypot." This is when you can buy a token, but you can’t sell it. The chart looks amazing—only green candles! But that’s because nobody is allowed to sell except the developer.

How do they do it? It’s rarely as simple as a button labeled StopSelling. They hide it in the _transfer function.

What to look for: When I audit a contract for RD Auditors, I go straight to the _transfer function. This function is called every time tokens move from one wallet to another (buying or selling).

A clean contract usually looks like this: _transfer(sender, recipient, amount)

A malicious contract will have "conditions" attached to this transfer. Look for weird modifiers or "require" statements like:

require(isWhitelisted[sender], "Not allowed");

require(tradingOpen == true, "Trading paused");

The Scam: The developer will launch the token with tradingOpen = true. Everyone buys. Then, once the pot is big enough, they call a hidden function to set tradingOpen = false. Suddenly, your transaction fails every time you try to swap on Uniswap or PancakeSwap.

The "Blacklist" Trick: Some developers are smarter. They don't stop everyone from selling (because that looks suspicious on scanners). Instead, they let you buy, but the moment you buy, your wallet address gets automatically added to a isBlacklisted mapping. You are trapped individually, while new victims keep buying in.

My Advice: Check the "Read Contract" tab on the block explorer. If you see functions like blacklist, botList, or setMaxTxPercent, be extremely careful. Unless there is a very good reason for them (like actual bot protection), they are often used to freeze your funds.

Red Flag #2: The Hidden Mint (The Infinite Supply)

This is the classic "Rug Pull."

In a standard ERC-20 token, the TotalSupply is usually fixed. If it says 1,000,000 tokens, there should never be more than 1,000,000 tokens.

However, Solidity has a function called _mint(). This function creates new tokens out of thin air.

The Scam: The developer creates a token with a supply of 1 million. They lock the liquidity pool so you feel safe. "Liquidity Locked for 100 Years!" they scream.

But, they left a backdoor in the code that allows the owner to call mint().

You buy the token at $1.00.

The Developer calls mint(devWallet, 10,000,000,000).

Now they have billions of tokens.

They dump them all into the liquidity pool.

Because there is suddenly massive supply, the price crashes to $0.00000001 instantly.

What I look for: Search the code specifically for the word mint. In a safe contract, mint should only exist in the constructor (the part of code that runs once when the token is born). If you see a function like this:

function increaseSupply(uint256 amount) public onlyOwner {

_mint(msg.sender, amount);

}

Run. There is absolutely zero reason for a "meme coin" or a "community token" to have a mint function accessible by the owner after launch. If they can print money, your investment is worthless.

Red Flag #3: Unverified Source Code

This is the biggest red flag of them all, and yet people still fall for it every day.

When a developer deploys a smart contract, they upload "Bytecode" (a string of numbers and letters that computers understand but humans can't read). To prove they are honest, they are supposed to "Verify" the source code on Etherscan. This translates that gibberish back into readable English/Solidity so auditors like us can check it.

The Scam: If you go to the "Contract" tab on the explorer and it says:

"Are you the contract owner? Verify and Publish your source code today!"

Or you see just a wall of hex code (0x6080604052600436106100...)

DO NOT BUY.

If the code is unverified, you have no idea what it does. It could be a honeypot. It could have a 99% tax. It could just send your ETH directly to the dev's wallet.

Why do they do this? Scammers often claim: "We are keeping the code secret to protect our unique anti-bot tech!" or "We will verify after launch to prevent snipers!"

This is a lie. Legitimate projects verifying their code builds trust. Hiding code hides malicious intent.

The "Proxy" Trap: Sometimes, a contract is verified, but it’s a "Proxy Contract." This means the contract you are looking at is just a shell, and it points to another hidden contract for its logic. If you see "Implementation Address" or "DelegateCall" in a verified contract, you need to check the address it points to. Often, the main contract looks clean, but the hidden contract it points to contains the rug-pull code.

Bonus: The "Fake Renounce"

You’ll hear this a lot: "Ownership Renounced! Safe!" Renouncing ownership means the developer sets the owner address to 0x0000...dead. This means nobody can call those special onlyOwner functions anymore.

The Trick: I’ve seen contracts where the developer "renounces" ownership, but they defined a secondary owner role in the code called _marketingWallet or _devAddress.

So, the owner is gone, but the code says: modifier onlyAuthorized { require(msg.sender == owner || msg.sender == _marketingWallet); }

They still have full control. They just changed the name of the key.

Summary

Crypto is a dark forest. There are opportunities to make money, but there are thousands of predators waiting for you to slip up.

At RD Auditors, we use automated static analysis and manual line-by-line review to catch these things for our clients. But if you are joining a project on your own, please do these three checks:

Is the code verified? (If no -> SCAM).

Can the owner mint new tokens? (Search for "mint").

Are there weird restrictions on transfer? (Search for "tradingOpen" or "whitelist").

Stay safe, and verify before you trust.