Solana moves fast. A new token launches, liquidity is added to a pool, and within the first minute the price can move 5x, 10x, or more. The traders who profited entered in the first 10–30 seconds — a window no human operating a keyboard can reliably access. That is the problem a Solana sniper bot solves.

In the Solana context, a sniper bot refers specifically to software that monitors the blockchain in real time for new liquidity pool creation events and executes a buy transaction immediately upon detection — before the token has had time to establish any price history at all. If you want a practical walkthrough of using one for the first time, our beginner's guide to sniping Solana tokens covers the full setup process step by step.

The Core Problem: Why Manual Trading Is Too Slow

Consider what happens when a token launches on Raydium. A developer calls the initialize2 instruction on the Raydium AMM program. That transaction lands in a block. The token now has a trading pair. From that moment:

  • Block time on Solana is approximately 400 milliseconds.
  • A human seeing the token on a screener, copying the address, opening a swap interface, approving a wallet transaction, and confirming — minimum 30–60 seconds under ideal conditions.
  • In that same 30–60 seconds, dozens or hundreds of automated buyers have already entered. The price has moved.

You are not competing against other humans in those early seconds. You are competing against other bots. In a competition defined purely by speed, manual interaction cannot win. Automated Solana sniping tools are how that advantage is accessed by retail traders who would otherwise have no path into a launch at its earliest stage.

What a Sniper Bot Actually Does

At a high level, a Solana sniper bot does four things in rapid sequence:

  1. Listens to the Solana network via a persistent WebSocket connection to an RPC node, watching for specific on-chain events.
  2. Detects a new token launch or liquidity pool creation that matches its configured criteria.
  3. Evaluates the token against safety filters and parameter thresholds.
  4. Executes a signed buy transaction within the same block or the immediately following block if all criteria pass.

The whole sequence — detection to transaction broadcast — runs in under 300 milliseconds in optimal conditions. This reflects the technical reality of what is possible when a bot is running close to a high-performance RPC node with optimised transaction construction.

RPC Connections and Why They Determine Your Speed

An RPC (Remote Procedure Call) node is the interface between software and the Solana blockchain. Every transaction you send and every piece of data you read from the chain goes through an RPC endpoint.

HTTP RPC

Standard request-response model — useful for reading data but has too much overhead for real-time event detection.

WebSocket (wss)

A persistent two-way connection. Rather than polling for new data, the RPC node pushes events to your bot the instant they appear on-chain. WebSocket subscription is what makes real-time token detection possible. The bot subscribes to program account changes on the Raydium AMM program ID (or Pump.fun, Bonk.fun, etc.) and receives a notification every time a matching account is created or modified.

The quality of the RPC node matters enormously. Public free-tier nodes are shared across thousands of users — slower, rate-limited, and frequently missing events under high load. A high-performance dedicated RPC significantly reduces detection latency.

How New Tokens Are Detected On-Chain

Different DEXes require different detection strategies.

Raydium AMM

The bot subscribes to program log notifications for the Raydium V4 AMM program. When a new pool is initialised, the program emits a specific log pattern. The bot parses the log to extract the base and quote token mint addresses, pool ID, and initial liquidity amounts — data used to construct the buy instruction.

Pump.fun and Bonk.fun

These launchpads use a bonding curve program. A new token is created when someone calls the create instruction on the launchpad program. The bot subscribes to new account creations under the bonding curve program and detects new token deployments in real time. The Pump.fun sniping strategy guide covers the bonding curve mechanics and how to optimise entry timing on this specific platform.

Why this matters: A bot that only monitors Raydium will miss Pump.fun launches entirely, and vice versa. Multi-DEX monitoring on the same WebSocket connection gives you full coverage without duplicating infrastructure.

Transaction Construction and Signing

Once a target token is detected and passes filters, the bot has milliseconds to construct a valid Solana transaction. The process:

  1. Fetching a recent blockhash. The bot keeps a cached recent blockhash refreshed every few seconds to avoid this fetch adding latency.
  2. Building the swap instruction. For Raydium, this targets the newly-created pool. For Pump.fun, it's a buy instruction on the bonding curve program.
  3. Setting compute units and priority fee. The bot attaches a priority fee instruction to increase the likelihood of inclusion in the next block.
  4. Signing the transaction. The private key signs the transaction locally using Ed25519 — the signing operation happens in milliseconds.
  5. Broadcasting. Sent to the RPC node with skipPreflight: true in most cases — skips pre-flight simulation to reduce latency.

The entire sequence from detection to broadcast typically completes in 150–350 milliseconds. Network latency between the bot and the RPC node accounts for most of the variance.

Priority Fees, Compute Units, and Getting Filled First

Solana transactions are processed by validators using a fee-priority queue. When multiple transactions compete to interact with the same pool — which is exactly what happens at a popular token launch — the validator processes higher-fee transactions first.

This means priority fees are a direct lever on your fill priority. The optimal fee depends on how competitive a particular launch is. For low-profile launches, minimal fees are sufficient. For highly anticipated launches where hundreds of bots compete, fees need to be meaningfully higher. We cover this in depth in our article on how Solana priority fees affect sniping speed.

Safety Checks Before Every Buy

Speed without safety is expensive. The 12-point safety analysis runs against every token before the buy instruction is constructed:

  • Mint authority check: An active mint authority lets the developer create unlimited new supply, diluting your position to near zero.
  • Freeze authority check: Active freeze authority means token holders can be prevented from selling — the classic honeypot mechanism on Solana.
  • Holder concentration: One or two wallets holding 40%+ of supply at launch means a single coordinated dump can destroy the price.
  • Deployer wallet history: Has this address launched tokens before? Were those tokens rugged? A history of failed launches is a strong red flag.
  • Honeypot simulation: The bot simulates a buy-and-sell sequence to check whether the sell would succeed. Some tokens allow buys but revert sells — this catches that pattern before real funds are deployed.
  • Buy/sell tax: Transfer taxes above 10% effectively trap you on every transaction in either direction.

For the full breakdown of all 12 signals, see our rug pull avoidance guide with its complete safety checklist.

Browser-Based vs. Server-Based Bots

Server-side bots

Run on a remote server operated by a third party. Your private key must be uploaded to or stored on that server — you are trusting the operator with the key that controls your funds. If the server is compromised or the operator disappears, your funds can be stolen.

Browser-based bots

Run entirely within your browser tab using JavaScript. Your private key is entered locally and stays in your browser session — never transmitted to any remote server. All transaction signing happens on your device.

Solana Sniper Bot is browser-based by deliberate architectural choice. For software that handles financial transaction signing, eliminating server-side key custody is the right call regardless of any latency implications. The execution speed difference between a well-positioned browser connection and a colocated server is measurable in tens of milliseconds — meaningful in the most competitive scenarios, but not the primary variable for most retail-scale sniping activity.