Raydium Sniper Bots: Catching New Liquidity Pools First

The window between a new Raydium pool being created on-chain and that pool appearing in any DEX aggregator or Telegram alpha group is measured in seconds — sometimes less. A well-engineered raydium sniper bot lives entirely inside that window. Missing it by even one block typically means paying a 20–40% markup on top of entry price as the retail wave follows.

How Pool Creation Actually Works on Raydium

Raydium AMM v4 initialises a new CPMM pool through an instruction called initialize2. When a project team or token launchpad calls this instruction, it atomically:

• Creates the pool account and sets initial reserve ratios
• Mints the initial LP tokens to the deployer
• Logs the new pool's base and quote mint addresses in the instruction data

Until that transaction confirms, the pool does not technically exist. The moment it does, anyone who submitted a buy transaction in the same block or the immediately following one can acquire tokens at or very close to the seeded price. Every millisecond of reaction time after that costs you price impact.

A naive approach — polling the Raydium API or watching Solscan — introduces hundreds of milliseconds of latency before you even begin building a transaction. At that point you are not a sniper; you are a late buyer.

Streaming the Mempool with Geyser

The correct approach is to subscribe to a Yellowstone gRPC Geyser stream from a geographically co-located RPC node. Geyser pushes account and transaction updates to your bot in real time — before a transaction is even included in a block — so you can detect the initialize2 instruction while it is still in the pending transaction pool.

The detection pipeline looks roughly like this:

1. Open a Geyser subscribeTransactions stream filtered to the Raydium AMM v4 program ID (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8).
2. Deserialise each incoming transaction and scan the instruction list for the discriminator that matches initialize2 (the first 8 bytes of the instruction data after Anchor's SHA-256 prefix).
3. Parse the accounts array to extract baseMint, quoteMint, and the new ammId.
4. Run a simulation against the current slot to estimate post-initialisation reserves and calculate an expected entry price.
5. If the token passes your anti-rug filters (LP lock status, mint authority revoked, initial liquidity threshold), fire your buy.

Steps 1–5 must complete — including the simulation round-trip — in under 150 ms if you want consistent same-block fills. In practice, the best setups hit 60–90 ms end-to-end using co-located validators.

Execution: Jito Bundles and Priority Fees

Once your buy transaction is built, raw submission to the standard mempool is not good enough. Competing bots are doing the same thing, and validator inclusion order matters. The two mechanisms that determine who gets in first are:

Priority fees. Solana's compute unit price system lets you bid for inclusion. Setting a high enough setComputeUnitPrice instruction raises your transaction's fee-per-CU, making it attractive for leaders to include first. The optimal fee is dynamic — you need to benchmark recent landed transactions at your target slot range rather than using a static constant.

Jito block engine. Jito allows you to submit atomic bundles of up to 5 transactions directly to a Jito-aware leader. Bundles can include a tip account transfer, which lets you out-bid competing snipers for top-of-block placement. Critically, bundles either land atomically or not at all, so you can safely pair your buy with a protection transaction without worrying about partial execution.

For pools with thin initial liquidity, slippage tolerance on the buy must be calibrated carefully. Too tight and your transaction reverts when someone else buys a millisecond ahead of you. Too wide and you eat every sandwich-bot on the network.

Simulation and Anti-Rug Filters

Speed without safety is how snipers get rugged. Before committing real capital, every candidate pool should pass at minimum:

• Mint authority check — if the deployer can still mint new tokens the supply is not fixed
• Freeze authority check — freeze authority on the token account is a kill-switch for your position
• LP lock verification — query on-chain LP token holders; if the team holds the LP tokens without a time-lock contract, they can drain the pool
• Simulation pass — simulate the buy against a forked state of the initialisation slot to verify the pool is actually tradeable before broadcasting

Our Solana sniper bot case study documents how these filters were implemented in production, including the exact on-chain account queries used to verify LP lock status without relying on third-party APIs that introduce latency.

If you need broader trading-bot services — from mempool sniping to multi-venue arbitrage — the underlying infrastructure is the same: low-latency RPC access, Geyser streaming, Jito integration, and robust simulation before any capital moves.

---

Building a raydium sniper bot that consistently wins the initialization race requires more than a fast internet connection — it demands co-located infrastructure, protocol-level instruction parsing, and hardened anti-rug logic running in sequence under 100 ms. If you want to deploy something production-ready without burning months on infrastructure, start a project with TierZero and we will scope the build from Geyser stream to first live trade.