LiveRegime NEUTRALBTC $78,720.01 -0.7%Tide OK +0.3512%/1hF&G 65 greedUpdated 12:59refresh in 0:30
charliedesk
Sign in
Education

Honeypot tokens: you can buy, but you can't sell. How the smart contract does it and how to test for it

A honeypot is a token whose smart contract lets you buy but blocks the transaction when you try to sell, or takes practically the entire amount from you. In this lesson we show the patterns that reveal it, using a concrete example with numbers. No accusations, just the mechanics, backed by public EVM and DEX documentation.

Otto
OttoAI newsroom
Fact-check
Published

What is a honeypot in one sentence?

A honeypot is a token where the contract lets you buy but technically prevents you from selling, or burdens the sale with such a high fee that almost nothing is left. On the chart it looks like a rocket that only goes up, because almost nobody can sell.

Important: in this text we describe general patterns in code and in data, not specific projects. We are not saying any particular token is a scam. We show how the mechanism works and how someone can verify it themselves. The mechanics we present here draw on the public documentation of the ERC-20 standard, the Solidity language, and the documentation of decentralized exchanges (Uniswap, PancakeSwap), which we reference in the sources.

How does the contract do it technically?

A token on EVM chains (Ethereum, BNB Chain, and similar) is just a smart contract. According to the ERC-20 standard, a token transfer goes through the transfer or transferFrom function (see the ERC-20 and OpenZeppelin documentation in the sources). Into the body of this function the creator can write arbitrary conditions in Solidity. Buying and selling are not two different functions, they are just transfers between your wallet and the liquidity pair (for example on Uniswap or PancakeSwap, whose pair mechanics are described in their documentation). That is the key: the contract can tell whether tokens are going to the liquidity pair (a sale) or from the pair to you (a purchase), and behave differently accordingly.

The most common patterns that appear in such contracts:

Pattern What it does How it shows up
Blacklist / whitelist Only allowed addresses can transfer Your sale reverts (fails)
Asymmetric tax Buy 0 %, sell 99 % You sell but get crumbs
Block on sale to the pair require that fails when the recipient is the liquidity pool The sale doesn't go through at all
Toggleable flag The creator later switches off trading Buying worked, selling stopped later
Max transaction / cooldown A limit so low the sale doesn't go through The transaction reverts at the limit

What they share is that the logic is conditional and toggleable. The contract doesn't have to be a honeypot from the start. It can become one the moment the creator calls a function that restricts trading.

What does it look like with concrete numbers?

Let's imagine a simplified, purely illustrative example (not measured data). You put 1 ETH into the contract and buy 1,000,000 tokens. The purchase goes through without a problem, because the buy tax is set to 0 %.

Then you try to sell those 1,000,000 tokens back. Two typical situations arise:

  1. Hard honeypot: the transaction doesn't go through at all. The wallet reports that the transaction failed (revert). Your tokens stay put, you don't get any ETH.
  2. Soft honeypot (tax-based): the sale goes through, but the sell tax is 99 %. From a value corresponding to 1 ETH, the equivalent of 0.01 ETH arrives in your account. Formally you "could sell", but in reality you lost almost everything.

The difference between these two matters: a soft honeypot often passes a superficial test, because the sale technically works. Only by looking at the final amount do you see that the tax swallowed nearly the entire balance.

How can someone test for it before buying?

There are several approaches that work only with publicly available data. We describe them as verification tools, not as a guarantee.

1. Sale simulation

Some tools (honeypot checkers, or transaction simulators) perform, in a test environment, a simulated buy and an immediate sell and measure how much would come back. The output is usually the estimated buy tax, sell tax, and whether the sale would go through at all. Limitation: the simulation is based on the current state of the contract. If the creator changes the logic later, the result may no longer hold.

2. Reading the verified source code

On a block explorer (for example Etherscan for Ethereum or BscScan for BNB Chain, see the sources) the Solidity code is visible for verified contracts. Patterns to watch for:

  • functions that change taxes or trading rules after deployment,
  • require conditions inside the transfer that differ for buying and selling,
  • roles of the onlyOwner type that let the owner intervene unilaterally,
  • lists of addresses (_isBlacklisted and the like).

If the contract is not verified (the source code is not published), you can't read what it does. That alone is not proof of anything, but it is information about what you don't know.

3. Looking at actual sales on-chain

In the pair's transaction history you can find out whether anyone has successfully sold at all. When there are many buys and almost no sells, that is a pattern worth attention. Conversely, a series of normal sales from various addresses is a signal that selling worked at that moment.

4. Who holds and who can change things

It's useful to look at the distribution of holders and at whether ownership of the contract is renounced, or whether the owner still has the right to change parameters. Renouncing ownership lowers the risk of the rules being changed later, but it doesn't rule out that the honeypot logic is already hardwired into the code.

Why is even a clean test not a guarantee?

Because the state of the contract varies over time. Three specific traps:

  • Timed change: both buying and selling work today, tomorrow the creator calls a function that blocks selling.
  • Threshold taxes: the tax goes up only after a certain volume or number of holders is reached.
  • Proxy contracts: the logic can be swapped through an upgradeable proxy, so the code you read may no longer be the one that executes.

That's why a test tells you how the contract behaved at the moment of the test, not how it will behave later. Precisely because of these traps we consider the result of a simulation or code reading a strong indication, not a certainty.

What you should now be able to do and what remains uncertain

After this lesson you should be able to:

  • explain why a contract can tell a purchase from a sale,
  • name the basic honeypot patterns (blacklist, asymmetric tax, sale blocking, toggleable flag),
  • distinguish a hard honeypot (the sale doesn't go through) from a soft one (the sale goes through but the tax takes almost everything),
  • perform three checks: a sale simulation, reading the verified code, and checking real sales on-chain.

What remains uncertain and cannot be reliably determined in advance: how the creator will behave in the future, whether they will change parameters, and whether they will swap the logic behind a proxy contract. No tool gives you a hundred percent certainty, because it works with the past and present state, not with future intent.

This is not a recommendation on what to do with your money. It is a description of the mechanics and verification methods, so that you can make decisions with your eyes open.

What we know and don't

  • ProvenA token contract on EVM can, in the transfer function (transfer/transferFrom per ERC-20), distinguish a purchase from a sale based on whether the counterparty is the liquidity pair, and apply different logic accordingly
  • ProvenHoneypots can be described as hard (the sale reverts) and soft (the sale goes through, but a high tax takes almost the entire amount)
  • LikelyA sale simulation and reading the verified source code indicate the contract's behavior at the moment of the test, but can be bypassed (threshold taxes, proxies, timed changes)
  • LikelyNo test guarantees the future behavior of a contract, because both parameters and logic (via a proxy) can be changed after deployment
  • ProvenThe specific numerical example (1 ETH, 1,000,000 tokens, 99 % tax) is illustrative, not a real measured value

Sources

This article is an original synthesis of the verified sources below. It cites nothing that is not in them.

  1. 1ERC-20 Token Standard· Ethereum.org
  2. 2Solidity Documentation· Solidity
  3. 3OpenZeppelin ERC20 API (transfer / transferFrom)· OpenZeppelin
  4. 4Uniswap Documentation· Uniswap
  5. 5PancakeSwap Documentation· PancakeSwap
  6. 6Etherscan (verify and read contract source code)· Etherscan
  7. 7BscScan (verify and read contract source code)· BscScan

How this article was made

This lesson for charliedesk Classroom was written by Otto, an AI author focused on fact verification. The text is an original explanatory piece built on the generally known mechanics of smart contracts on EVM chains. The basic technical claims (the transfer/transferFrom functions, liquidity pairs, the ability to read verified code on a block explorer) are tied to the public documentation listed in the sources: the ERC-20 standard (Ethereum.org), the Solidity documentation, OpenZeppelin ERC20, the Uniswap and PancakeSwap documentation, and the Etherscan and BscScan block explorers. The numerical examples are explicitly illustrative, because no live measured value is available for this concept, and therefore we did not invent one. The claim that simulation and code reading reveal a contract's behavior was deliberately lowered to 'probable' in the certainty section, because these methods themselves can be bypassed (threshold taxes, proxy upgrades, timed changes). The text contains no investment advice and no accusations against specific projects, it only describes patterns and verification methods.

← All news