A honeypot contract is one of the oldest and most effective traps in DeFi. The mechanics are simple: you can buy the token, you can watch the price go up, but when you try to sell, the transaction reverts. Your funds are locked. The deployer pulls the liquidity and disappears. By the time most victims understand what happened, the wallet is long gone.
Honeypots cost EVM users tens of millions of dollars every year across Ethereum, Arbitrum, BSC, and every other chain with a functioning DEX. This guide explains exactly how they are built, how to identify them before you interact, and what your limited options are if you are already holding a trapped token.
What Is a Honeypot Contract?
In smart contract terms, a honeypot is a token contract that contains hidden logic to selectively block sell transactions. The buy function works normally. The token appears in your wallet. The price may even rise as the deployer creates artificial volume to draw in more buyers. But the transfer or approval functions contain conditions that cause any sell attempt to fail — usually silently, with a generic revert error that reveals nothing about the actual cause.
The name comes from the classic security concept: a trap that looks attractive, draws the target in, and then prevents escape. In DeFi, the "honey" is the apparent price appreciation. The "pot" is the liquidity pool the deployer will drain once enough buyers are trapped.
Blockchain analytics firms estimate that thousands of honeypot tokens are deployed every month across EVM chains. The majority are small-scale operations targeting retail traders in Telegram groups, but sophisticated variants have extracted hundreds of thousands of dollars from a single deployment.
How Honeypots Work Under the Hood
Every ERC-20 token implements a standard interface: transfer(), transferFrom(), and approve(). A honeypot contract overrides one or more of these functions with conditional logic that allows buys to pass while blocking sells. The condition can be as simple as checking whether the caller is on a blacklist, or as complex as checking on-chain state variables that the deployer controls.
When you buy a token on a DEX like Uniswap, the router calls transferFrom() to move tokens from the pool to your wallet. When you sell, the router calls transferFrom() again, but in the opposite direction — moving tokens from your wallet back to the pool. The honeypot's logic detects this second call and reverts it, while allowing the first to succeed.
function _transfer(address from, address to, uint256 amount) internal {
// Allow buying from the pool (from = pool address)
if (from == uniswapPair) {
// Buy succeeds normally
_balances[to] += amount;
return;
}
// Block selling to the pool (to = pool address)
if (to == uniswapPair) {
require(_whitelist[from], "Transfer failed");
}
// Only whitelisted addresses (i.e. the deployer) can sell
_balances[to] += amount;
}
In this simplified example, the _whitelist mapping only contains the deployer's address. Every other wallet gets a revert on any attempt to transfer tokens to the trading pool. Real-world implementations obfuscate this logic further — often hiding it behind proxy contracts, using storage variables set post-deployment, or encoding the condition in a way that does not appear obviously malicious on first read.
The 7 Most Common Honeypot Patterns
Honeypot techniques have evolved considerably since the first simple examples appeared on BSC in 2020. Here are the seven patterns you are most likely to encounter in 2026, from most to least common.
On-Chain Red Flags to Check Before Buying
Before interacting with any unfamiliar token, run through this checklist. Each item takes seconds and together they cover the majority of honeypot scenarios.
How to Audit a Contract in 5 Minutes
You do not need to be a Solidity developer to perform a basic honeypot audit. The most important step — simulating a sell — requires only a contract address and the right tool.
Step 1: Run a DEX Simulation
The fastest and most reliable method is to use DropsHub's honeypot auditor. Paste the contract address, select the chain, and the auditor simulates both a buy and a sell transaction against the contract's actual on-chain state. It reports whether the sell succeeds, the effective buy and sell tax, any suspicious functions detected in the bytecode, and a plain-language risk rating. This catches the vast majority of honeypot patterns including gas exhaustion traps that manual code review can miss.
Step 2: Read the Transfer Function
If the source code is verified, locate the _transfer or transfer function on the block explorer. Look for any conditional logic that references the Uniswap pair address, a whitelist or blacklist mapping, or an owner-controlled boolean. These are the most common gates. If the function contains an external call to another contract, that contract warrants the same scrutiny.
Step 3: Check the Owner Functions
Search the source code for onlyOwner modifiers. List every function they protect and understand what each one does. Functions that can change tax rates, modify whitelist mappings, pause transfers, or upgrade contract logic are all dangerous if controlled by a single EOA without a timelock.
Step 4: Verify Liquidity Lock
Check the LP token balance of the liquidity locker contract directly — do not rely on the project's claim. Confirm the lock expiry date and that the locker contract itself does not have an owner function allowing early withdrawal. Common legitimate lockers include Team.Finance and Unicrypt, but verify the actual contract address matches these services.
Step 5: Check Transaction History
On any block explorer, filter the token's transactions to show only sells (transfers to the Uniswap pair). If there are zero successful sells and dozens of buy transactions, that is a confirmed honeypot. Even a handful of successful early sells (often the deployer's wallets) followed by zero others is highly suspicious.
DropsHub Terminal runs steps 1 through 5 automatically and surfaces the results in a single audit report. For tokens you encounter frequently while airdrop farming or trading new launches, running a quick audit before any interaction takes under 30 seconds.
Honeypot vs. Rug Pull: Key Differences
These two terms are often used interchangeably but they describe different mechanisms. Understanding the distinction matters when assessing risk.
A honeypot operates through contract logic — the token's transfer function is coded to prevent sells. Your tokens exist in your wallet and appear on explorers, but they are permanently illiquid. The deployer does not necessarily need to take any further action; the trap is already set in the code.
A rug pull is a liquidity event. The deployer withdraws their LP tokens from the trading pool, which removes all liquidity and crashes the token price to effectively zero. Sells are technically possible, but with no liquidity in the pool, you receive nothing. A rug pull requires an active action by the deployer — removing liquidity — whereas a honeypot is passive once deployed.
Many malicious projects combine both: the honeypot prevents early sellers from getting out, keeping the price stable and attractive while more buyers enter. Then, once sufficient liquidity has accumulated, the deployer performs a rug pull to extract the pooled ETH or USDC. Victims face both a sell block and a worthless token simultaneously.
A rug pull can happen to a legitimate token if the team acts maliciously. A honeypot is malicious by design from deployment. The audit steps above catch honeypots reliably — rug pull risk requires additional assessment of team identity, liquidity lock terms, and token distribution.
What to Do If You Are Already Trapped
If you have bought a honeypot token and cannot sell, your options are very limited. The honest answer is that in most cases, the funds are unrecoverable. However, there are a few steps worth taking.
- Confirm it is a honeypot — run the DropsHub auditor on the contract to verify the sell block is in the contract logic and not a temporary network or gas issue
- Check whether the contract has been flagged by security researchers — search the contract address on Twitter and in DeFi security Telegram groups; sometimes a published exploit or court-ordered recovery exists for larger-scale honeypots
- Revoke any approvals you granted to the token contract immediately, even if the tokens themselves are worthless — approval exploits can drain other assets from your wallet
- Document everything — transaction hashes, deployer wallet address, any communications with the project — in case law enforcement or a recovery service becomes relevant
- Report the contract to the block explorer (Etherscan, Arbiscan, etc.) to have it flagged, protecting future users
After being trapped in a honeypot, you may be contacted by "recovery services" offering to retrieve your funds for an upfront fee. These are almost universally scams that will compound your loss. No legitimate service can reverse confirmed on-chain transactions. Do not pay anyone claiming otherwise.
FAQ
What is a honeypot contract in crypto?
A honeypot contract is a malicious smart contract designed to let users buy a token but block them from selling it. The contract appears functional and may show growing price action, but any sell attempt fails — leaving the buyer holding illiquid tokens while the deployer drains the liquidity pool.
How do I check if a token is a honeypot?
The most reliable method is a sell simulation before buying. DropsHub's honeypot auditor simulates both a buy and a sell against the live contract and reports whether the sell succeeds, the effective tax on each direction, and any suspicious functions in the bytecode. Always audit before you interact with an unfamiliar token.
Can a verified contract still be a honeypot?
Yes. Verification means the source code is publicly readable — it does not mean the code is safe. Many honeypots are fully verified, relying on the fact that most users will not read the Solidity. Verification is a necessary baseline, not a safety guarantee. Always run a simulation in addition to reading the code.
What is the difference between a honeypot and a rug pull?
A honeypot traps funds through contract logic — sells are blocked by code. A rug pull is a liquidity removal event — the deployer withdraws from the pool, crashing the price to zero. Both result in total loss. Honeypots are coded traps; rug pulls are active actions by the deployer. Many projects combine both mechanisms to maximize extraction.