How Solana sniper bots work
The four decisions a sniper makes in the first seconds, why the filter stage is the only one an operator controls fully, and where each decision can go wrong.
DEC-01 Open the pageDetection: Where the Signal Comes From
Detection is the first constraint and the most quietly decisive one. A program cannot filter on information that did not exist at the moment it heard about the token, and it cannot hear about the token at all unless something it subscribed to fired. Every screening rule written downstream is really a rule about the state visible from one particular vantage point.
The two pages in this section deal with that vantage point: how the whole decision is structured, and what the realistic event sources are. Neither of them is about how quickly you can sign afterwards.
- 01 The subscription A bot sees only what it listens for: a program log, an account write, a curve creation, a pool initialisation, or a third-party feed built on one of those.
- 02 The arrival gap Between the event firing and your process reading it there is a gap that includes network transport, deserialisation and any queueing your own code adds.
- 03 The state problem At the instant of the earliest event, much of what you want to screen on does not exist yet. Holders, pool balances and metadata may all arrive later.
- 04 The completeness trade Waiting for state to fill in makes every rule better and every entry later. That trade is the real decision, and it is usually made by accident.
- 05 The duplicate problem One launch produces several events across several programs. A detector without identity handling will act on the same token more than once.
- 06 The inherited ceiling No filter can be more informed than its trigger. If the source cannot show pool composition, no threshold written about pool composition can be enforced.
2 pages in this section
How a new token becomes visible to a program at all: which event a bot is actually subscribed to, how much of the token state exists at that moment, and how the source of the signal limits every decision made after it.
Detecting a new token
The event sources a bot can subscribe to, what each one knows at the moment it fires, and the trade between hearing early and hearing something complete.
DEC-02 Open the pageWhat this section will not tell you
It will not tell you which RPC provider is fastest, because that is a commercial claim that changes weekly and cannot be verified from outside. It will not publish a latency figure for any detection path, because latency belongs to a specific endpoint, region and moment. And it will not treat being first as an objective in itself, since being first is only valuable if the thing you arrived at was worth arriving at.
- Owned here
- Which event fired, what it contained, and what the program could legitimately decide from it
- Owned elsewhere
- Priority fees, blockhash expiry, retry logic and landing rate, which are send-path engineering and a separate discipline
- Never published
- Latency measurements, provider rankings, or any claim that one detection route is generally faster than another
- Always stated
- The state a source does not have, so a rule that depends on missing state can be recognised as unenforceable
Filters What gets rejected Rule design as an engineering problem: authority and liquidity gates, distribution reads, thresholds that can be justified, and the arithmetic of a filter set that rejects far more than it admits. Outcomes What the entry was worth The part of the problem that starts once the fill exists: exit rules written before entry, the depth on the other side of the position, and the reason a fast entry into a bad candidate is still a bad entry. Terms The vocabulary, defined once Every term this site leans on, defined in the sense it is used here rather than the sense a marketing page uses, so a rule written on one page reads the same way on another.