Using simulated sales to check if a token can be sold is a common detection method. However, many honeypot contracts check the transaction sender's address — if you use a transaction simulator to simulate a sell, it detects that the caller is a simulator rather than a real user, bypasses restrictions to make the simulation succeed, and only when you buy with a real wallet do you find you can't sell at all.
Here are 3 steps to bypass the illusion of a "successful simulated sell" and identify honeypots.
Prerequisite: Understand the "Whitelist" Camouflage Mechanism of Honeypots
The core logic of a honeypot contract is to only allow specific addresses to sell, locking all others.
The two most common implementations:
Blacklist mechanism: The contract checks in the
transferfunction whether the sell target is a liquidity pool address. If so, and the sender is on the blacklist, the transaction fails. When buying, the sender is the pool and recipient is the user, so the blacklist check is not triggered. Thus a real user address is automatically added to the blacklist after buying, and selling immediately fails.Whitelist mechanism: The contract only allows pre-set addresses by the deployer to sell tokens. Normally, if a simulation tool's address is not on the whitelist, the check should show "sell failed". But advanced honeypots detect whether the caller is a "contract address" or a "normal wallet address". When a simulation tool (essentially a contract) triggers a sell, the contract recognizes the caller as a simulator and temporarily allows it, making the simulation result show "can sell"; when you buy with a real wallet, your address is not on the whitelist, and selling instantly fails.
Step 1: Use a "Random Wallet" Instead of a "Contract" to Simulate Selling
Many honeypots specifically exempt contract addresses used by simulation tools. Simulating a sell with a non-contract address can bypass this camouflage.
What to do: Use a detection tool that supports "non-contract address simulation" or manually attempt a small sell with a regular wallet.
How to do it:
Case A (using dedicated detection tools): Simulation engines of tools like DEXTools, Honeypot.is, GoPlus Security support forced simulation of a sell from a "random non-privileged wallet address". If the simulated sell fails, it's a direct honeypot verdict. But if it succeeds, you still need to proceed to the next step — because "time-lock" type honeypots may initially allow all addresses.
Case B (manual small-scale test): Buy a tiny amount of tokens with a small wallet, then immediately try to sell. This is the most direct verification. But be careful: if the honeypot has a "time lock" or "trading volume threshold", an early small sell may succeed, and it will only lock after pool size or time conditions are met.
When is this step complete: You have completed at least one non-contract address sell attempt or simulation, and recorded the result.
Common failure reason: Only using one detection tool and feeling safe after a pass. The tool's simulation environment is not perfectly accurate; some honeypots can recognize bytecode characteristics of simulation contracts and bypass detection.
Step 2: Check the Contract's "Upgrade Proxy" and "Hidden Permissions"
If the contract is upgradeable and upgrade permissions remain with the deployer, today's simulated "safety" result is meaningless — the deployer can swap the contract logic for a malicious version after you buy.
What to do: Check on the block explorer whether the contract uses a Proxy pattern, and who is the Proxy Admin Owner.
How to do it:
Search for the token contract address on Etherscan/BscScan. If the page top shows "This contract is a proxy", it indicates an upgradeable architecture is used.
Check the Proxy Admin's Owner address:
If it's a burn address (0x000...), upgrade permissions have been renounced, the logic can no longer be modified, relatively safe.
If it's an EOA wallet or multi-signature address, the contract can still be upgraded. This means: even if simulated selling is normal today, the deployer can at any time replace the logic with a new version containing a blacklist.
Check if the contract contains hidden permission functions like
setBlacklist,addBlacklist,setTax,enableTrading. Even if not currently active, the deployer can activate them later.
When is this step complete: You have confirmed whether the contract is upgradeable and who holds the upgrade/management permissions.
Step 3: Check if "Holder Distribution" Is Abnormally Concentrated
If the majority of the supply is in very few addresses, those addresses are whitelist addresses controlled by the deployer — they can sell, you cannot.
What to do: View the token holder distribution on the block explorer's "Holders" page.
How to do it:
If the top 10 addresses hold more than 50%-80% of the total supply, and there are no obvious "Burn address" or "LP lock contract" labels, this is a highly dangerous signal.
Check if there are funding connections between these large addresses (mutual transfers, receiving tokens at the same time). If multiple large addresses behave identically, they are likely a "whitelist address matrix" controlled by the same entity.
If the total number of holding addresses is extremely low (a few dozen to a few hundred) and the liquidity pool locked amount is very low, it's a typical honeypot characteristic — a small number of real users buy, but there is simply not enough funds in the pool for everyone to exit.
When is this step complete: You have determined whether the token distribution is overly concentrated in a few addresses, and whether those addresses are linked to the deployer.
How to Confirm Your Operation Is Correct?
After completing the above three steps, answer these three questions:
Did the non-contract wallet simulated sell succeed?
Is the contract upgradeable and the upgrade permission not renounced?
Is the holder distribution overly concentrated, and are large addresses linked to the deployer?
If the answer to question 2 or 3 is "yes", even if the simulated sell passed, the token is a high-risk honeypot, and it is recommended to skip it entirely. If all three pass, it still does not guarantee 100% safety — but at least you have avoided the most common types of deception.
