Anatomy of a honeypot and a sell-blocking contract

The buy is the advertisement

A honeypot, in the sense traders mean it, is a token you can buy and cannot sell on normal terms. The buy lands. The wallet shows a balance. The sell reverts, or it succeeds only for the owner's wallets, or a tax takes so much of the sale that the proceeds are a rounding error. The chart can still move up while outsiders are buying, because buys are allowed. The people who notice are the ones who try to leave.

That is a different event from a liquidity rug, where the pool itself is removed and there is nothing left to sell into. Both end with a seller stuck. The contract trick and the pool trick are different rows in a report. This page is the contract trick. The liquidity guide is the pool. The rug pull note is the short map of both.

Nothing here is a recipe for writing the contract. The useful part is recognizing the shape before you sign a buy, and reading a checker row without treating the word honeypot as a mood.

Where the block is written

ERC-20 transfers usually pass through one internal function. A sell on a decentralized exchange is that function, called by the pool, moving tokens from you to the pool and the other asset back. A honeypot edits that path. The edits are ordinary code, which is why a verified contract can still be a honeypot. Verification means you can read the edit. It does not mean the edit is fair. The Etherscan guide is the way to open that file.

A blacklist mapping is the blunt version. Before the balances change, the function checks the sender or the recipient against a list the owner can update. Buys from the pool to a new wallet are allowed. Sells, where the seller is the sender, hit the list and revert. The owner address is often exempt, so the people who deployed it can sell. Canonical USDT has a blacklist too. Tether uses it as an issuer control. On that known contract the checker calls the row context. On an unknown contract, a blacklist is a warning because the same switch blocks sellers after they buy.

A whitelist is the same idea pointed the other way. Only approved addresses may sell. Everyone else may buy. The function names vary. The behavior is a sell that reverts for you and works for them.

A tax is the version that does not revert. The transfer sends part of the amount to the owner, a marketing wallet, or the pool, and the rest to the recipient. A small tax is a fee. A sell tax of nearly the whole amount is a honeypot that still 'succeeds' in the technical sense: the transaction confirms, and you receive almost none of the other asset. Some contracts let the owner change the tax after the buys have landed. GoPlus calls that pattern slippage modifiable. The checker treats it as a warning, because the tax you simulated is not a promise about the tax on the day you sell.

Other levers show up often enough to name. A max transaction or max wallet set near zero stops a normal sell while still allowing dust. A trading switch leaves buys off or sells off until the owner flips it, and the owner may never flip the sell side. A function that rewrites balances, which GoPlus reports as the owner being able to change balances, can show you tokens in the wallet that the contract will not move. Hidden mint sits beside these: the owner creates supply and sells into the bids. That one is covered in the privileges guide. It ruins the price without needing the sell to revert.

What a simulation tries

honeypot.is, on Ethereum-style chains, attempts a buy and a sell against a router and reports whether the sell could be completed, along with the taxes it observed. The checker reads that result. If honeypot.is says the token is a honeypot, the row is critical: sell simulation failed. If the call comes back with HTTP 401 or 403, the checker marks the source down and says the decline is an outage, not a honeypot. If the body has no record, the sell row is not checked. It is not marked clear.

GoPlus returns its own honeypot flag, a cannot-sell-all flag, and buy and sell tax fields. The checker uses those on the same row, labeled Honeypot and sell tax. A tax at or above 50 percent is critical. A tax at or above 10 percent and below 50 percent is a warning. A smaller tax is reported as information. Those cuts are this site's bands, documented in the methodology. They are not a market standard and they are not a judgment that a 9 percent fee is honest.

Solana is outside honeypot.is. The checker does not pretend that source ran. RugCheck and GoPlus's Solana record cover mint, freeze, and a non-transferable flag instead. A Solana mint marked non-transferable is the checker’s critical sell block on that chain. Freeze authority is the other critical control: the authority can stop an account from moving the token.

A worked tax, labeled as arithmetic

This is arithmetic, not a trade this site placed. You buy 1,000 tokens. The contract takes 10 percent on the transfer in, so the wallet receives 900. You sell 900. A 10 percent tax on the way out moves 90 tokens aside and sends 810 toward the pool. The pool then pays you the other asset for those 810, minus price impact, which this paragraph does not invent a number for. You have paid the fee twice and you still depend on the pool having the other asset.

Change the sell tax to 99 percent. The transaction can still confirm. You send 900 tokens and 9 of them are eligible to swap. The rest goes to the fee receiver. A simulator that only checks 'did the transaction revert' may call that a success. A simulator that reports the tax, which is what honeypot.is and GoPlus do when they have a figure, shows the 99 percent. The checker’s 50 percent critical band is there so that case is not described as a clean sell.

Now change the mechanism instead of the percent. The sell reverts with a blacklist error, and the owner’s wallet is exempt. There is no honest tax to compute. The simulation fails. That is the critical honeypot flag, separate from the tax band. If the owner can edit the blacklist after you buy, the simulation you ran yesterday is a snapshot. It is not a lock on the function.

False alarms and real leftovers

A failed sell simulation is a reason to stop. It is not always a blacklist. A pool with almost no liquidity can make a simulated sell fail because the swap cannot be filled. The checker keeps that separate when DexScreener has no indexed pool: the liquidity row warns that there is no market, and the age row is left unchecked. Do not read a missing pool as a clear bill of health, and do not read every revert as a hidden blacklist if the page also says there is no market. Read both rows.

A token that charges a real fee, including some reflection or rebase designs, can confuse a simulator that assumes a plain ERC-20. The simulation may fail or the tax may look wild because the balance changes for reasons other than a simple percent. That is still a reason not to buy until you can explain the balance change. It is not a reason to ignore the flag because a forum said fee tokens are normal.

Trading paused before a launch looks like a honeypot on the day you check, and it may become a normal market later, or it may never enable sells. You cannot see the later switch in today’s simulation. If the contract has a public trading toggle and an owner, assume the owner keeps the switch. Walk away unless you already trust that issuer for other reasons, the way a reader might already understand Tether’s pause on canonical USDT. Trust here is your knowledge of the issuer, not a score.

A low score with a clear sell row means the sources that answered did not flag a honeypot or a high tax. The owner may still be able to change the tax later. Look at the warning for a modifiable tax, and at the proxy row. An upgrade can replace the transfer function entirely. A clear simulation of today’s code does not bind tomorrow’s implementation. That limit is why the checker’s low band says it is not a guarantee.

Before you buy

Paste the address into the checker and into the explorer. If the sell row is critical, do not buy it and do not approve a spender for it. If the row says not checked, you do not have a simulation. Treat the gap as a gap. If the row is context on a known stablecoin or wrapper, read the label and confirm the address is the canonical one, not a copy.

Reject any site that asks you to connect a wallet 'so the checker can see your bag.' This checker does not connect a wallet. A page that does, especially one that arrived in a direct message, is a different product.

1. Copy the contract address from the explorer, not from a chat image.
2. Run it in the checker. Read Honeypot and sell tax before you read the gauge.
3. If a source is down or empty, leave the decision at not checked. Do not fill the gap with a ticker search.
4. On the explorer, search the source for blacklist, whitelist, tax, fee, maxTx, and onlyOwner. If you cannot read source, stop or accept that you are guessing.
5. If you already bought and the sell fails, do not sign a second transaction from a 'recovery' site. The second signature is a common way the loss gets worse.

• You know whether the sell reverts, taxes most of the amount, or was not simulated.
• You know whether an owner can change that tax or upgrade the contract after the test.
• You are not treating a paused launch as a promise that sells will open.
• You are not treating canonical USDT’s issuer blacklist as the same fact as a new token’s blacklist.
• You did not approve a spender to 'test the sell.' A test sell of a tiny amount, if you choose to do one, is a swap you can read. An approval is a different permission.

Questions