Sell simulation is the most common method honeypot scanners use to check if a token is safe. The scanner buys a small amount, then tries to sell it. If the sell fails, it flags the token as a honeypot. It sounds airtight. It is not.
Sophisticated scammers have known about simulation-based detection for years. They have built specific techniques to pass simulations cleanly while still trapping real buyers. This article breaks down exactly how they do it — and what DexScanr does differently to catch them.
A token that passes sell simulation is not automatically safe. Simulation bypass is a documented and actively used technique in DeFi scams.
1. Address Whitelisting
The simplest and most common bypass. The deployer whitelists specific addresses — usually known scanner bots and simulation wallets — and allows them to sell freely. Every other wallet gets blocked.
When the scanner runs its simulation from a whitelisted address, the sell goes through. The token looks clean. Real buyers, using non-whitelisted wallets, cannot sell a single token.
mapping(address => bool) private _whitelist;
function _transfer(address from, address to, uint256 amount) internal {
if (to == uniswapPair && !_whitelist[from]) {
revert("Transfer failed");
}
// normal transfer logic
}
DexScanr detects this by analyzing the contract bytecode directly for whitelist mappings and conditional revert patterns — without relying on simulation at all.
2. Block Number Gating
The contract allows sells freely for the first N blocks after deployment. Scanners that run simulations immediately after a token launches will see clean results. After the grace period ends, the honeypot activates.
“The honeypot does not exist when the scanner checks. It activates the moment real buyers are trapped.”
This is particularly dangerous because the window is designed to coincide exactly with the period when most scanners run their checks and when early buyers rush in.
uint256 public launchBlock;
uint256 public gracePeriod = 3;
function _transfer(...) internal {
if (to == uniswapPair) {
require(
block.number <= launchBlock + gracePeriod,
"Sells disabled"
);
}
}
3. Selective Execution Logic
The contract checks the caller’s transaction history, wallet age, or token balance before allowing a sell. Simulation wallets are typically freshly created with no history. The contract detects this and lets the sell through.
Real users who bought through normal channels have a different transaction profile. The contract identifies them and blocks the sell silently — the transaction reverts with a vague error or no error at all.
DexScanr runs static code analysis on the contract source and bytecode, identifying conditional logic that branches based on caller properties. These patterns are flagged as high risk regardless of simulation outcome.
4. Owner-Controlled Tax Switches
The token launches with a normal sell tax — maybe 5%. Simulations pass. Once enough buyers are in, the deployer calls a privileged function to set the sell tax to 99% or higher. Some contracts allow tax changes up to 100%, meaning sellers receive nothing.
This is technically not a simulation bypass but a post-launch manipulation. By the time the scanner re-checks, it may still show a low tax if the deployer resets it temporarily.
function setSellTax(uint256 tax) external onlyOwner {
require(tax <= 100);
sellTax = tax; // can be set to 100 after buyers are in
}
5. Hidden Blacklist Functions
The contract contains a blacklist function that is not called at launch. After buyers accumulate, the deployer blacklists all non-zero holders in a single transaction. Every wallet that holds the token is blocked from selling simultaneously.
Simulation passes because no wallets are blacklisted yet. The trap is set after the fact.
Any contract with a public or owner-only blacklist function that can be called post-launch is a potential trap, even if current simulation shows clean sells.
What DexScanr Does Differently
DexScanr does not rely solely on simulation. Every scan includes:
- Static bytecode analysis — detects hidden functions, whitelist mappings, and conditional revert patterns even in unverified contracts
- Ownership risk scoring — flags contracts where the deployer retains privileged functions like tax changes or blacklisting
- Liquidity lock verification — checks whether liquidity is locked and for how long
- Deployer history — checks if the same wallet has deployed known scam tokens before
- Tax analysis — reads the actual on-chain tax values, not simulated ones
No single method catches everything. DexScanr combines all of these signals into a single safety score from 0 to 100, giving you a complete picture before you buy.
🛡️ Scan Any Token Right Now
DexScanr runs directly on DexScreener — every token you view gets automatically scanned. Free to install, no signup needed.
Install DexScanr Free →Summary
Sell simulation is a useful starting point but it is not a complete defence. The five techniques above — address whitelisting, block gating, selective execution, owner-controlled taxes, and hidden blacklists — all pass basic simulation checks while still trapping buyers.
If your scanner only simulates sells, you are missing a significant portion of active honeypots. Always check on-chain contract data, ownership status, and deployer history alongside any simulation result.