A honeypot token is a contract you can buy into and cannot sell out of. The code accepts your money, then rejects the transfer that would take it back, usually through a permission check or a fee set high enough to leave you nothing.
The word has two other owners, and mixing them up is how people get hurt. In network security a honeypot is a decoy server left exposed on purpose so defenders can watch attackers work. In Ethereum research it originally meant something narrower and stranger: a contract written to look broken, so that whoever tries to drain it loses their own funds instead. This page covers all three and then stays with the one that costs ordinary buyers money.
Quick Answer
A honeypot token is a smart contract that lets you buy and blocks you from selling. The block usually sits in the shared transfer path as a permission check, or as a sell fee the owner can raise to 99%. Check the verified source, simulate a sell, and look at whether anyone else has sold.
Last updated August 2026.
The three things called a honeypot, and only one of them is aimed at you
The three uses share a shape. Something valuable is left where a greedy party will find it, and the person who reaches for it is the one who gets caught. What changes is who is meant to reach.
| Meaning | Who is meant to get trapped | Where you meet it |
|---|---|---|
| Network security decoy | An intruder probing your infrastructure | Enterprise security, threat intelligence |
| Classic Ethereum honeypot | Someone trying to exploit a contract | Verified source on Etherscan, security research |
| Honeypot token | An ordinary buyer | Any decentralised exchange, most often on a new listing |
The first two bait a predator. The third baits a victim and kept the name anyway, which is why a search for the word returns a page of enterprise security vendors and almost nothing about tokens. If you arrived here after a token stopped selling, the rest of this page is for you.
How a honeypot token actually blocks the sell
Almost every explanation of this stops at “hidden code blocks selling”. That is true and it is not useful, because it does not tell you where to look. Here is where to look.
When you sell a token on a decentralised exchange, you do not move your own tokens. You approve the router, and the router moves them for you, which means the call that matters is transferFrom and not transfer. Both usually funnel into one shared internal function. That shared function is where the gate goes, because a gate there catches the sell without touching the buy.
The gate sits in the shared transfer path
Reduced to its essentials, it looks like this. The deployer permits the liquidity pool and nobody else, so tokens can leave the pool (you can buy) but cannot go back into it (you cannot sell).
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
// Illustrative only. A sell-gate honeypot reduced to its essentials.
contract Trap {
mapping(address => uint256) public balanceOf;
mapping(address => mapping(address => uint256)) public allowance;
mapping(address => bool) private _allowedToSend;
address private immutable _owner;
constructor() {
_owner = msg.sender;
balanceOf[msg.sender] = 1_000_000e18;
_allowedToSend[msg.sender] = true;
}
// The deployer allows the pool, and nobody else.
function setAllowed(address account, bool allowed) external {
require(msg.sender == _owner, "not owner");
_allowedToSend[account] = allowed;
}
function approve(address spender, uint256 amount) external returns (bool) {
allowance[msg.sender][spender] = amount;
return true;
}
function transfer(address to, uint256 amount) external returns (bool) {
_move(msg.sender, to, amount);
return true;
}
// Your sell arrives here, because the router moves your tokens for you.
function transferFrom(address from, address to, uint256 amount) external returns (bool) {
allowance[from][msg.sender] -= amount;
_move(from, to, amount);
return true;
}
function _move(address from, address to, uint256 amount) private {
require(_allowedToSend[from], "transfer failed");
balanceOf[from] -= amount;
balanceOf[to] += amount;
}
}Notice the revert string. A real one says something bland like “transfer failed”, so your wallet shows a generic error and you assume the problem is slippage or gas.
A 99% sell fee is not a block, and it does the same job
The cruder version does not refuse the transfer at all. It takes the proceeds.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
// Illustrative only. The sell fee is mutable, and 9_900 basis points leaves you 1%.
contract Fee {
uint256 public sellFeeBps = 300; // 3% at launch
address private immutable _owner;
constructor() {
_owner = msg.sender;
}
function setSellFee(uint256 bps) external {
require(msg.sender == _owner, "not owner");
require(bps <= 10_000, "out of range");
sellFeeBps = bps;
}
}A 3% sell fee is ordinary. Plenty of honest tokens charge one, and the major routers ship a dedicated swap function for tokens that take a cut on transfer. The problem is not the fee, it is setSellFee. A fee an owner can move is a fee that will be 99% on the day it matters, and a scanner that checked yesterday checked the old number.
The trap can be added after you have bought
Everything above can also be added after launch rather than written in at deployment. If the token sits behind an upgradeable proxy, the deployer can swap the implementation for a new one whose transfer path has a gate in it. The address does not change. The verified source you read does not change. The behaviour does.
The most famous case worked on the same principle without needing a proxy at all. The SQUID token of November 2021 reached $2,861 before collapsing, and holders were told their funds sat behind “anti-dump technology”. CBS News reported that the operators likely left with about $3.3 million, citing an estimate from Gizmodo. Euronews reported that a wallet linked to the creators had cashed out almost 3 million euros across the same weekend. Two outlets, two currencies, two different things being counted, which is its own lesson about how badly this gets measured after the fact.
The original honeypot: contracts built to rob the robbers
The academic meaning of the term is worth knowing, because it is where the vocabulary comes from and because it is a better story.
In 2019 Christof Ferreira Torres, Mathis Steichen and Radu State published “The Art of The Scam: Demystifying Honeypots in Ethereum Smart Contracts” at USENIX Security. They analysed more than 2 million smart contracts and found 690 honeypots and 240 victims, with over $90,000 in accumulated profit for the creators. Manual inspection confirmed 87% of the flagged contracts were genuine honeypots.
These contracts were not aimed at buyers. They were aimed at people hunting for vulnerable contracts to drain. The bait was a contract that appeared to have an obvious bug, and the trap was a second mechanism the attacker did not notice.
The paper sorts eight techniques by the layer they abuse, and the grouping is the useful part:
| Layer abused | Techniques |
|---|---|
| The Ethereum Virtual Machine | Balance disorder |
| The Solidity compiler | Inheritance disorder, skip empty string literal, type deduction overflow, uninitialised struct |
| The Etherscan explorer | Hidden state update, hidden transfer, straw man contract |
The third row is the one that still matters in 2026. Those three techniques do not exploit the chain at all. They exploit the fact that you are reading the contract through a website that does not show you everything, and that is exactly the assumption a modern honeypot token relies on when it hides behind a proxy. The most common technique in the paper was the hidden state update, at 382 of the 690.
If you want the same argument applied to code that was honest when it was written, we have made it before in when a smart contract audit actually expires.
How to check a token before you buy
In order, cheapest first.
- Check the source is verified. If the explorer shows only bytecode, you cannot read what you are buying and nobody else can either. That alone is a reason to stop.
- Read the transfer path. Find the shared internal transfer function and read every
requirein it. Look for address mappings, pause flags, maximum-amount checks and fee arithmetic. - Find the owner’s powers. Search the source for functions guarded by an owner check. Anything that sets a fee, a limit, a pause or a list is a switch that can be flipped after you buy.
- Look for a real sell. On the explorer’s token page, look at transfers into the liquidity pool from ordinary wallets. If the only address that has ever sold is the deployer, stop there, because that is the behaviour without the code.
- Simulate a sell. A honeypot checker runs a buy and a sell against a forked chain and tells you whether the sell reverts. The honeypot.is API returns
isHoneypotwith ahoneypotReason, plusbuyTax,sellTaxandtransferTax, which is the shape most of these tools share. - Check who can change the code. If there is a proxy, find its admin. An upgradeable token controlled by one key is a token that can become a honeypot later.
What the scanners cannot see
Simulation checkers are genuinely useful and they are the fastest thing available. They are also a point-in-time answer to a question with a moving answer. Honeypot.is says so in its own documentation, noting that its contract-code results are “cached and may be outdated”.
Three things beat a simulation. A fee the owner raises after the check. A blocklist populated after the check. An implementation swapped after the check. A clean result means the token was sellable when the tool looked, and nothing more.
Someone reading this because a token has already trapped them wants the other half of the problem, which is watching a contract after it is deployed rather than before. That is what post-deployment monitoring is for, with detectors tuned to a protocol’s own logic instead of generic thresholds.
Honeypot or rug pull? They are not the same thing
The two get used interchangeably and they describe different mechanics.
| Honeypot | Rug pull | |
|---|---|---|
| What happens | You cannot sell | You can sell, into nothing |
| Where the trap lives | In the token contract’s transfer path | In the liquidity, which the team removes |
| When you find out | The moment you try to exit | When the price goes to zero |
| Detectable before you buy | Often, by reading the code or simulating | Harder, it depends on lock and vesting arrangements |
A honeypot is a code problem. A rug pull is a custody and incentives problem, and it needs a different checklist, which we set out in when a rug pull is not a rug pull. Plenty of scams are both.
If you are building the token, not buying it
There is a problem on the other side of this that almost nobody writes about, and it is expensive.
The detectors above look for code patterns, not intent. Four features that legitimate protocols ship for good reasons trip them:
- A transfer fee, whether it funds a treasury, a buyback or a liquidity floor.
- Pausable transfers, which most serious teams want as an incident control.
- A blocklist, which a regulated or sanctions-exposed token may be obliged to hold.
- An upgradeable proxy, which is standard practice for anything expected to change.
Ship any of those and a scanner may return a warning, an aggregator may show a risk flag, and the first person to notice will post the screenshot rather than the source. The answer is not to strip the features out. It is to make the intent legible and the powers bounded.
- Verify the source, and keep the verified source current after every upgrade.
- Document each privileged function in plain language, including its ceiling. A fee that cannot exceed 5% because the setter enforces it is a different object from a fee that can go to 99%.
- Put the owner behind a timelock or a multisig, so a change is visible before it lands rather than after.
- Publish the audit, and publish the re-audit when the code changes. A manual audit at Fidesium starts at $5,000, covers logic and economic risk line by line, and includes two rounds of fix verification.
- Keep scanning after launch. An audit describes the code on the day it was read, and a proxy makes that day expire the moment someone upgrades. Continuous scanning starts at $399 a month and runs on every commit.
A protocol that cannot show what its owner key can do is asking to be mistaken for a honeypot, and in this market that mistake is priced immediately. Our published reports are at the audit portfolio, 23 of them across 16 protocols on EVM chains and Solana, and every audit is minted as an on-chain record so the result can be checked rather than claimed.
Security is a process, and this is one of the places that stops being a slogan. Talk to the audit team if you want the powers in your token written down before someone else describes them for you.
Frequently asked questions
What is a honeypot in crypto?
A honeypot in crypto is a token whose smart contract lets you buy but prevents you from selling. The restriction is usually a permission check in the contract’s transfer path, or a sell fee set so high that the proceeds are worthless. The term is borrowed from network security, where a honeypot is a decoy server used to attract and study attackers.
How do I know if a token is a honeypot before I buy?
Check that the contract source is verified on the block explorer, read every condition in the shared transfer function, and list the functions the owner can call. Then look at the token’s transfer history for sells by ordinary wallets rather than only the deployer, and run a honeypot checker that simulates a buy and a sell. Any one of these can miss a honeypot, so use several.
Can a honeypot checker be wrong?
Yes, in both directions. A checker simulates a trade at one moment, so a token can pass and then become unsellable when the owner raises the fee, adds an address to a blocklist, or upgrades the contract behind a proxy. It can also flag a legitimate token that has a transfer fee, a pause control or an upgradeable proxy for entirely ordinary reasons.
What is the difference between a honeypot and a rug pull?
In a honeypot the trap is in the token contract and you cannot sell at all. In a rug pull you can sell, but the team has removed the liquidity so there is nothing to sell into. A honeypot is a code problem you can often detect by reading the contract. A rug pull is a custody and incentives problem, and many scams are both.
Why does searching for honeypots return results about servers?
Because the network security meaning came first and is far more common. A honeypot in that sense is a system deliberately left exposed so defenders can observe how attackers behave. The crypto meaning reuses the word for something close to its opposite, a trap set for ordinary buyers rather than for intruders.
Are honeypot contracts illegal?
Deploying a contract designed to take money from buyers who cannot sell is fraud in most jurisdictions, whatever the code does. Enforcement is a separate question from legality, and cross-border recovery is difficult. Treat prevention as the only reliable control, because funds that leave a wallet in this way are rarely recovered.
Can an audit tell me a token is safe?
No, and no honest auditor will tell you otherwise. An audit reports what was found in a specific version of the code at a specific time, including who holds privileged powers and what those powers can do. It cannot promise that nothing was missed, and it says nothing about a version of the code deployed afterwards, which is why continuous scanning exists alongside it.
What should I do if I am already holding a honeypot token?
Stop adding to the position, and do not pay anything to a service promising recovery, because those are usually a second scam aimed at the same victim. Record the contract address and your transaction hashes, report the token to the explorer and to the aggregators listing it, and check whether the exchange you used has a fraud process. Assume the funds are gone while you do this.
