MEVDAO

Anti-Snipe Token Tax & Blacklist Detection for Snipers

By Merunas Grincalaitis · · 12 min read · 0 views

By Merunas Grincalaitis (X · GitHub · DEV · Hashnode · Telegram), Founder & Lead MEV Engineer at MEV DAO — Ethereum smart contract, Flashbots & MEV builder since 2017. Last updated: October 2026.

TL;DR: Every profitable Ethereum launch sniper runs an automated anti snipe token and token tax checker pipeline before tipping a block builder. Static web scanners take 30 to 90 seconds to index new ERC-20 bytecode—which is five blocks too late for block-0 entries. By reading five specific Solidity patterns (_transfer fee multipliers, block-number deadblocks, hidden isBlacklisted mappings, max-wallet caps, and external proxy calls) plus executing an in-memory eth_callBundle buy-and-sell simulation, you can filter out 99% of malicious launches in under 100 milliseconds.

Part of the Ethereum Sniper Bots, Token Launches & Honeypot Defense Topic Cluster: Start with our Pillar Guide, How Ethereum Sniper Bots Work: Same-Block Buys With Flashbots (and the Real Risks), for the complete architectural blueprint. This guide provides a 60-Second Pre-Snipe Diagnostic Script & 2-Block Anvil Simulation Harness to detect hidden taxes and blacklists in real time (for an architectural breakdown of how deployers code launch restrictions, see Anti-Snipe Token Launches: Taxes, Blacklists and Trading Delays).

When a new ERC-20 liquidity pool lands on Uniswap V2, V3, or V4, you do not have time to paste the contract address into a browser-based token tax checker and wait for a green checkmark. By the time a public web interface indexes the newly deployed bytecode, block-0 searchers have already captured the initial price discovery—or, far more often, naive retail bots have already been trapped inside an anti snipe token contract that levies a 99% sell tax or silently freezes early buyers.

I have written and audited both sides of this cat-and-mouse game on Ethereum mainnet: launch contracts designed to punish predatory bots, and high-speed sniper executors designed to detect those traps before risking a single wei of ETH. Below is the exact 60-second manual and sub-100ms automated playbook for reading a token contract, verifying dynamic tax logic, and avoiding blacklist traps.

Architecture diagram of anti snipe token workflow on Ethereum showing Launch Tx Detected, Anvil Tax/Sell Sim, Block-0 Bundle Sign, and Builder Coinbase Tip
Figure 1: End-to-end Ethereum execution pipeline for anti snipe token (Launch Tx Detected → Anvil Tax/Sell Sim → Block-0 Bundle Sign → Builder Coinbase Tip).

Why web-based token tax checker tools fail on block-0 launches

Most traders rely on public scanners like TokenSniffer, Honeypot.is, or a Telegram discord token sniper alert channel to tell them whether a token is safe. While those tools work reasonably well for tokens that have been trading for twenty minutes, they fail completely during the first three blocks of a launch for three technical reasons:

  1. Pre-liquidity state blindness: Before the developer's addLiquidityETH or enableTrading() transaction executes, trading is disabled. A standard static or eth_call checker simulates a buy against the current confirmed block—where trading is still closed—and falsely reports every pre-launch contract as a honeypot token or untradeable asset.
  2. State-dependent anti-snipe hooks: Modern anti snipe token contracts do not hardcode a permanent 99% tax. Instead, they check if (block.number <= launchBlock + deadBlocks) inside the _transfer function. If a scanner checks the contract five blocks after launch, it sees a clean 1% tax, completely missing the fact that anyone who bought in block 0 or block 1 was permanently written to a bots[] mapping.
  3. External oracle and Unchecked Call traps: Sophisticated scammers hide their blacklist logic inside an unverified external contract called during _beforeTokenTransfer (often disguised as an antiBot or liquidityManager library). Bytecode regex scanners see a clean ERC-20 shell and give it a 100/100 score while the external helper blocks every sell from non-whitelisted wallets.

If you want to understand how launch developers construct these traps from the ground up, read our companion breakdown on Anti-Snipe Token Launches: Taxes, Blacklists, and Trading Delays and our guide to Honeypot Tokens: How to Spot One Before You Buy.

The 60-second manual audit: Reading an anti snipe token contract

When a deployer verifies source code on Etherscan five minutes before adding liquidity—which happens constantly on hyped Ethereum meme coin and utility launches—you can audit the contract in 60 seconds flat by pressing Ctrl+F inside the Code tab for five specific signatures.

Solidity Pattern to Search What Safe Code Looks Like Red Flag / Anti-Snipe Trap Automated Bot Defense
_transfer( or _update( Standard balance deduction plus a capped fee (require(tax <= 500)) Conditional branch checking block.number < launchBlock + N that sets fee = 99 or isBot[to] = true Simulate buy + sell across block.number and block.number + 1 in eth_callBundle
blacklist / bots / isSniper No address-freeze mapping, or mapping permanently locked on openTrading() Owner-callable setBots(address[] calldata) or automatic flagging on block 0 Reject any contract with an active owner-controlled blacklist if owner is not renounced
maxWallet / maxTxAmount Hardcoded minimum floor (e.g., >= totalSupply / 100 or 1%) setMaxTxAmount(uint256) with no lower bound, allowing owner to set max sell to 0 Parse storage or ABI limits and cap buy size to 0.95 * maxWallet
swapTokensForEth / swapBack Triggered only on sells (to == uniswapV2Pair) with a reasonable threshold Triggered on buys or lacking an inSwap lock, causing gas griefing or intentional reverts Trace gas consumption on both buy and subsequent sell transactions
External call / staticcall Calls only to known IUniswapV2Router02 or IUniswapV2Factory addresses Calls to an arbitrary address private _guard or IERC20Metadata(hook).check(from, to) Decompile or trace internal CALL opcodes; reject unknown external contract dependencies

Step 1: Inspect _transfer (or OpenZeppelin v5 _update) first

Every ERC-20 tax, max-wallet limit, and blacklist check on Ethereum lives inside _transfer(address from, address to, uint256 amount) (or _update in newer OpenZeppelin 5.x contracts). Do not waste time reading standard boilerplate at the top of the file. Jump straight to _transfer and trace every if statement between the function header and the final balance update.

In a typical anti snipe token, you will see a block like this:

if (from == uniswapV2Pair && to != address(uniswapV2Router) && !_isExcludedFromFee[to]) {
    require(tradingOpen, "Trading not active");
    require(amount <= _maxTxAmount, "Exceeds maxTx");
    require(balanceOf(to) + amount <= _maxWalletSize, "Exceeds maxWallet");
    if (block.number <= launchBlock + 2) {
        _isBlacklisted[to] = true;
    }
    taxAmount = amount * ((_buyCount > _reduceBuyTaxAt) ? _finalBuyTax : _initialBuyTax) / 100;
}

Notice how two separate mechanisms fire simultaneously:

  • First, block.number <= launchBlock + 2 silently writes the buyer's address into _isBlacklisted[to] = true without reverting the buy! Your buy transaction succeeds, the developer takes your ETH in the pool, and when you try to sell ten seconds later, require(!_isBlacklisted[from]) reverts your exit.
  • Second, _initialBuyTax is charged until _buyCount exceeds _reduceBuyTaxAt. Many contracts set _initialBuyTax = 30 and _initialSellTax = 35 for the first 25 buyers, meaning if you snipe and flip within three blocks, more than half your position evaporates into the deployer's tax wallet.

Step 2: Check whether the owner can change taxes or limits after launch

A clean token tax checker verification at block 0 means nothing if the contract owner can call setFees(99, 99) in block 4. Search the contract for onlyOwner (or custom modifiers like onlyTaxWallet or onlyDev, which scammers keep active even after calling renounceOwnership()!).

Specifically, verify:

  1. Does renounceOwnership() actually clear the privileged role, or did the developer leave a secondary address private _marketingAdmin that can still modify state?
  2. Are there setter functions for taxes (setTax, updateFees), limits (setMaxWallet), or pair addresses (setPair, setRouter)? If a developer can call setPair(fakeAddress) after launch, they can break the sell path on Uniswap instantly.

Automated block-0 simulation: How a Flashbots token sniper verifies safety

Manual code reading works when a contract is verified ahead of time, but on fast stealth launches, your Ethereum Sniper Bot: Flashbots Same-Block Sniping on Uniswap has to make a buy-or-skip decision in under 50 milliseconds against unverified bytecode.

Here is how a production crypto sniper bot executes an automated token tax checker and anti-blacklist test using a local Reth/Geth node or Anvil state override before submitting a bundle:

  1. Construct a 4-transaction simulation bundle: Whenever the mempool monitor spots a pending addLiquidityETH or openTrading transaction (Tx1), the bot builds a simulated sequence:
    • Tx1: The developer's pending liquidity/enable transaction.
    • Tx2: Your sniper wallet buying X ETH worth of the token.
    • Tx3: A simulated approve(router, type(uint256).max) from your sniper wallet.
    • Tx4: A simulated swapExactTokensForETHSupportingFeeOnTransferTokens selling 100% of the tokens received in Tx2.
  2. Execute across block N and block N+1: Using eth_callBundle (or custom EVM state inspection), the bot runs [Tx1, Tx2] in block N and [Tx3, Tx4] in both block N and block N+3. Why test two different sell blocks? Because some anti snipe token contracts block same-block sells (require(lastBuyBlock[from] < block.number)) while others allow same-block sells but activate a blacklist once block.number > launchBlock.
  3. Calculate exact effective round-trip tax: Instead of trusting a contract's public buyTax() getter—which scammers routinely fake—the bot measures actual ETH out vs. ETH in after compensating for AMM price impact: $$ ext{Effective Retained Ratio} = rac{ ext{ETH Received in Tx4}}{ ext{Theoretical Zero-Tax AMM Output}}$$ If the retained ratio drops below your configured floor (for example, 0.75, representing a combined buy + sell tax above 25%), or if Tx4 reverts, the sniper aborts immediately and never sends the bundle to Flashbots or Titan.

You can inspect and run this exact simulation flow on a local fork by following our tutorial on How to Simulate a Flashbots Bundle With eth_callBundle and How to Test an MEV Bot on a Mainnet Fork with Anvil, or grab the open-source Solidity analyzer in our solidity-mev-bot-scam-detector GitHub repository.

Deadblock arithmetic: Turning anti-snipe rules into an edge

Not every anti snipe token is a scam. Legitimate project teams frequently deploy a 1-block or 2-block deadblock period where block-0 buyers get taxed 99% or blacklisted, specifically to stop naive mempool bots from buying 20% of the supply for $500.

When a token sniper detects a hardcoded 2-block deadblock (if (block.number <= launchBlock + 2)), naive bots either get trapped in block 0 or give up entirely. A smart searcher reads that exact constant from bytecode or storage and schedules their Flashbots bundle for launchBlock + 3—the first clean block where taxes drop to normal levels and blacklisting turns off.

We cover the exact bundle targeting parameters for post-deadblock entries in Block 0 Sniper Explained: Same-Block Token Launch Buys and coordinate live contract breakdowns inside our Crypto Sniping Group on Telegram (MEV DAO Premium Sniping Group).

Frequently asked questions

What is an anti snipe token on Ethereum?

An anti snipe token is an ERC-20 smart contract that includes defensive rules inside its transfer function—such as punishing 80%–99% buy taxes during the first 1 to 3 blocks, automatic address blacklisting in block 0, per-wallet holding caps (maxWallet), or cooldown timers—to prevent automated sniper bots from buying the majority of token supply at launch.

How does a token tax checker calculate real buy and sell fees?

A reliable token tax checker does not trust the public buyFee or sellFee variables printed on Etherscan. Instead, it simulates an actual buy swap and an immediate sell swap against the Uniswap pool inside an isolated EVM fork (eth_call or eth_callBundle) and compares the actual tokens and ETH received against the mathematical constant-product AMM formula.

Can a token pass a honeypot checker at launch and still trap snipers later?

Yes. If the contract owner has not renounced ownership—or if they hid a secondary privileged role such as taxWallet or an upgradable external hook—they can call a setter function in a later block to raise the sell tax to 99%, pause trading, or add profitable sniper wallets to a blacklist.

How is checking an Ethereum token different from a Solana rug pull checker?

While a solana rug pull checker primarily inspects SPL mint authority, freeze authority, and Raydium LP lock status because standard SPL tokens do not execute custom code on transfer, Ethereum ERC-20 tokens run arbitrary Turing-complete Solidity code on every transfer. That means Ethereum snipers must simulate bytecode execution rather than just checking metadata flags.

How do I avoid getting blacklisted when sniping block 0?

Before submitting a block-0 bundle, your bot must inspect the pending openTrading or addLiquidity transaction alongside the token bytecode to detect block.number comparisons. If the contract blacklists buyers in launchBlock or launchBlock + 1, configure your bundle target block for the first safe block after the deadblock window expires.

Want automated tax simulation, deadblock detection, and zero per-trade router fees? Start a 3-day free trial of the MEV DAO Sniper Bot & Sniping Group at mevdao.org/subscribe, or reach out to me on Telegram at @merunas.

← More on Sniper Bots All articles