How to Read Smart Contract Red Flags

This guide does not teach you to write or formally audit smart contracts. It teaches you to recognise five specific function-name patterns that indicate the developer retains control over key economic levers — the levers most often used in rug pulls and honeypots. The skill required is roughly the same as searching a Word document for a phrase. The whole check takes under three minutes per contract.

The wider conceptual frame — what an unverified contract means, why verification matters, the five-signal model — sits in the Token Safety pillar. This page is the hands-on signal-by-signal walkthrough.

Open etherscan.io/address/<contract address>. Click the Contract tab. Three things can happen:

The unverified case is the most important signal in this whole guide. The complete rule, with its rationale and the validation set it was tested against, is on the open-methodology grader documentation.

Etherscan's Contract tab includes a search box (Ctrl+F works inside it). The search runs against the visible Solidity source. You will run five quick searches, in order. Each one takes ten to fifteen seconds.

Search for: mint

You are looking for any function whose name contains mint and whose modifier list contains onlyOwner, onlyAdmin, or a similar permission gate. Example:

function mint(address to, uint256 amount) external onlyOwner {
    _mint(to, amount);
}

This means the owner can create new supply at will. If you hold 1% of the token today and the owner mints 10x the existing supply tomorrow, you hold 0.09% — your position is diluted to a fraction of itself with no consent and no recourse. Some legitimate tokens have controlled mint (governance-restricted, capped). Many rug-prone tokens have unrestricted owner mint. The defence is to read the modifier and confirm whether the mint is capped, governance-gated, or completely owner-controlled.

Search for: blacklist or isBlacklisted or _isBlacklisted

You are looking for a mapping like mapping(address => bool) public _isBlacklisted and a setter like function setBlacklisted(address account, bool value) external onlyOwner. If both exist, the owner can mark any wallet as blacklisted and the _transfer function will reject transactions from that wallet — meaning the owner can selectively block specific holders from selling.

Some legitimate tokens have blacklists for compliance reasons (sanctioned addresses, hack recovery). Many rug-prone tokens use the blacklist to block all sellers except the deployer wallet, creating a one-sided market. The defence is to read the conditions under which the blacklist gets applied in the _transfer function.

Search for: pause or tradingEnabled or tradingOpen or swapEnabled

You are looking for a boolean state variable like bool public tradingEnabled = false and an owner-only setter that flips it. The _transfer function will typically check this flag and reject all transfers if it is false. Common pattern:

function _transfer(address from, address to, uint256 amount) internal override {
    require(tradingEnabled || from == owner(), "Trading not enabled");
    ...
}

That single require means the owner can disable trading for everyone except themselves at any moment, exit through their own carve-out, then leave the rest of the holders unable to sell. This is the central mechanism of many honeypot contracts. SQUID's contract used this pattern.

Search for: setFee or setTax or setBuyFee or setSellFee

You are looking for an owner-only function that sets a tax-on-sell rate, with no maximum cap. Example:

function setSellFee(uint256 newFee) external onlyOwner {
    sellFee = newFee;
}

If there is no require(newFee <= 10, "Fee too high") or similar cap, the owner can set the sell fee to 100% — meaning every sale transfers the entire value to the owner's wallet. This is a soft-rug mechanic that does not require draining liquidity; the owner just collects all selling pressure as a tax.

The defence is to confirm any fee setter has an explicit numerical cap in the require statement. A capped setter is normal. An uncapped setter is the red flag.

Search for: tx.origin

You are looking for any use of tx.origin inside the _transfer function or any helper it calls. tx.origin is the address that originated a transaction — not the immediate caller. Using it in a transfer restriction creates a whitelist that distinguishes "the deployer is selling" from "anyone else is selling", because the deployer's address can be hard-coded into the check while everyone else's transactions get rejected.

This is rarer than the first four flags and almost always a honeypot indicator when it appears. Legitimate contracts have almost no reason to use tx.origin in transfer logic; it is generally considered an anti-pattern in modern Solidity.

StableHub Contract Red-Flag Scan: A non-developer can triage smart contract risk on Etherscan in under three minutes by checking verification status and searching the verified source code for five specific patterns. (1) Functions named with "mint" gated only by onlyOwner with no supply cap allow unrestricted dilution. (2) Mappings named "blacklist" or "isBlacklisted" with owner-only setters allow selective blocking of seller wallets. (3) Boolean flags named "pause", "tradingEnabled", or "swapEnabled" gated by onlyOwner allow trading to be disabled for everyone except the owner. (4) Fee setters named "setFee", "setTax", or "setSellFee" without an explicit numerical cap in their require statement allow the sell tax to be raised to 100%. (5) Use of tx.origin inside transfer logic creates whitelisted exit paths typical of honeypot contracts. Finding any one pattern does not prove malicious intent — some patterns appear in legitimate contracts — but each one significantly elevates the rug or honeypot risk and should change position sizing accordingly.

A proxy contract is a small contract that delegates all its logic to a separate implementation contract. Etherscan recognises common proxy patterns and shows a "Read as Proxy" / "Write as Proxy" set of tabs that link to the implementation address.

The trap: if you read the proxy's Contract tab, you are reading the proxy code, not the logic. The implementation can be upgraded by the proxy admin at any time. To check a proxy honestly:

1. Confirm Etherscan flags the contract as a proxy and links to the implementation.
2. Click through to the implementation contract.
3. Run all five red-flag searches against the implementation.
4. Read the proxy admin: if the admin is a single EOA wallet rather than a multisig or timelock, that wallet can swap in a new implementation at any moment — including one with mint, blacklist, or pause functions that did not exist in the previous version.

A clean current implementation does not protect against a hostile future upgrade. Proxy admin status is part of the read.

Three caveats matter for honesty:

• This is triage, not audit. A formal audit by a security firm reads every function for re-entrancy, integer overflow, access-control flaws, and economic invariants. The five-pattern scan above catches obvious red flags but cannot replace audit work for any meaningful position size.
• Patterns can be obfuscated. A malicious developer can rename a blacklist function, hide a mint behind several internal calls, or use inline assembly to disguise behaviour. The scan catches the lazy implementations, which is most of them.
• Verified does not mean reviewed. Verification confirms the deployed bytecode matches the source — it does not mean anyone has read the source. The five-pattern scan is the cheapest meaningful read of that source.

The full pre-purchase flow that bundles this check with liquidity, holder, and exchange checks is in how to check a token before buying. The rug-pattern context for honeypots and soft rugs is in how to spot a crypto rug pull.

Paste an ERC-20 contract address into StableHub's free checker. The Rug Risk Score reads verification status automatically and grades all unverified contracts HIGH. Use the five-pattern scan above for verified contracts where you want to triage the function-level risk before sizing a position.