Rug Pull & Honeypot Scanners, Liquidity Pool Security Sites

Rug Pull & Honeypot Scanners: The Fastest Way to Check Token & LP Security (Before You Buy)

Ever stared at a fresh token, felt the FOMO, and asked yourself: “Is this thing safe to buy… or am I about to get trapped?”

That’s exactly what this category is here for. I built this guide to show you which rug pull and honeypot scanners actually help, what their results really mean, and how to spot the red flags most people miss—fast.

If you want fewer nasty surprises and more confident trades, you’re in the right place. I’ll keep this page updated with tools, short workflows, and answers to the questions I get every day, so you can check token and LP security in minutes, not hours.

Why traders still get trapped (even with scanners)

Rug pulls, honeypots, stealth taxes, and unlocked liquidity wipe out portfolios every single day. Scanners exist, but a few things trip people up:

• Trusting one score. A green badge can’t protect you from a sneaky owner function or a proxy upgrade waiting to flip later.


• Not knowing what warnings mean. “Owner can set fees” or “Liquidity not locked” sounds obvious, but how risky is that in context? It depends.


• Blind spots. Scammers tweak contracts to bypass simple checks, hide blacklist logic, or use delayed switches that only trigger after liquidity builds.

Real-world pain? You’ve seen it. The infamous “Squid Game” token pumped hard, then became unsellable—a textbook honeypot. And in Oct 2022, a flaw related to a popular locker contributed to millions siphoned, proving even “locked” liquidity isn’t a silver bullet.

It’s not just anecdotes. Chainalysis research has shown rug pulls made up a large chunk of scam revenue in 2021, and Solidus Labs has flagged hundreds of thousands of tokens with scam traits across major chains. Bottom line: attackers adapt, and they adapt fast.

What you’ll get here

I’ll show you how the best scanners work, how to combine them, and what simple manual checks to run so you’re not relying on a single “OK” stamp.

• Read LP locks the right way: locked, burned, or rug-ready?


• Spot contract powers: ownership, mint, blacklist, and tax edits.


• Catch stealth traps: asymmetric sell taxes, max wallet/tx, and trading toggles.


• Run a tiny test trade safely (and revoke approvals after).

Quick truth: Scanners are your first filter, not your final answer. Use them to narrow the field, then verify the parts that matter.

Mini FAQ: fast answers to the questions I get every day

• “Are scanners accurate?” They’re good at catching common patterns, but they’re not perfect. Treat them as alerts, not guarantees.


• “What’s the fastest check?” Paste the contract into two scanners, confirm LP lock/burn, glance at owner permissions, then test a tiny buy/sell.


• “How do I avoid fake tickers?” Always start on the official block explorer page for the contract. Don’t search by name.


• “What tax is ‘normal’?” Launches may run higher, but extreme or asymmetric sell taxes are a red flag. If sell tax looks >10–12%, pause.

The starter stack I actually use (short list)

Use two or three—never just one. Each catches different things.

• Token scanners:TokenSniffer, Honeypot.is, GoPlus Token Security, De.Fi Scanner, RugDoc (notes)


• LP and pools:Team Finance, Unicrypt, DexTools, DexScreener


• Explorers & extras:Etherscan/BSCScan for holders and source, BubbleMaps for wallet clusters

Fast pre-buy checklist (60 seconds)

• Start with the contract address on the official explorer page. Avoid copycat tickers.


• Run two scanners. If either throws high-risk on LP, taxes, blacklist, or mint, stop and investigate.


• Check LP status. Locked or burned? For how long? Who controls the lock?


• Look at owner powers. Can they set taxes, blacklist, mint, or pause trading?


• Holder spread. Any whale or team cluster sitting on 30%+? That’s a risk.


• Tiny test trade. If everything looks fine, buy and sell a tiny amount to confirm you can exit. Then limit approvals and be ready to revoke.

All of this sounds simple once you’ve done it a few times. The trick is knowing why each check matters—and what patterns scream “rug” vs. “honeypot.”

So here’s the question: what’s the actual difference between a rug pull and a honeypot on-chain, and why do you need different checks for each? Let’s break that down next.

Rug pull vs. honeypot: what’s the difference and why it matters

Two scams, same result: your balance goes to zero. But on-chain, they look very different—and that’s why you need different checks to catch them.

“Trust the math, not the marketing.”

Think of a rug pull as the floor vanishing under the chart. Think of a honeypot as the door locking the moment you step inside. Both are avoidable if you know what to look for.

What is a rug pull?

A rug pull is when the team removes price support or floods supply so fast that the market collapses. The classic move is yanking liquidity, but there are sneakier versions that look legit—until they aren’t.

How rugs happen on-chain:

• LP withdrawals: Liquidity provider (LP) tokens are not locked or burned, so the deployer withdraws the pool. Price craters to near-zero because buyers can’t exit against real liquidity.


• Mint-and-dump: Contract keeps a mint function live. Team mints a huge bag after launch and sells into the pool. Supply balloons, price implodes.


• Ownership abuse: The owner can change taxes, limits, or trading settings. A sudden 40–99% sell tax or a hard trading toggle traps liquidity and drains confidence.


• Migration/migrator tricks: “Upgrade” or “migrator” functions move liquidity or tokens to a new contract the team controls, then they pull the funds there. No warning, instant loss.

Real-world snapshots:

• AnubisDAO (2021): $60M in ETH vanished after contributors sent funds to a contract without a proper multisig; the deployer moved liquidity out quickly. Classic liquidity control risk.


• Chef Nomi (early SushiSwap drama): Massive dev fund withdrawal shocked markets (later returned), proving one keyholder with privileges can nuke trust in one transaction.

On a chart: Rugs look like a sheer vertical drop with no bounce, usually right after a liquidity move or a big mint. On-chain, you’ll see LP tokens moving out or a spike in supply from a mint function.

What is a honeypot?

A honeypot lets you buy but makes it impossible—or brutally expensive—to sell. The code doesn’t need to say “no selling.” It just needs to make selling fail or bleed you dry.

How honeypots trap you:

• Sell reverts: The transfer logic checks if the receiver is the DEX pair; if true, it requires a special flag or whitelist. Your sell fails with a revert message (or no message at all).


• Hidden taxes: A “normal” buy tax but a 50–100% sell tax that’s toggled on after hype. It isn’t a technical block, but it’s financially the same—you get pennies back.


• Blacklist logic: Addresses can be marked as blocked after buying. You’re not banned from transfers to friends, only from selling to the pair.


• Tiny maxTx or maxWallet on sells: A microscopic sell limit (e.g., 0.0001% of supply) makes realistic exits impossible, especially when gas and price impact add up.

Real-world snapshots:

• SQUID (2021): Buyers piled in as the token went viral; selling failed due to anti-sell logic tied to “game” rules. Liquidity drain followed. A hybrid honeypot-rug—textbook pain.


• Common BSC patterns: Bots and retail buy without checking sell paths; sell attempts revert or return dust after a silent fee change. Tools like Honeypot.is became popular for a reason.

On-chain tell: Successful buys and transfers between wallets, but repeated sell transactions revert when the destination is the pair, or they confirm with a 90%+ tax. The contract often hides the logic inside an overridden _transfer with flags like tradingEnabled, isWhitelisted, or fee multipliers set by the owner.

Why scanners are your first filter, not your final answer

Scanners are great for catching patterns like unlocked LP, mintability, blacklist functions, or extreme taxes. They spot common tricks fast and save you time. But attackers adapt—especially on EVM chains where code can be obfuscated, proxied, or gated behind upgradeable patterns.

What scanners usually flag well:

• Unlocked or team-held LP


• Owner-only superpowers (mint, setTax, blacklist)


• Obvious honeypot behavior (sell fails on a test)

What can still slip through:

• Taxes that change after “go-live” or at specific block heights


• Proxy contracts where logic is swapped after launch


• Delayed traps—sell works until a switch flips

There’s data to back the caution: blockchain forensics firms have shown year after year that rug pulls and investment scams make up a large chunk of crypto losses, with billions siphoned across 2021–2023. The patterns evolve. Your process has to, too.

Bottom line: A rug pull kills the market by removing liquidity or exploding supply. A honeypot locks you inside by blocking or taxing sells into oblivion. The checks aren’t identical, so your workflow shouldn’t be either:

• For rugs: focus on LP lock/burn status, who holds LP tokens, mint/owner powers, and any migrator routes.


• For honeypots: focus on sell path logic, blacklist/whitelist controls, maxTx/maxWallet on sells, and tax toggles—then run a safe test trade.

Curious how most scanners decide what’s “risky,” why they sometimes panic you for no reason, and where false negatives really come from? Let’s unpack how these tools actually work next—so you can read their scores without guessing.

How rug pull and honeypot scanners actually work

Scanners aren’t crystal balls. They’re a set of on-chain rules and heuristics that try to predict behavior before it hurts you. They read the contract, query the pool, simulate trades, and spit out a risk score. Useful? Absolutely. Perfect? Not even close.

“Trust, but verify. The chain never lies—only people do.”

If you’ve ever wondered why one tool screams “high risk” while another shrugs “low,” it’s because each one weighs the same facts differently. Here’s what they actually check, where they fail, and how to keep your cool when a score turns red.

Core checks most scanners run

Most reputable scanners look at the same handful of things. They just package them differently and give you different thresholds for “safe.” Under the hood, you’ll usually see:

• LP lock/burn status: Reads the liquidity pair to see if LP tokens are sent to burn addresses like 0x0000…dead or locked via lockers (Team Finance/Unicrypt). If LP is unlocked, a sudden drain is possible.


• Owner/privileged roles: Pulls owner, admin, or role-based access for functions like “setFee,” “setBlacklist,” “mint,” or a “tradingEnabled” toggle. A single EOA with god-mode is a yellow-to-red flag.


• Buy/sell tax levels: Reads fee variables and routes (marketing, dev, liquidity). A 0–5% range is common; 10–12% can be okay at launch; anything extreme—or sell tax higher than buy—demands caution.


• Mint function and supply control: Checks if “mint” is present, who can call it, and whether max supply is enforced. Unlimited mint = instant pass for scammers to nuke you later.


• Blacklist/whitelist logic: Finds “blacklist,” “exclude,” or “onlyWhitelisted” gates, especially if these hit transfer or sell flows. This is how classic honeypots block you from exiting.


• Max wallet/tx parameters: Flags “maxTxAmount” or “maxWallet” that can look protective but trap sells when combined with other rules or sudden parameter changes.


• Trading toggles and launch guards: Sees if “tradingEnabled” or block-based anti-bot logic can stall your sells after hype. Legit teams use this early; bad ones keep the switch forever.


• Honeypot emulation: Tools like Honeypot.is simulate a buy/sell through popular routers to detect reverts, hidden megataxes, or selective blocking.


• Pool health: Reads pair age, depth, and presence on major DEXs to gauge if a pool is fresh bait. Tiny, brand-new pools with aggressive marketing are risky.


• Source verification and proxy map: Confirms verified source on explorers and checks if it’s a proxy (EIP-1967/UUPS). If the logic can change after launch, that impacts risk.

Scoring is usually a weighted sum: LP safety, permissions, fee logic, and trade simulation carry most of the weight. For example, TokenSniffer factors code clones, liquidity, and ownership into a 0–100 score; GoPlus displays per-risk flags (mint, blacklist, etc.) you can evaluate line by line; De.Fi Scanner blends static checks with reputation databases.

Why does this matter? Because scammers know which checks exist—and code around them. Research from Chainalysis and Solidus Labs shows billions siphoned via rug-style schemes and hundreds of thousands of suspicious tokens launched across major chains. Pattern-matching protects you from the common tricks; edge cases still slip through.

Where scanners can miss

Attackers don’t need to be smarter than every tool—they just need one blind spot. Here are the popular blind spots I keep seeing (and what they look like in the wild):

• Upgradeable proxies that look “renounced”: The implementation contract might be renounced, but the proxy admin can swap logic later. If the admin isn’t timelocked or multisigged, your risk is not gone.


• Hidden external calls: Fees routed to a separate “helper” contract with its own blacklist or tax switches. Scanners focused on a single contract can miss this hop.


• Delayed or block-based switches: Sell works during tests; after liquidity grows or a certain block height passes, a revert triggers. Early scans look green; post-hype behavior turns red.


• Router-specific honeypots: Sells only fail when using popular routers, but succeed for whitelisted wallets. A basic emulation might pick the “safe” route and miss the trap.


• Obfuscated or unverified code: Without verified source, scanners rely on bytecode signatures. Clever obfuscation hides blacklist logic or fee math changes.


• LP migrators and wrappers: Migration functions (infamous “migrator” patterns) move LP to a new pool you don’t control. Many scanners flag this, but not all recognize custom migrators.


• Off-chain traps: Perfectly fine contract, malicious front end. The site slips you a fake router, or a phishing “approve unlimited” that drains unrelated tokens. Scanners don’t save you here.


• Multiple pools and spoofing: You scan the clean pool; trades route to a different, fee-heavy pool. Always check the actual pair your DEX will use.

Real-world example: the 2021 “SQUID” token blocked sells by allowing only whitelisted addresses to exit—an archetypal honeypot pattern. Many users relied on FOMO instead of reading the sell path. That’s exactly the kind of simple logic that scanners do flag today—but refined versions still appear with timing delays or router-targeted checks.

How to read scores without panicking

Green ≠ safe. Red ≠ instant scam. Context is everything. Here’s how I interpret scanner output without losing the plot:

• Green score, one or two yellows: I check what they are. Example: unrenounced owner but secured by a reputable multisig with a public timelock? That’s acceptable. Launch-only anti-bot limits? Fine if they’re removed and verifiable.


• Mixed signals across tools: I side with the stricter result and run manual checks. If one says “low tax” and another shows 20% sell, I assume 20% until I see the variables and a test sell confirms it.


• High risk tags that don’t scare me (with proof):
  
  
  
  • Proxy present, but the proxy admin is a well-known multisig + timelock.
  
  
  • Owner not renounced, but fees and blacklist functions are removed or timelocked on-chain.
  
  
  • Moderate taxes during the first hours of launch, with clear, on-chain reductions as TVL grows.
  
  
  
  


• Hard-pass flags (I don’t negotiate with these):
  
  
  
  • Unlimited mint or supply control by a single EOA.
  
  
  • Blacklist/whitelist that can target arbitrary wallets post-launch.
  
  
  • LP unlocked or “locked” to a team-controlled wallet or sketchy locker.
  
  
  • Migrator functions with no public plan or community oversight.
  
  
  • Extreme or asymmetric sell taxes that can be changed at any time.
  
  
  • Unverified source combined with privileges. If I can’t read it, I assume the worst.
  
  
  
  

One more emotional truth: impatience is the scammer’s favorite co-conspirator. If a score nudges you to rush or ignore a red flag, hit pause. The market always offers another trade; you only get one bankroll.

Want a fast, repeatable way to apply all this in 3–5 minutes before you buy? In the next section I’ll show you the exact workflow I use—from pasting the right contract to a safe test sell. Ready to see it step-by-step?

Step-by-step: run a token through scanners and sanity checks

“Fast is fine. Accurate is better.”

I keep this workflow taped to my monitor. It takes 3–5 minutes and has saved me from more traps than I can count. Use it exactly once and you’ll wonder how you ever clicked buy without it.

Paste contract address, not the token name

Names are easy to spoof. Contract addresses aren’t. I always start on the block explorer, never a DEX search box.

• Get the address from a trusted source: the project’s pinned post on X, the official site’s footer, or a verified listing (e.g., CoinGecko). Cross-check that address appears on the project’s GitHub or docs too.


• Open the token on the explorer (e.g., Etherscan, BscScan): confirm the chain, symbol, decimals, and that the source code is verified. If it’s a proxy, Etherscan will show “Proxy: Yes.” Click through to the implementation.


• Check the creator and first transactions: sudden minting, stealth deploys, or creator wallets that tie back to known rugs are instant pass.


• Skip ticker searches on DEX UIs: scammers clone names by the dozen. In late 2021, “SQUID” lookalikes exploded while the real honeypot blocked sells—users learned the hard way that names mean nothing.

Tip: watch out for address-poisoning scams where your history shows lookalike addresses. Always copy from the source you trust, not your wallet history.

Check LP status and ownership

Next I confirm who controls the liquidity and who controls the contract. This part is quick—and critical.

• Find the main pool: open the token on DexScreener or DexTools, pick the highest-liquidity pair, then click through to the “Pair” contract on the explorer.


• See where LP tokens live:
  
  
  
  • Burned: LP tokens sent to 0xdead or 0x00…00. Good sign, but still verify it’s the real LP.
  
  
  • Locked: LP held by lockers like Unicrypt or Team Finance. Click the locker contract and check the unlock date and amount. Short locks around hype windows are a red flag.
  
  
  • Held by a wallet: if a single wallet holds most LP and it’s not a multisig, that’s rug-ready territory.
  
  
  
  


• Check contract ownership: in “Read/Write Contract,” find the owner. Renounced (0x00…00 or 0xdead) reduces some risks. Non-renounced is acceptable only if it’s a reputable multisig with a public team and ideally a timelock.


• Watch for migrators and proxies: a “migrator” function or upgradeable proxy can move liquidity or change logic after launch. If Proxy: Yes, inspect the implementation and any admin keys.

Reality check: large exploits have hit lockers themselves (a 2022 incident saw millions siphoned via a flawed migration path). That’s why I confirm what is locked, how long, and who can touch it—don’t just stop at a pretty “LP locked” badge.

Taxes, limits, and blacklist traps

Now I sanity-check the token’s rules—the same ones scanners flag—but I always verify them myself.

• Run two scanners: plug the contract into:
  
  
  
  • TokenSniffer or GoPlus Token Security for tax/mint/blacklist checks
  
  
  • Honeypot.is for a simulated buy/sell on supported chains
  
  
  
  Cross-reference results; if they disagree, I treat the stricter result as the baseline and check manually.


• Manual reads I care about (in the Contract tab):
  
  
  
  • Fee/tax setters: setTax, setFees, setSellFee (especially if owner can change them post-launch)
  
  
  • Trading gatekeepers: setTradingEnabled, enableTrading, openTrading
  
  
  • Blacklist/whitelist: setBlacklist, blacklistAddress, isBlacklisted
  
  
  • Limits: setMaxTxAmount, setMaxWallet, transferDelayEnabled
  
  
  • Mint/burn powers: mint, setMinter, burnFrom
  
  
  
  


• Numbers that make me pause:
  
  
  
  • Sell tax above 10–12% or adjustable by owner without a timelock
  
  
  • Max wallet/tx under ~1% of supply while LP is thin (easy to trap exits)
  
  
  • Blacklist present and owner is not renounced or timelocked
  
  
  • Trading toggle still off while the chart is moving (stealth allowlists = danger)
  
  
  
  

Patterns repeat. In 2021–2023, countless BSC honeypots used adjustable fees and blacklist logic to allow buys but revert sells or route them at 99% tax. Public reports from analytics firms noted these tactics becoming mainstream in DeFi scams—so if you see the knobs, assume someone plans to turn them.

Do a tiny test trade and approve safely

If everything still looks reasonable, I test with lunch-money size. The goal isn’t profit—it’s proof I can exit.

• Use a fresh wallet for new tokens. Keep hot wallets compartmentalized.


• Approve the router with a custom limit equal to your tiny buy, not unlimited. Most wallets let you set this during approval. If the token tries to force approval to the token contract instead of the router, I’m gone.


• Buy a tiny amount. Check received tokens vs. expected—stealth transfer fees show here.


• Try an immediate tiny sell:
  
  
  
  • Keep slippage modest. If it reverts, check the error. “Transfer failed” or “insufficient output” while buys work is classic honeypot behavior.
  
  
  • Watch MEV/unusual gas: contract tricks sometimes show up as very high gas usage on sell.
  
  
  
  


• Revoke approvals right after the test using Revoke.cash or your explorer’s token approvals page. Never leave open lines to sketchy contracts.

Extra safety: Some contracts allow tiny sells but block meaningful ones or raise taxes later. That’s why I combine this test with the ownership and tax checks above—assume switches exist until proven otherwise.

Quick 3–5 minute checklist I actually use

• Address from official/pinned source → explorer shows verified code and the right chain


• Main pair found → LP burned/locked with real duration → holder of LP checked


• Owner renounced or reputable multisig → no migrator/proxy tricks (or fully understood)


• Scanners run → fees/limits/blacklist powers reviewed in the code


• Tiny buy → tiny sell succeeds → approvals revoked

You’ve just cut your risk dramatically. But here’s the thing: liquidity protection is the first and biggest domino. Want to know exactly how to confirm whether LP is truly locked, burned, or rug-ready—and how long is “long enough” to trust it?

LP security 101: locked, burned, or rug-ready?

I’ve seen too many charts go vertical, then straight to zero because the liquidity vanished. You can’t always stop a scammer from trying—but you can see them coming if you know where to look. Liquidity protection is the first thing I check on any token, because when LP goes, price follows fast.

“In this market, liquidity is oxygen—when it’s gone, everyone realizes too late.”

Chainalysis tracked a surge in rug pulls during the 2021–2022 cycle, noting they made up a huge share of scam revenue in DeFi. That trend didn’t disappear in 2023 or 2024—attackers just got better at hiding it. If you want to avoid waking up to a -95% candle, learn to read LP security like a pro.

Locked vs. burned liquidity

These two terms get thrown around a lot. They aren’t the same—and one can be faked.

Locked LP means the LP tokens (the receipt tokens from the DEX) are held in a locker contract until a set time. After the timer expires, the lock owner can withdraw. Common lockers include Unicrypt and Team Finance.

Burned LP means the LP tokens were sent to an unrecoverable address. On EVM chains, the usual burn addresses are:

• 0x0000000000000000000000000000000000000000 (zero address)


• 0x000000000000000000000000000000000000dEaD (dead address)

How I verify in seconds:

• Open the token’s main pool on the DEX explorer (e.g., DexScreener) and click the pair contract.


• On Etherscan/BscScan, hit Holders for the LP token. The top holder should be a known locker or a burn address.


• If it’s locked, click through to the locker transaction and confirm:
  
  
  
  • Amount locked (what % of total LP?)
  
  
  • Unlock date (timestamp) and TX hash as proof
  
  
  • Withdrawer address (who can pull it later?)
  
  
  
  


• If it’s burned, make sure the tokens truly sit at the zero/dead address—no cute “dead” label on a regular wallet. Labels can lie; addresses don’t.

Quick reality check: burning LP is “forever,” but it doesn’t save you from other traps (like sell blocks or mint abuse). Locking is reversible at the unlock date, which makes the timeline a big piece of the risk.

Who controls the lock?

“LP locked” sounds safe until you see the details. The lock has an owner. That owner can withdraw at expiry, sometimes transfer lock control, and in some lockers even split the lock into tranches. I always ask:

• How long is it locked? Weeks aren’t comforting. Months are a minimum. A year+ calms nerves.


• Who is the withdrawer? An anonymous EOA = fragile trust. A reputable multisig is better.


• Is it a partial lock? If only 30–50% is locked, the rest can be yanked at any time.


• Are there multiple locks? Teams sometimes lock tiny slices and shout “100 years!” while keeping a big unlocked pile elsewhere.


• Is LP staked in a farm (MasterChef)? If yes, make sure the farm contract has no migrator function. Countless BSC forks rugged with a migrator that yoinked LP to a dev wallet. RugDoc has a good primer on this risk: rugdoc.io/docs/migrator.

Real-world lesson: Avalanche’s SnowdogDAO executed a “liquidity event” that moved trading to a new pool and left holders rekt. Different mechanics, same pain: control the pool, control the outcome.

Bottom line: I don’t just want to see “locked.” I want to see who can unlock, when they can do it, and how much they actually locked.

Red flags around LP

LP checks catch a huge chunk of rugs. Here are the patterns that make me hit pause immediately:

• Unlocked LP or micro-locks: No lock at all, or a 1–7 day lock around a marketing push. That’s a “get volume, pull liquidity” setup.


• Tiny pool depth: A new pool with $3k–$10k liquidity and a fully diluted $5M cap is a house of cards. One sell nukes it.


• Suspicious relocks: Team relocks the LP minutes before AMA/listing to create FOMO. Check the previous locks and timing in the locker UI and on-chain events.


• Partial lock bait: “LP locked 100 years!”—click through and it’s 18% of the pool. The other 82% is free and clear.


• Multiple pools decoy: One pool is locked and advertised, trading quietly. A separate “real” pool carries volume and stays unlocked. Always confirm which pair is actually active on the DEX.


• Migrator contracts: If LP sits inside a farm or staking contract, read the code for migrator, setMigrator, or similar. If present or recently toggled, that’s a hard pass.


• Router games: Tokens with a setRouter/setPair function can switch where new liquidity goes. On its own that isn’t evil, but paired with short locks it’s a common rug route.


• Fake burns: LP “sent” to an address labeled “dead” that isn’t 0x0000... or ...dEaD. Always verify the exact address string.

What solid looks like:

• 80–100% of LP locked or burned


• Locks spanning months (preferably 6–12+) with clear TX hashes


• Withdrawer is a known multisig (Gnosis Safe) and publicly documented


• No migrator in any farm contracts that custody LP


• One primary, active pool with consistent lock coverage

Tip: When a project claims “liquidity locked,” ask for the locker link and TX hash—not a screenshot. Verify it yourself on-chain. If they hesitate, you have your answer.

LP security won’t protect you from everything. Even with liquidity locked or burned, contracts can still change taxes, block sells, or mint tokens into oblivion. That’s where permissions come in. Want to see the exact functions and roles that turn a “locked LP” into a trap anyway? Let’s look at the superpowers you should never ignore next…

Contract permissions that should make you pause

If a token looks exciting but the contract screams “one-key god mode,” I slow down. Permissions are the quiet levers that turn a fair launch into a trap. The fastest wins I’ve had in avoiding rugs came from spotting a single write function that could nuke the market in one transaction.

“If one wallet can ruin your day, it probably will.”

Here’s the quick, no-fluff breakdown of the permissions I check first and how I sanity-check them on-chain in seconds.

Owner-only superpowers

Most ERC-20s use Ownable or AccessControl. That’s normal. The risk comes when the owner (or any privileged role) can change core economics or block exits after you buy. If you see these, take a breath and validate who holds the keys and how they’re controlled.

• Mint / setSupply / setMinter — Unlimited or poorly gated minting lets a team flood supply and dump. This has been behind countless “chart goes vertical, then flatlines” stories. If minting exists, I expect caps, events, and role limits—and I want that role in a multisig or timelock.


• setTax / setFees / setSellFee — Adjustable fees can turn into a honeypot with a single call (99% sell tax). I’ve seen teams launch at 5–10% then quietly crank it. Look for fee caps in code and who can change them.


• setBlacklist / blacklistAddress / setTradingWhitelist — Classic honeypot play: you can buy, then you’re blacklisted on sell. The SQUID token fiasco used restrictive sell logic that made exits nearly impossible.


• setTradingEnabled / pause / unpause — Trading toggles are used for anti-bot launches—but they also let one wallet freeze the market while insiders exit on another route.


• setMaxTxAmount / setMaxWallet — After you buy, they can drop limits so your balance is “too large to transfer,” trapping you. I treat adjustable limits without caps as orange-to-red flags.


• emergencyWithdraw / rescueTokens / sweep — Common in staking farms. These functions can yank user tokens or LP out “for safety.” If there’s no timelock and no event trail, I’m out.


• setRouter / setPair / setLiquidityReceiver — Swapping a router or liquidity receiver can break sells or redirect liquidity to a dev-controlled address.


• migrate / upgradeSettings — Migration patterns are legitimate in complex systems, but in meme-land they often move funds to a fresh contract where the rules change.

Spot them fast:

• Open the token on Etherscan/BscScan → Contract → Read/Write Contract. Search “tax,” “fee,” “blacklist,” “mint,” “trading,” “max”.


• Check owner() and any role addresses (e.g., getRoleMember in AccessControl). If it’s a fresh EOA with no history or a single team wallet, that’s risk concentrated.


• Look for caps in code: feeMax, maxSupply, minDelay. No caps = no guardrails.

Why I care: security firms keep pointing to privileged role misuse as a leading cause of losses. CertiK and SlowMist have both flagged centralization and access control failures in their annual retrospectives (CertiK Resources, SlowMist Hacked). If the power exists, sooner or later someone uses it.

Renounce, multisig, and timelocks

“Renounced ownership” gets thrown around like it’s a magic shield. It helps—but it’s not the whole story.

• Renounce — Setting owner to the zero address removes one big rug vector, and I like that. But I still check for “shadow admins.” Some contracts keep separate roles (operator, feeSetter, controller) outside Owner. Also, renouncing the implementation while keeping a proxy admin (see below) is a fake comfort.


• Multisig — A 2/3 or 3/5 Gnosis Safe for owner/admin is a green flag. On Etherscan, Safe proxies are often labeled; you can verify thresholds and signers via the Safe app. One signer controlling a multisig defeats the purpose—check real owners.


• Timelocks — A proper TimelockController with a visible minDelay (e.g., 24–48h) gives the market time to react before upgrades or parameter changes. If upgrades/fee changes bypass the timelock, call it what it is: centralized control with extra steps.

Quick heuristics I use:

• Best: Owner is a timelocked multisig; fee/tax and blacklist functions either don’t exist or are timelocked; LP is locked/burned.


• Okay: Renounced owner with no hidden roles; minimal adjustable parameters with caps; no proxy admin.


• Risky: Single EOA as owner/admin; adjustable taxes/blacklist/maxTx; no timelock; proxy upgrade rights intact.

For context, Chainalysis noted how rug pulls surged when creators realized how easy it is to yank value through centralized controls (Chainalysis research). The pattern hasn’t gone away—just got quieter.

Proxies and upgradeability

Even if a token looks clean, proxies can change the rules after launch. Two patterns matter:

• Transparent Proxy — An admin address controls upgrades. Users interact with the proxy; logic lives in an implementation contract. Admin can point to a new implementation at any time.


• UUPS — Upgrade logic is in the implementation itself, but an upgrader role authorizes changes. Still boils down to “who can upgrade and how quickly.”

How I check it in under a minute:

• On Etherscan/BscScan, look for the banner: “This contract is a proxy.” Click Read as Proxy.


• Note the implementation and admin addresses. If the admin is an EOA (a single wallet) or unlabeled, assume high risk. If it’s a Timelock or Gnosis Safe, better.


• Open the implementation. Is it verified? Any fee/blacklist functions in the new logic? Are upgrades gated by a timelock?


• Look for upgradeTo / upgradeToAndCall in Write as Proxy. If callable by a single admin with no delay, you’re trusting that one party completely.

Why this matters: I’ve watched tokens run clean for days, then flip into a sell trap after an upgrade switched fee logic. Traders blamed “bad luck.” It wasn’t. It was governance-by-surprise, and the proxy made it possible.

Personal thresholds (feel free to copy):

• If a proxy admin isn’t a timelocked multisig, I size down or pass.


• If the team won’t explain who controls upgrades (and how), I assume the worst.


• If renounce is claimed but a proxy exists, I treat “renounced” as marketing, not security.

Here’s the punchline: permissions tell you who can rewrite the rules after you enter. LP checks and scanners are great, but this is where real control lives. And even if the permissions look okay, there’s still one place most people get tagged—your own wallet habits. Ready to harden those next?

Wallet safety and trade hygiene most people skip

Passing the scanners doesn’t mean you’re safe. Most losses I see don’t come from genius-level exploits—they come from rushed clicks, lazy approvals, and slippage set like a red carpet for thieves.

“In crypto, the small habit you skip is usually the one that costs you the most.”

Here’s how I keep my trades clean even when everything looks green.

Limit approvals and revoke often

On most DEXs you approve a token before you swap it. By default, that approval is often “infinite,” meaning the spender can move any amount later. That’s convenient until a website you once used gets compromised or a spender contract upgrades its logic. Months later, a drainer hits your wallet without you pressing buy or sell.

What I do:

• Use spending caps, not infinite approvals. When your wallet asks for permission, click Use custom spending cap (MetaMask, Rabby, Ledger Live all support this). Set the cap just above your intended trade.


• Approve only when you trade—and revoke right after you exit. No approval should live longer than your position. If I’m out, I’m revoked.


• Monitor approvals weekly. Check and revoke on:
  
  
  
  • Etherscan Token Approvals (Ethereum)
  
  
  • BSCScan Token Approvals (BSC)
  
  
  • Revoke.cash (multi-chain)
  
  
  • DeBank (portfolio + approvals)
  
  
  
  


• Prefer “permit” with deadlines over blanket approvals when available. Some apps use signed permits (EIP-2612/Permit2) that can expire—use that if supported.


• Watch for approve-like signatures in your wallet. If a site asks you to sign anything that sounds like “SetApprovalForAll,” “Permit,” or “IncreaseAllowance,” slow down and read it. If your wallet supports simulation, check what changes before you sign.

Multiple industry reports (Chainalysis, ScamSniffer, REKT) point to phishing drainers abusing approvals and signatures as a major share of losses. It’s not a theoretical risk—it’s the playbook. Keeping allowances tight is the cheapest insurance you’ll ever buy.

Beware slippage and stealth taxes

High slippage is a gift to both MEV bots and shady tax logic. I’ve seen tokens that let buys through with normal slippage, then require 25–50% slippage to sell “due to volatility” (translation: you’re paying their exit fee).

My guardrails:

• Keep slippage modest. For most pairs, I start at 0.3–0.8%. If I must go higher, I ask why. If it’s illiquid or launch chaos, I size down rather than cranking slippage.


• Never rely on “Auto” slippage. Some DEXs bump it sky-high to force a fill. Set your own number.


• Set a short deadline. Two–three minutes max. Stale tx = easy target.


• Run a tiny round-trip test. Buy a dust amount, then sell it. Confirm the net you receive. If your wallet balance drops far more than expected, that’s your answer.


• Check the expected output before you sign. Many wallets show “Minimum received.” If it looks off, it is.


• Remember MEV. High slippage invites sandwiches. Use MEV-protected routes when possible:
  
  
  
  • Flashbots Protect RPC (ETH)
  
  
  • CoW Swap (batch auctions reduce sandwich risk)
  
  
  
  

If a project insists you need 20%+ slippage to sell “just for launch,” I consider that a built-in tax. Scanners may not catch it; your test trade will.

Use explorers and holder maps

A token can look safe and still be surrounded by wallets that can nuke you with one move. I care less about the story and more about the map.

• Open the contract on the explorer first. Holders tab on Etherscan or BSCScan tells you who sits on the supply.


• Look for top-heavy distributions. If a few wallets (outside of LP and known vesting) control a big chunk, that’s exit risk. I’m cautious if any single external wallet holds 3–5%+ and very cautious if the top 10 wallets control 20–30%+ without locks.


• Check the LP token holders. If LP tokens aren’t burned or locked, see who holds them and for how long (lockers like Team Finance/Unicrypt show lock IDs and dates).


• Trace clusters. Tools like BubbleMaps visualize wallet relationships. A web of fresh wallets funded by the same source and swapping in sync = likely team cluster.


• Watch for sudden whale moves. Add the top holders to a simple watchlist (Etherscan “Add to Watch List,” DeBank, or your wallet’s address book). A synchronized drain from three whales right after a tweet? That’s not alpha; it’s the exit signal.

Distribution isn’t just a stat—it’s your early-warning system. Healthy projects want liquidity spread out and obvious team/vesting wallets labeled. If you have to guess, that’s already a clue.

Segregate wallets and control your attack surface

One wallet for everything is like using the same password everywhere. It works—until it doesn’t.

• Use a fresh “scratch” wallet for degen trades. Keep your long-term stack on a separate hardware-protected wallet.


• Disable autosign and turn on simulations. Wallets like Rabby simulate transactions before you sign. Use it.


• Avoid connecting your main wallet to new sites. If you must, connect read-only or via a burner first.


• Bookmark official URLs. Phishing thrives on lookalike domains. Search results are not your friend when money is on the line.

Simulate before you sign

Contracts can do a lot behind a friendly button. I like to see what will happen before I commit.

• Use transaction simulators. Tenderly (simulator), Rabby’s built-in simulation, and some explorers will show value transfers and state changes pre-trade.


• Check decoded function calls. On the explorer’s “Write/Read Contract” tabs, confirm what the function is supposed to do, and that you’re not hitting a migrate/blacklist/fee edit by mistake.

Keep gas and routing under control

Rushing the gas slider can cost you twice—failed tx fees and bad fills.

• Avoid extreme priority fees unless you need them. Overpaying doesn’t just burn ETH; it telegraphs urgency to MEV searchers.


• Pin your route. If your DEX lets you, pick the pool path manually. Aggregators sometimes choose a cheap-looking route that hides a taxed pool or a sketchy intermediate token.

None of this is hard. It’s a 90-second routine that turns “hope” into a plan: small approvals, small tests, small slippage, clear holders. You’ll feel calmer because you’re in control.

Want to copy my exact stack—scanners, lockers, explorers, and the one holder map I check every time? I’m walking through the specific tools next. Which two scanners do I actually trust together, and what order do I use them in to save time?

Tools I actually use (and how I combine them)

I keep a tight stack of tools that help me rule out obvious traps in minutes. None of them are magic. Used together, though, they’ll save you from most of the gotchas that nuke portfolios.

Token and honeypot scanners

• TokenSniffer — Quick smell test with a simple score. I mostly use it to catch copy-paste contracts, extreme taxes, and owner-only superpowers. Tip: click into the “Similar Contracts” and “Holders” sections, not just the badge on top.


• Honeypot.is — Simulates buy/sell and shows if a sell reverts or is taxed to oblivion. If it shows “sell failed” or absurd sell tax, that’s usually a no-go for me.


• GoPlus Token Security — Great for a structured list of risks: blacklists, mint, trading toggle, maxTx/maxWallet. It’s chain-agnostic and updates quickly on new launches.


• De.Fi Scanner — Good UI and coverage; also ties into their revoke tool. I like the way it flags proxies and variable taxes.


• RugDoc — DeFi-native checks with human notes for many chains (esp. on fair launches and farms). If they’ve posted a warning on a project type, I listen.

Why pair them? Attackers adapt to one checker. Two independent scans often surface different red flags. If either screams “honeypot” or “owner can mint unlimited,” I stop right there.

Speed tip: If a scanner shows >12% sell tax, a blacklist function, or unlocked LP, I don’t keep digging. There are too many safer charts to waste time on a maybe.

LP locks and pool insights

• Team Finance — Popular locker with verifiable lock records. Click through to the actual lock hash and expiration, don’t trust screenshots.


• Unicrypt — Another major locker. Same process: confirm the lock transaction on-chain and note the duration.


• Uniswap Info — Check pool age, liquidity depth, volume, and top pairs on Ethereum.


• DexScreener — Fast charting across many chains. I look at “FDV,” “Liquidity,” “Holders,” and the first LP add timestamp.


• DexTools — Great for watchlists, live trades, and pair explorers. If the pool was created minutes ago with tiny depth, I treat it as radioactive until proven otherwise.

Reality check: Lockers don’t fix bad code. A year-long lock on a contract that can mint and dump is still a rug waiting to happen. Lock + sane contract + healthy holders is the combo you want.

Explorers and extras

• Etherscan / BSCScan — Start here. Verify source, read contract, check “Contract Creator,” “Owner,” and “Read/Write Contract.” The “Holders” tab + “Token Tracker” updates tell you a lot fast.


• BubbleMaps — Visualizes wallet clusters. If the top wallets are heavily connected or the deployer sits near multiple whales, exits can get ugly.


• CertiK Skynet — If a project is listed, you can track real-time alerts, governance updates, and on-chain anomalies. Not every token is there, but when it is, I check it.

For context, security researchers have shown that exit scams and LP rugs concentrate during hype windows, and fake-token campaigns keep evolving to bypass simple checks. Industry reports like Chainalysis’ Crypto Crime series back this up with trends across cycles. The takeaway: use multiple eyes (tools) on every contract.

How I stack them for a fast yes/no

• Explorer first: Paste the contract on Etherscan/BSCScan. Is the code verified? Is there an obvious owner or proxy? Any suspicious functions (mint, blacklist, setTax)?


• Run two scanners: TokenSniffer + GoPlus or De.Fi. If either flags honeypot behavior, extreme sell tax, or owner-only godmode, I stop.


• Honeypot test: Check Honeypot.is. If it shows failed sells or stealth taxes, pass.


• LP status: Look up the lock on Team Finance or Unicrypt. Confirm the lock tx and duration. Cross-check pair age and depth on DexScreener or DexTools.


• Holder map: Top 10 ownership and BubbleMaps clustering. If one cluster controls >30–40% combined, the exit risk is high.


• Only then, tiny test: If everything looks clean, I do a tiny buy/sell with tight approvals and verify that the sell executes.

Reading scanner outputs in under 60 seconds

• Green ≠ safe: A low-risk badge means “no common traps detected,” not “good token.” I still check LP and holders.


• Red ≠ instant FUD: Some legit launches keep ownership early for fixes or use higher temporary taxes. If the team is known and timelocked, I may watch, not buy.


• Deal-breakers for me: Unlocked LP, nontrivial blacklist logic, mint enabled after launch, proxies with unknown admins, or sell tax above ~12%.

Chain-specific notes that cut noise

• Ethereum: Proxy patterns (UUPS/transparent) are common. Always click “Read as Proxy” on Etherscan and jump to the implementation contract.


• BSC: Higher volume of copy-paste scams. I never skip the honeypot test here, even if one scanner says “low risk.”


• Newer chains: Tooling can lag. When in doubt, lean harder on explorers and a small manual test.

Real-world example: how a 3-minute check prevents pain

New token pops on DexScreener with 50k liquidity and fast green candles. Here’s how I triage:

• Explorer: Verified code, but owner not renounced. I see setFee and setBlacklist.


• Scanners: TokenSniffer flags adjustable taxes; GoPlus shows blacklist present and trading toggle set to true (okay for now).


• Honeypot: Honeypot.is reports 7% buy, 22% sell. That’s already a pause.


• LP: LP lock on Unicrypt, but only 7 days. Pool age is 2 hours.


• Holders: Top 5 own 28% and cluster together on BubbleMaps.

I pass. Within 24 hours, sell tax gets bumped to 45% via owner function. Charts never show you that early—but the tools did. This is exactly the pattern security teams and analysts keep seeing during hype phases: quick locks, adjustable fees, then a switch.

When tools disagree

• Default to caution: I side with the stricter outcome, then verify manually on the explorer.


• Check context: Known team with a timelock and public roadmap? A single red flag may be temporary. Anonymous team with multiple flags? Hard pass.


• Wait it out: If you aren’t sure, set alerts on DexTools/DexScreener and re-check after a day. Time is the best filter for noisy launches.

Automate the boring parts

• Watchlists: Track pairs on DexTools and DexScreener to spot sudden LP changes or whale sells.


• Notifications: Follow the token address on Etherscan/BSCScan to get email alerts on contract interactions or big holder moves.


• Revokes: Keep a revoke tab handy (De.Fi has a good one) and clear approvals after exits.

You’ve got the stack and the flow. Want a one-page checklist that ties this all together and answers the most common “what if” questions I get every day? That’s exactly what’s coming next—how would your pre-buy routine change if you could run it in under 90 seconds, every time?

FAQ and final checklist

I get the same questions in my inbox every week, so I pulled the clearest answers into one place and wrapped it up with a checklist you can save. Think of this as your quick “don’t-get-wrecked” page before you click buy.

Are rug pull and honeypot scanners accurate?

They’re great at catching the obvious stuff—excessive taxes, blacklist functions, unlocked LP, owner-only toggles—but they’re not crystal balls. Attackers ship proxy contracts, delayed switches, and obfuscated logic to sneak past pattern-based checks.

A good mindset: scanners = alerts, not guarantees. Treat a clean score as “no obvious traps” rather than “safe.” Independent research backs this up—annual security reviews from firms like CertiK and SlowMist continuously show exit scams and honeypots evolving to bypass naive checks.

How can I tell if a token is a honeypot before buying?

• Run a honeypot tester (e.g., Honeypot.is) and at least one general token scanner.


• Open the contract on the explorer and look for sell blockers: blacklist, maxTx/maxWallet set absurdly low, trading toggles, or logic that reverts on sell.


• If scanners look clean, try a tiny buy and then an immediate tiny sell. If the sell fails or the received amount is way off, stop.

Real-world example: the infamous “Squid” token let people buy but not sell. Multiple outlets documented how sell transactions reverted while the price ran up. Here’s coverage from the BBC.

What’s a safe tax range?

Launch periods sometimes use modest taxes to seed LP or fund operations. But extreme or asymmetric sell taxes are a classic trap.

• My rule of thumb: anything above ~10–12% on sells is a hard pause.


• If the team insists “it’s temporary,” ask to see the function that lowers tax and whether it’s timelocked or controlled by a multisig.


• High slippage settings can hide huge sell taxes. Always test with small size first.

Is renounced ownership always better?

It removes some common risks (like the owner flipping a blacklist mid-pump), but it also blocks legit fixes. I prefer:

• Renounced ownership with timelocked critical functions, or


• A reputable multisig with timelocks over a single keyholder.

That balance lets teams patch issues without having god-mode powers.

How long should LP be locked?

Months at minimum; a year or more is better. Short locks around big marketing pushes are suspicious. Always verify the lock on-chain, check who controls it, and confirm there’s no hidden migrator that can move liquidity anyway.

What if scanners disagree?

Happens all the time. Go with the stricter result and check manually:

• LP status and lock proof


• Owner and privileged roles


• Taxes and trading toggles


• Blacklist/whitelist and mint functions


• Proxy/upgradeable architecture


• Holder distribution and any obvious team clusters

If you’re still unsure after that, skip it. You’ll see another chart in ten minutes.

What should I do if I suspect a rug pull?

• Stop buying. Don’t “average down” a scam.


• Attempt a small test sell immediately. Don’t wait for perfect timing.


• Revoke approvals for the token and any shady spenders:
  
  
  
  • revoke.cash
  
  
  • Etherscan Token Approval Checker
  
  
  • Unrekt
  
  
  
  


• Warn others with evidence: tx hashes, screenshots of reverted sells, and contract lines that show the trap.

Tip: If a token suddenly requires extreme slippage to sell, assume a stealth tax switch or sell block and exit if you can.

Quick pre-buy checklist

• Verified contract? Source code published on the explorer with matching compiler settings.


• LP locked or burned with proof? Link to the lock tx and check the duration and controller.


• Owner risk under control? Renounced, or a reputable multisig with timelocks.


• Reasonable taxes? Especially on sells. Anything over ~10–12% = pause.


• No blacklist/mint traps? Look for setBlacklist, setTax, mint, trading toggles, and hardcoded wallets.


• Healthy distribution? Top wallets aren’t concentrated; no obvious team clusters holding most supply or LP.


• Passes two scanners? Use more than one; treat them as alerts, not guarantees.


• Tiny test sell works? Buy small, sell small. If it fails or returns pennies, walk away.

One more thing I keep in mind

Independent reports like the Chainalysis Crypto Crime Reports show that exit scams and rug-style schemes are persistent year after year, even as tooling improves. Scams evolve; your process should too.

Conclusion and next steps

I’ll keep this page on cryptolinks.com/news updated as new tools and tricks show up. Bookmark it, share the checklist, and treat every new token like it has something to prove. The best trades feel boring because the checks all line up. That’s the point.

If you’ve got a scanner, locker, or analysis tool that saved you from a rug or honeypot, send it my way. I’ll test it and add it to the rotation if it holds up.