Sniper bots and anti-snipe protection
IN SHORT
A sniper bot buys a token in the first instants it becomes tradable, taking cheap supply before anyone else can react and typically selling into the demand that follows. On chains with a public mempool it does this by front-running the transaction that opens trading.
A chain with no public mempool — like Robinhood Chain — removes front-running but not sniping. Nobody can get in front of your launch, but bots can still buy in the block after it. Real protection therefore comes from taking your own allocation atomically at launch, not from the chain alone.
How sniping actually works
Strip away the mystique and there are only two families of attack, distinguished by what the bot is watching.
Mempool front-running
On a chain with a public transaction queue, everything pending is visible before it executes. A bot watches for the transaction that will make a token tradable, then submits its own buy with higher priority fees so that it is ordered first. It buys at the opening price, your buy executes after it at a worse one, and it sells into whoever arrives next.
This is the attack that requires a public mempool. Without one, it is simply not available.
Next-block racing
The second family needs no mempool at all. The bot watches confirmed blocks — or, on an Arbitrum Orbit chain, the raw sequencer feed, which reports ordering slightly ahead of the public RPC — and fires a buy the instant it sees a new pool. It cannot get in front of your launch. It is trying to be the very next thing that happens.
This is why “our chain has no mempool, so you are safe” is an incomplete claim. The threat model changes shape; it does not disappear.
What actually helps
| Defence | Stops | Does not stop |
|---|---|---|
| No public mempool | Front-running — nobody sees the launch before it lands | Bots buying in the following block |
| Creator buy inside the launch call | Everything — the launch block is creator-only, so the buy is uncontested by construction | Anything after the launch block |
| One atomic multicall for all buys | Anything being inserted between your own buys | A separate buyer in the next block |
| Launchpad restriction window | Any single wallet taking a large share early | Many wallets each taking a small share |
| High launch gas / priority fees | Very little on an L2 — ordering is the sequencer’s, not an auction | Essentially everything |
The launch-block window
The strongest guarantee available on Robinhood Chain comes from the launchpad itself. Pons reserves the launch block for the creator: the buy included inside launchToken executes there, and no other buy can. A sniper is not outbid or outrun — it is refused by the contract.
The practical consequence is that taking your allocation inside the launch call is categorically safer than racing for it afterwards, however fast your infrastructure is. There is no race to win.
One detail that bites teams building against this: on an Orbit chain, block.number inside a contract is the L1 block estimate, which advances about every 12 seconds rather than at L2 speed. A restriction window of a handful of blocks is therefore a window of minutes, not milliseconds.
What does not help
- Anti-bot code in the token contract. Blacklists and transfer-delay tricks are read by every honeypot scanner on the market and will get your token flagged. They also rarely stop a competent bot.
- Launching “quietly” at an odd hour. Bots do not sleep, and they are not reading your announcements.
- Overpaying on gas. On a sequencer-ordered L2 you are not bidding for position in the way you would on Ethereum.
Frequently asked questions
What is a sniper bot?
A sniper bot is automated software that buys a token in the first moments it becomes tradable, aiming to acquire supply at the lowest price before ordinary buyers can react, and usually to sell into the demand that follows. Some watch the public mempool for the transaction that opens trading; others watch confirmed blocks and react as fast as the chain allows.
Does no public mempool mean no snipers?
No. Removing the public mempool removes front-running — nobody can see your launch transaction before it executes and jump ahead of it. Bots can still watch confirmed blocks and the sequencer feed and buy in the block immediately after your launch. It eliminates the race to be first, not the race to be second.
How do launchpad restriction windows work?
Many launchpads cap per-wallet and per-transaction buy sizes for a set number of blocks after launch, and reserve the launch block itself for the creator. This limits how much any single sniper can take early. On Arbitrum Orbit chains these windows are measured in L1 blocks, which advance roughly every 12 seconds, so they last much longer in wall-clock time than the block count suggests.
What is the best anti-snipe protection?
There is no single mechanism. The combination that holds up is: launch on a chain with no public mempool so you cannot be front-run, take your own allocation atomically in the launch block or in one batched transaction so nothing can be inserted between your buys, and rely on the launchpad restriction window to cap what anyone else can take immediately after.
Protect your own launch
BundleZeus takes your allocation atomically — inside the launch call, or as one router multicall across up to 250 wallets — so there is no gap for anyone to trade into. Simulate the whole thing free before you commit.