TrustDex › Guides › Honeypot variants
Honeypot variants: sell-tax traps, blacklists and conditional blocks
There isn't one honeypot — there's a family of them, each blocking your exit through a different mechanism. Knowing the variants tells you which detection signal to trust and which one can be fooled.
If you already understand the basic idea — a token you can buy but not sell — the useful next question is how the exit gets blocked, because the mechanism determines what a scanner can and cannot see. Some variants leave loud fingerprints in the contract code. Others hide behind owner-only settings that look harmless until they're flipped. The nastiest ones are engineered specifically to defeat the automated tests people rely on. This guide walks through each major variant of the honeypot pattern and the specific tell that gives it away.
Run a honeypot-pattern check
Drop in a contract or mint address — the report flags sell restrictions and owner powers.
The 100% sell tax — and its slow-motion cousin
The crudest variant never blocks your sell at all. The transaction goes through, the pool takes your tokens, and a transfer hook quietly diverts the entire proceeds — a tax set at or near 100% — to the contract or the deployer's wallet. On an explorer the sell looks like a success, which is precisely the point: any tool that merely asks "did the sell revert?" will wave this token through.
The escalating version is more patient. It launches with a plausible fee, low enough that early sellers get out and post proof that exits work. The rate is stored in an owner-settable variable, and once volume builds, the deployer ratchets it upward — sometimes in steps, sometimes straight to confiscatory levels. There was never a moment where sells "broke"; the terms just changed under everyone's feet. The tell here isn't the number, it's the mutability: a setter function with no upper bound means today's fee is a courtesy, not a rule.
Blacklists: everyone buys, you specifically can't sell
A blacklist honeypot keeps trading open in general and closes it per address. The contract holds a mapping of blocked wallets, and the transfer function checks it before letting tokens move. Deployers use it in a few styles. Some sweep every buyer into the list within seconds of purchase, running a bot that watches the pool. Others are selective, letting shrimp trade freely to keep the chart alive while blocking only the wallets that accumulated real size. A third style automates the whole thing: cross a balance threshold and the contract flags you on its own, no bot required.
Blacklists are detectable in two ways. In code, look for address mappings consulted inside the transfer path with names like isBot, blocked, or something deliberately innocuous. On chain, the giveaway is behavioral: buys flow constantly while sells come only from a small, repeating set of addresses — usually the deployer's own cluster.
Whitelist windows: sells are off unless you're on the list
Flip the logic and you get the whitelist variant: transfers are restricted by default, and only approved addresses — the deployer, the pool, a marketing wallet — may sell. Often it's dressed up as a legitimate anti-snipe launch phase, "trading opens soon," with a flag the owner promises to flip. In the honeypot version the flag either never flips, or the exemption list quietly stays in force after "launch." Every green candle you're watching is the whitelisted crew selling to you. When a contract has both a global trading toggle and an exemption mapping, ask a simple question: if the toggle is still closed, who has been generating all these sells?
Balance rewrites and phantom tokens
Some traps don't touch the sell function because they've already taken the tokens. A malicious contract can expose owner functions that rewrite the balance mapping directly — reducing your recorded holdings, zeroing them, or minting phantom balances that display in wallets but can never actually move. You believe you hold the token because your wallet says so; the ledger the contract actually settles against says otherwise. Related tricks make balanceOf return one number while transfers compute against another. The signal to hunt for is any function that mutates balances outside of a normal transfer, mint, or burn — legitimate tokens have no business editing who owns what by fiat.
One trap, many disguises: every variant on this page produces the same victim experience — a chart that only goes up while your exit silently doesn't exist. The variants matter to detection, not to outcome. That's why a scan that enumerates retained powers beats any single pass/fail sell test.
Conditional honeypots: armed after you're in
A conditional honeypot ships in an honest state and turns hostile on a trigger. The trigger can be time — a block number or timestamp after which restrictions activate. It can be a threshold — once liquidity or holder count crosses a target, the trap springs, maximizing the haul. Or it can be manual: a pause switch, an owner-settable tax, or an upgradeable proxy through which the entire transfer logic is swapped for a blocking version. Early buyers genuinely could sell, and their successful exits become the scam's best marketing.
This variant is why point-in-time verdicts age so badly. The honest question is never "can people sell at this moment?" but "what would have to change for sells to stop, and who can change it?" If the answer is "one address, in one transaction," the token is a honeypot-in-waiting regardless of its current behavior. Upgradeable contracts deserve special suspicion here — a clean implementation today constrains nothing about tomorrow's.
Simulation-resistant designs: built to pass the test
Honeypot checkers typically work by simulating a sell — spin up a test wallet, buy, immediately sell, report whether it worked. So the arms race moved to distinguishing the tester from the victim. Some contracts exempt addresses that bought in the same block or hold dust-sized amounts, which describes test wallets and no real holder. Some restrict only addresses that have accumulated over multiple purchases. Others inspect tx.origin or gas parameters to spot simulation environments, or randomize the block so that any individual sell might succeed while sustained selling can't. And the delayed-arming designs from the previous section defeat simulation trivially: the test runs while the trap is still open.
The defense is to stop treating "checker says sellable" as a clearance. Treat it as one input, and weight the structural evidence — unverified or upgradeable code, owner privileges over taxes and transfers, exemption mappings, concentrated supply — more heavily than any behavioral snapshot.
Matching the variant to its signal
| Variant | How your exit dies | Best detection signal |
|---|---|---|
| 100% / escalating tax | Sell succeeds, proceeds diverted | Unbounded owner-settable fee variables |
| Blacklist | Your address is blocked post-buy | Address mappings checked in the transfer path |
| Whitelist window | Only exempt wallets may sell | Trading toggle plus exemption list; ask who's selling |
| Balance rewrite | Your recorded holdings are edited away | Functions mutating balances outside transfers |
| Conditional | Trap arms on a timer, threshold, or switch | Pause flags, settable params, upgradeable proxy |
| Simulation-resistant | Test sells pass, real ones don't | Structural red flags outrank a passing sell test |
Check the structure, not just the snapshot
A TrustDex scan reads retained powers and restrictions — the things a passing sell test can miss.
Frequently asked
Is a 100% sell tax the same thing as a honeypot?
Functionally yes. The transfer technically succeeds, but the contract routes your entire proceeds to itself or the deployer, so you exit with nothing. Because the transaction doesn't revert, naive checkers that only test whether a sell executes will report the token as sellable.
Can a token that was sellable yesterday become a honeypot today?
Yes, and this is common. Contracts with owner-settable tax rates, editable blacklists, pausable trading, or upgradeable logic can flip from open to blocked in a single transaction. A sell test only proves the state at the moment it ran, which is why the powers a contract retains matter more than any one snapshot.
How do blacklist honeypots decide who gets blocked?
Most keep an owner-editable mapping of addresses. Some deployers block every buyer as they come in, while others wait and blacklist only the wallets holding meaningful size. A few automate it, flagging any address whose balance crosses a threshold, so small test wallets sell fine while real victims are stuck.
Why do some honeypots pass automated honeypot checkers?
Checkers work by simulating a sell from a test wallet. A simulation-resistant honeypot distinguishes that test from a real victim — by exempting unknown fresh wallets, keying restrictions to accumulated buyers, reading transaction origin, or arming only after a delay — so the simulation succeeds while genuine holders are blocked.
Do honeypot variants exist on Solana too?
The mechanics differ because standard SPL tokens can't carry arbitrary transfer logic, but the outcomes are reproduced with the tools Solana does have: an active freeze authority can lock individual holders after they buy, and Token-2022 extensions can impose confiscatory transfer fees. The chain changes the wrench, not the trap.