A "sniper bot" on Solana is, at its core, a transaction submission system optimised for one thing: being among the first to buy when a new token launches or a new pool opens. People mostly hear about sniper bots in the context of pump.fun, but the category is broader — it covers anything that watches for an on-chain event and reacts within a slot or two.
This piece walks through what sniper bots actually do, what makes one profitable versus unprofitable, and what infrastructure decisions decide which side of that line you end up on.
What Sniper Bots Actually Do
Three components, in order of execution:
- Detection — watching the chain for the trigger event. This could be a new pool creation on Raydium, a new token launch on pump.fun, a liquidity addition on a tracked pool, or any other on-chain signal you've decided is interesting.
- Decision — deciding whether to act. Do you actually want to buy this token? At what amount? With what slippage tolerance?
- Submission — sending the buy transaction with timing that puts you ahead of other bots.
The first component is computationally interesting but architecturally well-understood — you stream account changes, subscribe to program logs, watch specific accounts for state changes. The second is where the trading judgment lives. The third is where most bots quietly fail.
Why Latency Decides Profitability
When a new pool opens, the first few seconds are the most profitable buying window. The price hasn't been set by market forces yet; it's whatever the pool creator initialised it at. Buying in the first slot or two means you're getting the lowest price; buying ten slots later means market makers and other snipers have already moved the price.
If you buy in slot N+1 instead of slot N, your entry price is meaningfully worse. If you buy in slot N+10, you're often the exit liquidity for everyone who got in earlier. The economic difference between "fast enough" and "not fast enough" is huge — often the difference between profit and loss.
This puts extreme requirements on the submission stack. You need:
- Detection latency measured in milliseconds, not seconds
- Path computation that doesn't bottleneck (don't allocate, don't make round-trips)
- Pre-built transactions ready to sign and submit the moment the trigger fires
- End-to-end submission latency that consistently puts you in the next slot, not five slots later
- SWQoS routing so that during congestion (which is exactly when these events happen) your transaction still lands
A sniper bot running on a general-purpose RPC can detect the opportunity but routinely lose the race to bots running on optimised infrastructure.
The On-Chain Detection Methods
Different events require different detection approaches:
Pump.fun new tokens. Watch the pump.fun program for token creation transactions. Filter on the right log line, parse out the token mint, you have a signal. Works because pump.fun emits structured events; the latency is a function of how fast your stream provider tells you about the new transaction.
Raydium new pools. Watch the Raydium AMM v4 program for pool initialisation. New pool creation has a specific instruction signature; subscribe to it.
Liquidity additions on watched pools. Subscribe to the pool's accounts; when reserves change in a way that suggests a deposit, fire.
Specific wallet activity. Smart-money tracking — watching known profitable wallets and copying their trades. This is technically simpler but the trade quality depends entirely on whose wallet you're tracking.
Pump.fun graduation events. When a token "graduates" from pump.fun's bonding curve to PumpSwap (pump.fun's own AMM), there's often a brief window where the price hasn't settled. Bots watch for graduation events specifically.
The common thread: you need a streaming source of on-chain data and you need it to be fast. RPC polling is too slow; you need RPC streaming subscriptions or some equivalent. You need this in addition to a fast submission RPC.
The Submission Stack
This is where most sniper bots either work or don't.
The naive approach: detect the event, build the transaction, sign it, send it via any RPC. Time elapsed: 200-500ms in the optimistic case, much worse during congestion. Result: you arrive 5-20 slots late and the price has already moved.
The optimised approach:
- Pre-built transaction templates. When the event fires, you only need to fill in the mint address and submit. Building the transaction from scratch each time costs you tens to hundreds of milliseconds.
- Pre-funded ATAs. If you have to create the associated token account at submission time, that's an extra instruction. Pre-create them or include creation in the buy with proper CU budget.
- Submission via an RPC built for this. General-purpose RPCs add latency in the hot path. RPCs built for transaction sending route to the producing validator with less overhead.
- Anti-MEV routing. Sniper transactions are perfect sandwich targets — large size, predictable direction. If your transaction is visible before it lands, you're getting sandwiched.
- SWQoS prioritisation. During the seconds of a hot launch, congestion is high. Without SWQoS-aware delivery, your transaction is competing with everything else for inclusion.
A bot with a fast detection layer but a slow submission stack is a bot that detects opportunities and watches other people capture them.
Common Failure Modes
Things that kill sniper bot P&L, in rough order of frequency:
Submission too slow. Detected the opportunity, lost the race. The most common failure mode by far.
Sandwich. Your buy was front-run by a bot that saw it in the public observation surface; you bought at an inflated price; they back-ran. Common on profitable launches.
No-fill. Slippage tolerance was too tight; the transaction succeeded technically but bought zero tokens. Or it failed entirely on slippage.
Bought a rug. The "opportunity" was a token designed to be rugged on purchase. No technical fix; only protection is filtering the detection criteria.
Compute unit failure. Especially for transactions that include account creation plus swap; under-budgeted CU means partial execution.
Blockhash expired. Long retry chains expire silently. Don't retry past two attempts; submit fresh.
Wallet drained by approval drainer. Off-topic, but: don't use your main wallet for sniper operations. Hot wallet only.
What Makes a Good Sniper Bot
After all the above, the actual answer is unsexy:
- A streaming source for detection that's fast and reliable
- Trading logic that filters out obvious traps
- A submission stack that puts you in slot N or N+1 consistently
- Per-signature telemetry so you can debug what happened
- An RPC that handles the workload during congestion, not just during quiet periods
- Tip strategy that varies with expected profit, not fixed at maximum
Most of this is operational discipline rather than clever algorithms. The bots that win are the ones with clean architecture and good infrastructure, not the ones with the cleverest detection logic.
What to Do If You're Building One
A practical sequence:
- Pick one trigger type. Don't try to handle pump.fun new tokens, new pool creation (PumpSwap / Raydium / Orca), graduation events, and smart-money tracking all at once. Master one first.
- Get detection working first. Make sure your bot reliably sees the events with low latency. If detection is broken, nothing else matters.
- Build the submission stack on day one. Pre-built transactions, pre-funded ATAs, optimised CU budget, RPC chosen for transaction sending.
- Test on small position sizes. The first version of any sniper bot is going to lose money in unexpected ways. Find them on small capital.
- Add filters incrementally. Reject tokens with bad creator wallets, reject pools with broken authorities, reject anything that looks rugged-on-arrival.
- Measure cost per attempt. Total fees + tips + slippage + sandwich tax, divided by the number of attempts. This is the real number.
Try BoltTx for Sniper Workloads
BoltTx is built for transaction-sending workloads where the difference between slot N and slot N+5 is the difference between profitable and unprofitable. Specifically relevant for sniper bots:
- Sub-second confirmation as a design floor with consistent tail behaviour
- Native Anti-MEV routing — your buys aren't visible to sandwich bots before they land
- SWQoS-aware delivery so transactions land during the exact congestion windows where launches happen
- Per-signature telemetry to debug specific failed attempts
- Tip-based pricing — pay only on landed transactions
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Free tier signup — enough to evaluate whether the submission profile fits your workload. Run a week of real attempts and compare landing rate against your current setup.
FAQ
What's the minimum capital for a sniper bot? Mechanically a few hundred dollars works for testing. Practically, the position sizes that survive fees and slippage on memecoin pairs are usually $500-5000 per attempt minimum.
How important is the RPC for a sniper bot? Decisive. The RPC determines whether you land in slot N or slot N+5. That gap is the gap between profit and loss for most sniper strategies.
What's the difference between a sniper bot and an arbitrage bot? Sniper bots react to discrete events (new tokens, new pools). Arbitrage bots react to continuous price divergences across markets. Different detection patterns, similar submission stacks.
Will most sniper bots be profitable? No. The category is heavily competitive and most attempts lose money. Profitable operators have either better detection (smart-money tracking with good wallets), better infrastructure, or both.
Can I run a sniper bot from my laptop? For testing yes, for production no. Network latency from a residential connection to Solana validators is too variable. Production sniper bots run on cloud infrastructure with low-latency networking.