MEVDAO

Anti-Snipe Token Launches: Taxes, Blacklists and Trading Delays

By Merunas Grincalaitis · · 6 min read · 0 views

Every token launch is a fight between two groups. The developers want a fair-looking chart and holders who stick around. The snipers want to be first in, sometimes in the same block the liquidity goes live. So developers add anti-snipe rules to their contracts, and snipers adapt to them. Then developers add new rules.

I build sniper bots, so I'm on one side of this. But I read a lot of launch contracts, and honestly the best thing you can do on either side is understand the mechanics properly. A sniper who doesn't read the contract gets taxed into dust. A developer who copies anti-snipe code from a random token often ends up with something that looks exactly like a honeypot.

Here's every common mechanism I run into, what it does, and how a sniper handles it.

1. The trading switch

The most basic one. The token has a flag, usually tradingEnabled or tradingOpen, and transfers to or from the pair revert until the owner calls something like enableTrading() or openTrading().

Why devs use it: it separates adding liquidity from opening trading. Without it, the add-liquidity transaction itself is the signal, and bots buy in the same block.

What it means for snipers: you're no longer watching for addLiquidityETH (function selector 0xf305d719 on the Uniswap V2 router). You're watching for the owner's enable call. That's why the MEVDAO Sniper Bot lets you set the function signature to listen for, instead of assuming it's always the liquidity add. The goal is the same either way: land your buy right after the enable transaction, in the same block. I explained how that works with bundles in how Ethereum sniper bots work.

The catch is that some devs open trading through a private transaction, which means you never see it in the mempool. Then the race moves to the block right after.

2. Launch blacklists ("dead blocks")

The contract records the block number when trading opens. Anyone who buys within the first N blocks gets added to a blacklist, or gets a 99% tax, or can't sell.

if (block.number <= launchBlock + deadBlocks && from == pair) {
    isBot[to] = true;
}

What it means for snipers: this is the dangerous one, because it's indistinguishable from a honeypot if you don't read the code. You buy at block zero and your tokens are frozen. Bots handle it by reading the contract before launch, finding the deadBlocks value (or whatever they called it), and delaying the buy until the window closes. If the value is settable by the owner after launch, I personally skip the token.

If you want the full list of ways a token can stop you from selling, I wrote about it in honeypot tokens: how to spot one before you buy.

3. Launch taxes

High buy and sell taxes at launch, like 20% or 30%, that drop over the first minutes or blocks, often down to a few percent. Some contracts lower them automatically based on block number or number of buys. Others need the owner to call setFees.

Why devs use it: it makes sniping expensive instead of impossible, and the tax collected funds marketing or liquidity.

What it means for snipers: it's just math. If the buy tax is 25%, you only receive 75% of the tokens, so the price has to go up 33% just to break even on the buy tax. Add the sell tax and it's more. Good bots read the current tax on-chain at the moment they decide, simulate the buy, and compare what they'd actually receive to what they'd get a few blocks later.

The automatic, block-based decay is much nicer for everyone. When the owner has to lower the tax manually, you're trusting them to actually do it.

4. Max transaction and max wallet

maxTransactionAmount caps the size of a single buy. maxWallet caps how much one address can hold. Typical values at launch are 1% or 2% of supply, raised or removed later.

What it means for snipers: you can't put in one huge buy. Bots respond by sizing the buy exactly to the limit, and some use several wallets, which is why many contracts combine this with other rules. A buy that's over the limit just reverts, so your bot has to read the current value and calculate the amount out with the tax included, or the whole bundle fails.

5. Cooldowns and one-buy-per-block rules

The contract stores the last block (or timestamp) each address traded, and rejects another trade until some time has passed. Some versions limit it to one buy per block for the whole token, or per tx.origin.

require(_lastTransferBlock[tx.origin] < block.number, "one per block");

What it means for snipers: it stops the trick where one transaction buys many times through a contract. It doesn't stop a bundle with several separate wallets.

6. Contract and gas checks

Some anti-bot code tries to block smart contracts from buying, usually with tx.origin == msg.sender or an extcodesize check. Some also reject transactions with a gas price above a limit, to stop priority-fee wars.

These have been weak for a long time, and now EIP-7702 makes them weaker. The spec says explicitly that tx.origin == msg.sender no longer guarantees the caller is a plain EOA, because a delegated EOA can run code. And gas price caps don't do much against Flashbots bundles, where the payment to the builder can be a direct ETH transfer instead of a high gas price.

If you're a developer, don't rely on these.

7. Uniswap v4 hooks

This is the new one, and the most interesting. In Uniswap v4, each pool can have a hook contract that runs at specific points, including beforeSwap and afterSwap. The hook is set when the pool is initialized and can't be changed afterwards. Which functions it implements is even encoded in the bits of the hook's address.

That means launch protection can live in the pool instead of the token. A beforeSwap hook can enforce a trading start time, limit swap size for the first blocks, apply a dynamic fee that starts high and decays, or run an auction for the first block. The token itself can be a completely plain ERC-20.

What it means for snipers: you have to read the hook contract instead of (or as well as) the token. The good news is that because the hook is fixed at pool creation, its rules are more predictable than a token with an owner who can change fees whenever they want. The bad news is that the logic can be anything, so each launch with a custom hook needs its own simulation.

How I approach a launch as a sniper

This is the order I go in:

  1. Find the gate. Is it the liquidity add, an enable call, a v4 pool initialization, or a time? That's what the bot listens for.
  2. Read the restrictions. Dead blocks, taxes and how they change, max tx, max wallet, cooldowns.
  3. Check what the owner can change after launch. Uncapped fee setters and editable blacklists mean I either skip it or go small.
  4. Simulate the exact bundle. Their enable transaction, my buy, and a test sell. If the sell fails in simulation, I don't send it.
  5. Size to the rules. Buy under max tx, account for the tax, and decide in advance when to sell.

Advice if you're the developer

I'll be direct: snipers will buy your launch. You can't stop it completely, so aim for a launch that's fair and doesn't look like a scam.

  • Make everything time-limited and automatic. Taxes that decay by block number, limits that switch off on their own. Owner-controlled switches scare off real buyers too.
  • Hard-cap your fees in the code. require(newFee <= 5). People check this.
  • Don't blacklist forever. If you penalise early buyers, do it with a temporary tax that expires, not a permanent freeze. Permanent freezes are how honeypots work, and scanners will flag you.
  • Verify the contract and renounce what you can. Unverified code at launch kills your volume.
  • Consider a v4 hook if you want real launch logic. It's transparent and immutable, which is what buyers want to see.

Where the real edge is

Most anti-snipe code is copied from older tokens, so the same patterns show up again and again. The edge isn't in some magic trick. It's in reading every contract fast, simulating correctly, and not getting greedy on tokens where the owner keeps too much power.

That's what we do every day in the MEVDAO Premium Sniping Group: we snipe proven tokens together with the Sniper Bot, which uses Flashbots bundles and still snipes if Flashbots is unavailable. It's all in one subscription with a 3-day free trial.

And if you're launching a token and want a custom launch contract or hook, message me on Telegram.

← All articles