Honeypot Token: How to Spot a Token You Cannot Sell
Learn what a honeypot token is, how to check for sell blocks without a wallet, and why passing a sell test is not proof of safety.
Published
Updated
Roughly 88% of 17,194 newly created Ethereum tokens exhibited blocked selling at some stage in a 2025 EPJ Data Science study. That finding describes a particular sample, not every crypto market. But it challenges a dangerous assumption: if your purchase succeeds, selling must work too.
For Solana meme-coin traders, the question goes further. You need to know whether your tokens can move, whether a buyer or liquidity pool can absorb them, and what you'll receive when you exit.
Table of Contents
- What a Honeypot Token Is and Why Buyers Get Trapped
- Six Quick Checks Before You Buy
- Contract Permissions That Block Selling
- How Test-Sell Simulations Work and Where They Fail
- Why a Sellable Token May Still Be a Trap
- Two Real Cases Behind the Honeypot Label
- Confirm the Check Before You Commit Money
What a Honeypot Token Is and Why Buyers Get Trapped
A honeypot token is a token you can buy but can't sell normally because its rules block or economically punish the exit. Think of a one-way door: the buy side swings open, but the sell side stays locked. Outside, a cheering crowd and a rising price chart make the entrance look inviting.
Your wallet can still show a balance. A trading page can still display an impressive valuation. Neither proves that you can convert those tokens back into SOL or another asset.
Why an active chart can mislead you
Restrictions can sit in contract code, account permissions, or adjustable trading rules. Some prevent transfers to a trading pool; others allow the transaction but take so much in fees that selling becomes economically pointless. Liquidity removal creates a related exit trap, although it isn't necessarily a classic contract-level honeypot.
The EPJ Data Science study of newly created tokens found that the median honeypot had only 42 swaps, compared with 363 swaps for tokens that remained sellable. Early activity therefore deserves scrutiny, not automatic trust.
A swap count doesn't tell you who traded, whether ordinary holders could sell, or whether the creator gave selected wallets special treatment. A few successful transactions can coexist with restrictions affecting everyone else.
Core principle: A successful purchase proves that the entrance worked. It doesn't prove that the exit exists.
Separate the balance from the proceeds
Say you buy a newly launched token and its displayed price rises. Multiplying that price by your balance produces a tempting number, but it isn't a cash offer for your entire position.
Before treating that number as accessible money, establish:
- Transfer permission: Can your wallet send the tokens through the intended trading route?
- Sale proceeds: What remains after fees and price impact?
- Available liquidity: Can the pool absorb the position you intend to sell?
Don't confuse a failed transaction with definitive proof of fraud, either. Routing problems and account configuration can also interrupt a swap. The useful question is whether the failure comes from an ordinary technical problem or a restriction that selectively prevents holders from leaving.
Six Quick Checks Before You Buy
Start with read-only lookups using the token address. You shouldn't need to connect a wallet, approve spending, or sign a transaction just to inspect public token information.
Copy the address from the asset you're evaluating, not from an unsolicited message or a search result with a similar ticker. A convincing name and logo don't establish identity.
The checklist below turns that address into a practical screening record.
A read-only screening routine
Open the address in a block explorer. On an EVM chain, inspect whether the contract source is verified and whether the token uses an upgradeable proxy; unverified code is a reason to slow down, not proof of a scam. On Solana, use an explorer such as Solscan to identify the mint and owning token program, since an EVM-style verified-contract label isn't a universal Solana test.
Read the holder distribution. Look beyond the largest wallet and consider whether apparently separate wallets could be connected through funding or transfers. Identify pool, exchange, and custody accounts before treating a large balance as an insider position, because mislabeling those accounts can distort your conclusion.
Inspect mint and freeze authority on Solana. Record whether each authority remains active or is set to null, and distinguish their purposes: mint authority concerns additional issuance, while freeze authority concerns account movement. An active permission deserves explanation rather than an assumption that the creator won't use it.
Run an address-based honeypot checker. Record whether it supports the chain and trading venue, whether the simulated sale passes, and what sell fees it reports. An unsupported route or incomplete result isn't a pass, and a green result shouldn't override contradictory on-chain evidence.
Compare liquidity with your intended exit. Inspect the actual trading pool and request a sell quote for the position you expect to hold, rather than relying on market capitalization. A route that handles a tiny sale may produce unacceptable proceeds for your full position.
Inspect the creator's wallet activity. Check retained tokens, recent transfers, liquidity-related transactions, and connections to other large holders. Transfers don't prove wrongdoing, but unexplained movement into wallets positioned to sell should stop you from rushing.
Keep a usable record
Write down the address, chain, trading pair, result, and timestamp for each check. Include unresolved questions rather than forcing every observation into a safe-or-unsafe label.
Our Solana token safety checks guide provides a broader framework for organizing that review. Keep the process read-only until you've decided whether the evidence supports proceeding at all.
Contract Permissions That Block Selling
The critical contract question isn't whether the code looks familiar. It's what the controller can make happen to your tokens.
On EVM chains, a deployer can encode selective restrictions directly into transfer logic. A contract might permit purchases from a pool while rejecting transfers back to it, or exempt privileged wallets from rules imposed on ordinary holders.
Permissions that can block an exit
| Permission | Where it sits | Effect on exit |
|---|---|---|
| Blacklist function | Contract owner controls | Blocks chosen wallets from selling |
| Transfer restriction | Contract transfer logic | Lets buys succeed while sells revert |
| Owner-set sell fee | Adjustable fee variable | Takes most of the value on sale |
| Trading cooldown or limit | Contract trading rules | Caps or delays sells for most holders |
| Pausable transfers | Owner pause switch | Halts all trading at once |
| Freeze authority | Solana SPL mint account | Freezes a holder account so tokens cannot move |
A function's name isn't enough to establish its effect. Read who can call it, which addresses it affects, and whether another function can change its settings. If the contract is upgradeable, inspect who controls the upgrade rather than assuming the visible implementation is permanent.
A cooldown also needs context. A disclosed launch restriction applied consistently isn't the same as a hidden rule that exempts the creator while trapping buyers.
How Solana account freezing works
The Solana documentation on freezing token accounts explains that an authorized signer can issue a FreezeAccount instruction when the mint retains freeze authority. A frozen account keeps its owner, mint, and balance, but it can't receive, transfer, or burn tokens.
That distinction explains a confusing wallet experience: the tokens haven't disappeared, yet the holder can't move them. Because a DEX sale requires transferring tokens through the swap, a frozen token account prevents that sale.
Revoking freeze authority removes this particular control path. It doesn't establish that the token has adequate liquidity, honest ownership, or no other restrictive program behavior.
An active authority establishes capability, not intent. Combine it with account state and actual trading behavior before drawing a conclusion.
Freeze controls can serve legitimate administrative or compliance purposes. For an unfamiliar speculative token, however, an unexplained ability to immobilize holders is a meaningful warning.
Inspect whether ordinary wallets have completed genuine sales and whether failed transactions point to frozen accounts. Our explanation of Solana freeze authority helps distinguish the mint-level permission from the state of an individual holder account.
How Test-Sell Simulations Work and Where They Fail
A test-sell simulation asks a narrower question than whether a token is safe: can a modeled buyer purchase and then sell under the conditions reproduced by the checker?
In a fork-based implementation, the checker copies blockchain state into an isolated environment, simulates a purchase, and attempts the return sale. It can inspect whether the transaction reverts and compare expected proceeds with what the simulated seller receives.
The diagram shows that transaction sequence and its main limitation.
Detection methods and their blind spots
| Method | What it establishes | What it misses |
|---|---|---|
| Contract permission read | Dangerous functions or freeze authority exist | Behavior not yet triggered and the controller's intentions |
| Simulated buy then sell | Whether the modeled sale reverts or incurs economically prohibitive fees, classified as above 90% in the fork-based detection study | Changes made after the simulation |
| Aggregate checkers | Whether supported checks identify known warning patterns | Unsupported routes, unrecognized logic, and incomplete inputs |
| Repeated monitoring | Liquidity, concentration, and creator changes over time | Sudden exits between checks |
A successful simulation depends on its assumptions. The modeled wallet, trade size, route, and copied state may not match your eventual transaction.
For example, a checker might model a small purchase while you intend to build a much larger position. Or the owner might activate a restriction after the copied state was captured.
Interpret failures before retrying
A failed simulation deserves investigation, but failure alone doesn't identify the cause. Look for a useful error explanation: frozen account, transfer restriction, missing route, insufficient liquidity, or an execution setting that the simulator couldn't reproduce.
Don't respond by blindly increasing slippage. That can turn an unsuccessful trade into an expensive successful one without resolving the underlying risk.
For a visual walkthrough, the accompanying video offers another way to follow the checking process.
Combine permission inspection with transaction simulation, then compare both with real wallet activity. Agreement between independent methods is more useful than several interfaces repeating the same underlying result.
Trigger a fresh assessment when liquidity moves, creator-linked wallets transfer tokens, trading settings change, or buys cluster unusually. There's no universal waiting period after which an unfamiliar token becomes trustworthy.
The useful output is a time-stamped assessment with explicit uncertainty, not a permanent safety label. A checker can describe the state it examined; it can't bind the creator's future actions.
Why a Sellable Token May Still Be a Trap
A token doesn't need an explicit sell block to leave buyers unable to recover meaningful value. Developers can withdraw liquidity, insiders can overwhelm the pool with sales, or coordinated promoters can attract buyers before large holders exit.
A study covering newly issued tokens on Orca, Raydium, and Meteora examined 100,063 tokens and identified 76,469 suspected rug pulls, organized around freeze-authority abuse, liquidity withdrawal, and pump-and-dump behavior. Suspected rug pulls aren't all classic honeypots, but that distinction is precisely why a sell-only test is incomplete.
Technical sellability versus economic exitability
Technical sellability means a transaction can execute. Economic exitability means you can leave at proceeds you're prepared to accept.
Say your tokens remain transferable and a swap quote is available. If selling your position consumes a substantial share of the pool's usable liquidity, your own sale can push the execution price sharply below the displayed price.
That's price impact. Slippage is the difference between the quoted outcome and the eventual execution, within the tolerance you authorize. Increasing that tolerance doesn't deepen the pool or make an unfavorable exit sensible.
Use an exit-price test:
- Compare position and depth: Divide the current quote-currency value of your planned position by the pool's quoted liquidity value as a rough size warning.
- Request an executable quote: Enter the full intended sale amount and inspect the expected output, fees, route, and minimum received.
- Account for pool structure: Total pool value isn't identical to usable liquidity near the current price, particularly in concentrated-liquidity pools.
- Consider competing sellers: Creator-linked holdings and connected wallets may represent supply that reaches the pool before yours.
The position-to-pool ratio is a screening aid, not a universal price-impact formula. Use the actual route's quote rather than converting that ratio directly into an expected loss.
A token can pass a sell test while failing your exit-price test.
A risk score can't create buyers
A token can pass our checks and still collapse because demand disappears, large holders sell, liquidity changes, or new information appears. A lower rug pull risk rating doesn't mean a token is safe, and a higher health score doesn't mean its price will rise.
If you're troubleshooting an existing position, distinguish a transaction failure from unacceptable proceeds using our guide to why you can't sell a Solana token. They call for different investigations.
Treat a passing result as evidence about observed conditions. Your decision still depends on whether the exit is realistically available for your size.
Two Real Cases Behind the Honeypot Label
The SQUID incident and a later campaign attributed to a repeat operator illustrate different ways promoters can package the same asymmetric transaction path.
FinanceFeeds' account of honeypot tokens describes the November 2021 SQUID incident, in which selling was effectively blocked before developers withdrew liquidity, and a February 2024 case documented by Hacken, in which one operator ran at least nine schemes and stole approximately $3.2 million. The later operation reportedly used paid actors and Telegram promotion.
SQUID and the apparent paper profit
SQUID promoters associated the token with a popular television series. Buyers entered, its price surged, and holders then discovered that selling was effectively blocked.
From a buyer's perspective, the sequence is easy to understand: purchase the token, watch the displayed position appreciate, attempt to realize the gain, then discover the exit doesn't work. The developers' liquidity withdrawal left the visible price unable to support the outcome buyers expected.
Familiar branding helped attract attention, but it didn't establish an authorized relationship or a fair trading mechanism.
A repeatable promotional operation
The later campaign shows why the operator matters alongside the code. Paid appearances and messaging channels can make separate launches look like independent opportunities even when the same person controls them.
Tracing creator funding, related wallets, and previous launches can therefore add context that a token's current landing page omits. Promotional production quality doesn't establish independent demand.
Watch for these patterns:
- Borrowed credibility: Recognizable entertainment branding appears beside rapid early gains, without evidence supporting the implied association.
- Promotion ahead of evidence: Testimonials and urgent messages dominate while ordinary-wallet sale history remains unclear.
- Recurring operators: Funding paths or creator links connect apparently unrelated launches.
None of those observations proves a honeypot by itself. They identify claims that need corroboration before you send money.
The defining harm isn't an ordinary price decline. In a volatile but functioning market, buyers and sellers can transact under the available conditions; in a honeypot, the operator creates or controls an unfairly restricted route out.
Confirm the Check Before You Commit Money
Any unresolved red flag means no trade. That includes unexplained active freeze authority, a failed or punitive-fee sell simulation, contradictory checker results, or a pool that can't support your intended exit.
This is a conservative decision rule, not a claim that every flagged token is fraudulent. You don't need to prove malicious intent before deciding that the available evidence is too weak to risk your money.
Make the decision reproducible
Repeat the checks shortly before entry and before an intended exit. Record what changed, not just whether the latest interface displays green.
Keep a short decision record:
- Identity: The exact mint or contract address and the chain you checked.
- Execution: The tested route, sale amount, quoted proceeds, and unresolved errors.
- Control: Active authorities, adjustable rules, and relevant creator permissions.
- Market conditions: Liquidity, concentrated holdings, and recent creator-linked activity.
- Freshness: The timestamp and any event that would invalidate the assessment.
If you use automation, an unavailable or incomplete check should remain an unknown result rather than becoming a pass. Preserve the reason for rejecting a trade so you can review the decision later.
Use tools as inputs
Our free MemeAssist Honeypot Checker offers an address-based starting point for examining potential selling restrictions. A full token analysis costs $0.20 and includes a health score, rug risk rating, AI verdict, detailed risk breakdown, and a conditional trade plan when the data allows.
Either output is a second opinion, not a verdict. We provide automated, informational token analyses, not financial advice, and memecoins are extremely risky: you can lose all invested capital.
Commit money only when you understand the remaining uncertainty and can justify the trade without relying on a reassuring label. The practical objective is an exit you can execute.
Visit MemeAssist to check a Solana token address with our free tools or request a fuller analysis of liquidity, holders, creator behavior, and trading risks. Use the findings to investigate selling restrictions and realistic exit conditions before committing money, not as a guarantee that a token is safe.