Rug Pull Detection: A Guide to On-Chain Red Flags

Rug pulls are not random misfortune. They are designed in. The contract is written so that the team can drain the protocol, and on-chain you can almost always see it before the rug happens, if you know where to look. This piece walks through the rug-pull red flags we check on every due-diligence engagement, and the heuristics retail can apply with a block explorer and 15 minutes.

What "rug pull" means in practice

The term is used loosely. The useful taxonomy:

• Hard rug: the contract has explicit functions that let the deployer drain liquidity, mint unlimited tokens, or block selling. The exit was coded in. This is what most people mean by "rug pull."
• Soft rug: the team abandons the project after raising capital. Less malicious, but the holders are still left with an unsupported token.
• Slow rug: the team gradually sells holdings, pulls liquidity in tranches, and stops shipping. The price death spirals. Hard to distinguish from organic failure.

This piece focuses on hard rugs, the ones where the contract itself is the smoking gun.

Red flag 1: privileged mint functions

The single biggest hard-rug pattern: an onlyOwner (or equivalent) function that can mint arbitrary token amounts, with no cap. Sometimes labeled mint, sometimes hidden as claimRewards, airdrop, or setBalance.

What to check on a token contract:

• Is totalSupply capped, or can the owner mint more? Look for a MAX_SUPPLY constant or equivalent.
• Are mint-capable roles transferable? An onlyOwner mint where ownership is renounced to address(0) is far safer than one where ownership sits in an EOA.
• Is there a timelock? onlyOwner with a 30-second delay is functionally onlyOwner with no delay.

A clean token has either no mint function after deployment (fixed supply), or a mint function gated by a timelocked multi-sig with a published policy.

Red flag 2: liquidity that can be pulled

The classic rug: the team supplies all the liquidity to the AMM pool, then pulls it. To check:

• Liquidity holder concentration: who holds the LP tokens? If a single address (especially the deployer) holds >50%, they can drain.
• Liquidity lock: legitimate projects lock LP tokens with a verifiable lock contract (Unicrypt, Team.Finance) for a stated duration. The lock is a public address you can verify directly.
• Lock duration: a 30-day lock is not a lock. Real projects lock for 1+ years.
• Multiple pools: if liquidity is spread across multiple pairs (token/ETH, token/USDC, token/WBTC), pulling all of them simultaneously is harder to mask.

For a token claiming "liquidity is locked", verify the lock contract holds the LP tokens, the duration matches the claim, and the unlock date is real.

Red flag 3: blacklist and pause functions that block selling

A favourite rug pattern is a token contract that can pause transfers or blacklist addresses: used legitimately by the team to "block bots" pre-launch, used maliciously to block holders from selling once the price has been pumped.

What to check:

• pause() / unpause() functions controlled by an EOA or fast-acting role.
• blacklist(address) functions that prevent a specific address from transferring.
• Transfer logic that includes conditional reverts based on owner-set state.

A clean token either has no pause function (after launch), or has it gated by a timelocked governance process with documented use cases.

Red flag 4: malicious upgrade paths

For upgradeable contracts (proxies), the upgrade path is the contract. The current implementation can be replaced with a malicious one in a single transaction.

What to check:

• Who can upgrade? An EOA-controlled proxy is a rug waiting to happen.
• Is there a timelock on upgrades? 24-48 hours minimum gives users time to exit.
• Has the proxy admin renounced control? Sometimes shown as "ownership renounced": verify the admin slot, not just the implementation's owner().
• Are upgrade events publicly tracked? Legitimate projects publicise upgrade proposals.

Upgradeability is not inherently bad. It allows bug fixes and feature evolution. But upgrade-control concentration is the single most common path from "audited contract" to "drained protocol".

Red flag 5: missing or shallow audits

A "smart contract audit report" that:

• Lists only auto-tool output (Slither, Mythril dump).
• Has no scope statement.
• Doesn't name specific auditors.
• Was performed weeks before launch with no time for fixes.
• Has no re-audit section.

…is closer to a marketing checkbox than a security artifact. Our guide on reading audit reports walks through what credible reports actually contain.

The presence of an audit is not safety. The absence of one is a red flag, but a thin audit can be worse than none. It provides false confidence to retail.

Red flag 6: token holder concentration

A glance at the holder distribution tells you a lot:

• Top 10 holders should not control >50% of supply.
• The deployer wallet should be either renounced or hold a small allocation.
• "Marketing" or "treasury" wallets concentrated under EOAs are a slow-rug risk.
• Vesting contracts holding team allocation are good: verify the vesting contract, the cliff, and the duration are real.

Etherscan's "Holders" tab on any ERC-20 gives you this in 30 seconds.

Red flag 7: source code mismatch

Verify on the block explorer that the deployed contract is verified (source published) and matches what was audited. Common patterns:

• Contract is unverified: you have no idea what's running.
• Contract is verified but the source diverges from the audit's commit hash.
• Multiple proxy targets exist; the audit covered one but not the current one.

Etherscan / Routescan / equivalent block explorers show "Contract Source Code Verified" on the contract page. If it's missing, the project chose to ship opaque bytecode. That choice has implications.

What the on-chain trace looks like after a rug

For completeness, the post-rug pattern is consistent:

1. Liquidity is removed in a single transaction (or a small burst).
2. Token is dumped into the residual pool.
3. Funds are moved through a mixer (Tornado, eXch) or bridged to a different chain.
4. The deployer's social accounts go dark, sometimes deleted.
5. A new "team" emerges weeks later under a new project name with the same wallet patterns.

This is where incident response and on-chain forensics comes in: tracing the funds across mixers and bridges, coordinating with off-ramps, and producing the documentation that enables recovery weeks or months later.

When to engage professional due diligence

For institutional capital allocators, individual checking isn't enough. A formal pre-investment due diligence on a DeFi protocol covers all of the above plus:

• Code review of in-scope contracts.
• On-chain analysis of related deployer wallets and prior projects.
• Team background verification.
• Liquidity sustainability modeling.

If you are deploying meaningful capital into a DeFi position, a scoped due diligence engagement is cheap insurance compared to the position size.