Honeypots: a successful buy does not prove a usable exit

The short answer

In token trading, a honeypot is an asset or execution path designed to accept buys while preventing ordinary holders from selling on reasonable terms. The restriction can be absolute, wallet-specific, size-specific, time-dependent, or hidden behind a tax, blacklist, external contract, proxy, hook, or mutable admin setting.

A failed sell is not enough to prove one. Markets also fail because liquidity disappears, price impact exceeds the limit, a route goes stale, gas or account funding is insufficient, an aggregator chooses an unsupported path, or the token has a disclosed pause. Reproduce the failure and identify the controlling condition before naming the mechanism.

Sell restrictions take several forms

• Revert or freeze: transfers to the pool fail for most holders, or the holder's token account is frozen.
• Allowlist or blacklist: privileged wallets can sell while new buyers or selected addresses cannot.
• Dynamic fee: a sell tax or transfer fee consumes most or all of the output, sometimes only after buyers enter.
• Limit trap: maximum transaction, minimum balance, cooldown, holding period, or per-wallet rule makes practical liquidation impossible.
• External decision: the token calls another contract, program, registry, oracle, or hook whose mutable state decides whether a transfer works.
• Upgradeable logic: a proxy or program authority changes behavior after scanners and early test trades have passed.

Some of these capabilities have legitimate compliance or launch uses. The honeypot conclusion depends on disclosure, selectivity, economic effect, retained control, timing, and evidence that the entry was presented as freely tradable.

Map the chain-specific control surface

On EVM chains, follow the transfer path through token overrides, modifiers, ownership and roles, fee logic, pair detection, external calls, proxy implementation, and every setting that an administrator can change. Read the active implementation and live storage—not only verified source attached to a familiar address.

On Solana, resolve the token program and inspect freeze authority, Token-2022 extensions, custom programs, hooks, delegates, and program upgrade authority. Default Account State can make new token accounts start frozen. Transfer Fee configuration can reduce each transfer and can be updated by its authority. Permanent Delegate can transfer or burn holder tokens. These are capabilities, not automatic proof of deception; use the retained-control audit to map who can exercise them.

Test the intended exit, not an abstract sell

Start with a current executable quote for the actual wallet and intended size. Record the input, route, pool, expected output, minimum output, price impact, transfer fees, network cost, and expiration. Simulate the full transaction where supported, then decode the exact failing instruction and error.

A tiny test can pass while a larger sell hits a limit or punitive curve. A simulation can pass while an administrator changes state before landing. A route can work through one pool and fail through another. Test several bounded sizes without turning the investigation into repeated real-money attempts, and apply the failed-swap diagnosis before attributing intent.

Transaction history shows who actually exits

Collect successful and failed sells around the same time and classify sender, amount, pool, route, tax, output, role, and resulting balance. Look for a market with many independent buys but sells limited to linked or privileged wallets. Compare rule-setting transactions, authority changes, upgrades, blacklist events, and fee changes with the arrival of outside buyers.

Absence of sells can also reflect a brand-new launch, weak demand, or incomplete indexing. Build a fixed observation window and preserve the underlying transactions. A chart's green and red candles do not expose which wallets were eligible, what tax they paid, or whether the route was executable at size.

A scanner tests a model and a moment

Honeypot scanners may simulate a buy and sell, inspect known bytecode patterns, or analyze historical behavior. They can miss proxies, external registries, delayed toggles, wallet-specific rules, unusual routers, unsupported programs, and state changes that occur after the scan. They can also flag disclosed taxes or temporary pauses without proving fraud.

Record scanner name, version or time, chain, router, simulated wallet, trade size, block, output, warnings, and unsupported features. Reproduce the material result in an explorer or simulation. “Passed” means that particular modeled path worked under observed state—not that future exits are guaranteed.

Rule out ordinary exit failure

• Depth: the pool exists but cannot absorb the position without breaching minimum output.
• Routing: the quote references a stale, unsupported, or account-intensive path.
• Fees and funding: the wallet lacks gas, SOL, token-account rent, or enough balance after transfer fees.
• State: the market, token, or account is paused or frozen under a disclosed rule that also affects insiders.
• Interface: decimals, token account, approval, allowance, or wallet display is wrong while the underlying transfer remains possible.

These conditions can still make a trade unacceptable. They simply support a different diagnosis. The rug mechanism taxonomy helps distinguish sell blocking from liquidity withdrawal or concentrated selling.

A sellability verification workflow

1. Resolve the asset and market. Save chain, full contract or mint, token program, pool, quote asset, router, and launch source.
2. Map transfer capabilities. Inspect active code, proxy or program authority, roles, limits, taxes, lists, extensions, hooks, and external dependencies.
3. Build an intended-size quote. Record route, pool state, output, minimum, price impact, transfer deductions, and network requirements.
4. Simulate and decode. Use the actual wallet and transaction path; isolate the failing instruction, condition, and live value.
5. Compare participants. Identify who sold successfully, whether they were exempt or linked, and when rule-setting transactions occurred.
6. State the narrow finding. Separate confirmed wallet-specific restriction, punitive cost, mutable risk, ordinary execution failure, and unresolved behavior.

What belongs in the journal

Record contract or mint, token program and active implementation, pool and route, wallet tested, sizes, quote and minimum output, transfer tax, price impact, gas or account requirements, simulation block or slot, decoded error, successful and failed comparison sells, exemptions, roles and authorities, setting changes, scanner method and time, ordinary failure alternatives, and the narrow evidence-based conclusion.

Primary sources