How to Build a Solana Sniper Bot: Detection, Filters and Execution

In a nutshell, a Solana sniper bot is a type of program that spots a new liquidity pool or a token listing as soon as it appears on the blockchain and then places a buy order before the wider market has had a chance to react. Since the entire approach is a race that takes place in milliseconds, the bot essentially consists of three parts: a detection layer which picks up the event first, a decision layer which filters out potential scams, and an execution layer which carries out the transaction while the price is still exactly as it was when it was observed. This article examines each of these layers, explains where the time is actually spent, and outlines the failure modes that distinguish bots that function in real conditions from those that only work on the testnet.

Key Takeaways

• The speed of detection is what gives you the edge. A bot which learns about a pool from a finalised block is already hundreds of milliseconds slower than one that reads shreds or uses a low-latency gRPC stream.
• The reason for most losses isn't that the bot is slow; it's that it buys the wrong thing. Honeypot checks, authority checks, and liquidity sanity checks should be included in the hot path and not left until a later review.
• Execution requires a prioritised write path; if a simple sendTransaction is carried out at the time of a launch, it goes out over an unstaked connection and usually loses to snipers who are on staked ones.
• Build around the leader schedule, since the region from which your transaction leaves is determined by where the current leader is sitting.

How does a Solana sniper bot actually work?

A sniper bot monitors on-chain events, detects the establishment of a tradeable market, decides within microseconds whether or not to take action, and then carries out a swap. On Solana the events that are worth keeping an eye on are the instructions which create or initialise a pool on a DEX program (Raydium, Orca, Meteora and the launchpad programs that migrate into them) and the first liquidity deposit that makes the pool tradeable.

The pipeline has four stages, and each stage has a latency budget:

All the parts that come after 'observe' take place within your own process and can therefore be made faster through normal engineering techniques. Since the 'observe' and 'execute' stages rely on infrastructure, the remainder of this guide focuses most of its attention on that area.

Detection: where the race is decided

There are four methods of working out that a pool has been made, and these methods are not the same.

1. Polling an RPC. Continuously calling either getProgramAccounts or getSignaturesForAddress. This is simple but terribly slow: you only find out about the pool a few seconds after it has been created, and you end up hitting your rate limit as a result. It can be of use only for research and never for actual live sniping.

2. WebSocket subscriptions. By using logsSubscribe or programSubscribe on the DEX program, you will receive a push notification whenever a matching transaction is processed. This represents the basic requirement for a functioning bot, but the notifications are sent after the RPC node has processed the block, which is after the leader has produced it and after it has been propagated.

3. Geyser gRPC (Yellowstone). The Geyser plugin sends out a gRPC stream which provides account and transaction updates as the node is processing them, with filtering carried out on the server so that you only get the data for which you have subscribed. It has lower latency than WebSockets and is much more selective. This is the minimum requirement for most serious bots.

4. Shreds. When a leader is forming a block, it sends out fragments called shreds. If you look at these fragments directly or use a service which reconstructs the transactions from them, you will be able to see the pool creation as the block is still being put together, prior to any RPC node having processed it. This represents the earliest possible point at which observation can take place, and it is what distinguishes consistently early bots from the rest.

In reality the stack is as follows: it includes a Shredstream-fed stream for the hot path, a gRPC stream as the source of structured data, and WebSockets as the fallback option. Because OrbitFlare's Jetstream gRPC provides the stream derived from the shreds with the transaction already decoded, your bot receives a typed event instead of raw packets. Details about the mechanics can be found in what is Shredstream.

Decoding the event correctly

When an event occurs, the bot requires the pool address, both token mints, the initial liquidity amounts, and the accounts that it will need in order to carry out a swap. Two rules prevent this stage from becoming a bottleneck.

Parse in memory, never fetch. Each time you make a getAccountInfo call after the event it involves a round trip that you can't afford. Decode the instruction data and the accounts list from the transaction itself and keep the DEX program layouts in your binary, along with a warm cache of the token program, the associated token program and the common vault layouts.

Precompute what you can. The address of your wallet's associated token account for a particular mint is deterministic. The swap instruction for a given DEX is a template as well. Before the event takes place, prepare as much of the transaction as possible and then insert the mint and pool addresses when they become available.

A good decode stage runs in less than a millisecond. If yours is slower, profile it before changing anything.

Deciding: the filters that save you money

It's speed that gets you into the trade, while filters keep you out of the trades which were meant to take your money. The typical traps found on Solana launches, and the safeguards that detect them:

Each of these has to be based on data that you already possess or that you can obtain from a single cached source. A filter which requires three RPC calls is one that causes you to be delayed. Since many bots have a background indexer that continuously monitors token metadata and holder distributions, the hot path performs a hash lookup instead of making a network request.

This also applies to position sizing. You should decide the maximum amount of SOL per trade, the maximum slippage, and the maximum share of the pool's liquidity that you are willing to take up before the event takes place. These should be set as constants and read by the hot path, not made into calls.

Executing: landing the buy

You first observed the pool and concluded that it was safe; at this stage the transaction has to get to the current leader before all the others'. This is entirely an infrastructure issue and it has four parts.

Priority fee. Set the compute unit price high enough to win ordering within the block. Since the fee market on Solana is specific to the accounts you interact with, the relevant price is the one that other snipers are paying on this pool, not the overall median fee for the network. Estimating the fee dynamically, based on recent transactions that have involved the same DEX program, is better than using a fixed fee.

Write path. When a launch is taking place the public TPU gets overwhelmed by other snipers and as a result the unstaked connections are dropped first. In this case you should use either a Jito bundle (one that includes a tip reflecting the expected edge) or a stake-weighted QoS lane. We look at all the options in how to land transactions on Solana. A staked lane is generally the better default choice for single-leg sniping since the bundle auction involves an extra step.

Region. In the current slot the leader is a particular validator located in a specific datacentre. When a transaction goes from Frankfurt to a leader based in Ashburn, it pays for the Atlantic twice: once when your data arrives and again when the block returns. Serious bots operate in more than one region and submit their transactions from the one closest to the scheduled leader. The region pages show where OrbitFlare has a presence.

Retry strategy. Send the transaction to both the current leader and the next one, then stop. Blindly resending it for ten seconds will burn through the rate limit and often results in a worse fill in a later slot that you didn't want.

A reference architecture

Putting the stages together, a production sniper looks like this:

1. Streams: a gRPC subscription powered by Shredstream and filtered to include only the DEX programs that you trade, together with a gRPC subscription from Yellowstone for account state, and also a WebSocket fallback.
2. Indexer: a background process which keeps the token metadata, authorities, and holder distributions in memory, fed by the same streams.
3. Hot path: there is one single-threaded event loop in each region which carries out the decoding, filtering, sizing, building, signing, and submission. If your language permits it, there should be no allocations on the hot path; Rust is the most commonly used language and Go can be used as well.
4. Submission: in each region there is a staked write path together with leader schedule tracking so that the appropriate region can be selected for each event.
5. Post-trade: this is a distinct process which keeps an eye on the position, handles the exits, and records the result for later analysis.

The fundamental rule concerning design is that nothing on the hot path should wait for a network request; all the data it needs must have been included with the event or should have been cached previously.

Measuring whether your bot is actually fast

Statements about latency without actual measurement are just guesses. To obtain accurate figures, record three timestamps for each event: the time at which the event was observed, the time when the transaction was submitted, and the slot in which it landed. Then track:

• Observe-to-submit time. This is your own code. You should achieve sub-millisecond performance with a well-built bot.
• Submit-to-landing slot delta. The difference between the slot you submitted in and the slot the transaction actually landed in. This is your infrastructure. A zero indicates that you landed in the slot you had aimed for.
• Landing rate during launches. The proportion of submitted transactions that landed at all within the 60 seconds surrounding a launch.
• Fill quality. The executed price compared to the price at the time of observation. This figure shows whether being fast actually translated into being early.

If you look at the results for different regions and for different write paths, you will usually find that one region is early for a subset of the leaders but late for the others; this is the kind of data that you need in order to justify a multi-region deployment.

Common mistakes

• Using a public or shared RPC for the hot path. It is unreliable precisely when it is needed due to rate limits and the shared capacity. A dedicated node or a plan with reserved capacity should be the standard choice.
• Filtering after submitting. Bots end up with frozen tokens because they buy first and then check.
• One region. The leader schedule is global and a single-region bot is late for most of it.
• Ignoring Token-2022 extensions. Transfer hooks and fees are valid features and can also be very effective as traps. Skip any tokens with extensions that you do not explicitly understand.
• Fixed priority fees. The fee applicable at the time of a launch can be many times higher than the quiet-hour fee. This should be estimated dynamically.
• No exit plan. Paper gains turn into real losses when you get in quickly without having a strategy for getting out.

Conclusion

A Solana sniper bot is essentially a race based on latency that also involves a safety issue; in order to win the observation phase you need to use either shred-level or gRPC streaming, keep the decode and decision phases in memory, and then carry out the transaction via a staked, region-aware write path. You should measure the time taken from observation to submission, from submission to landing, and the fill quality, and let these figures guide all of your infrastructure decisions.

If you wish to make the transition from a working bot to an early one, the Jetstream gRPC service provides you with the event stream derived from shreds, and the RPC plans include the staked write path as well, and both are available in the regions where the leaders are.

Resources

1. Stake-weighted QoS guide (Solana)
2. Jito bundle documentation
3. What is Shredstream?
4. Shredstream decode example (GitHub)
5. Jetstream V2 docs
6. OrbitFlare benchmarks