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 pageA sniper bot is a filter that happens to be fast
First Block is about the part of automated entry that nobody demos: the rules a program applies between hearing about a token and agreeing to buy it. Speed is a solved engineering problem with a known cost. Deciding what deserves a buy is neither solved nor cheap, and it is where almost all of the money goes.
Every page here works from mechanisms you can verify against public Solana data. Nothing on this site reports a win rate, a return or a backtest, because a filter set that looked good over one week of launches is not evidence about the next one.
- 01Detect: something exists A program learns that a mint, a pool or a curve account appeared. What it learns depends entirely on which event it subscribed to, and every later decision inherits that limit.
- 02Screen: it clears the rules Authority fields, pool composition, distribution and metadata are read and compared against thresholds. Most candidates die here, and that is the filter working rather than failing.
- 03Size: it gets a number Position size is a function of pool depth and of how wrong the screen can be. A size chosen without reference to depth is a decision to accept whatever slippage the pool offers.
- 04Exit: it has a way out The exit rule is written before entry or it is not written at all. Once the position exists, the operator is negotiating with a market that already knows more than the filter did.
What a filter set is actually for
A screening rule is not a prediction. It is a statement about which mistakes you are willing to make, written in a form a program can evaluate in the time available. These four ideas run under every page on this site.
The two errors cost different amounts
Rejecting something that would have worked costs an opportunity. Accepting something that traps the position costs the position. Those are not symmetric, so a filter set tuned to catch everything good is tuned wrong.
RULE 01Design target: cheap rejections, expensive admissions
A rule must name what it misses
Every threshold has a failure mode, and a rule written without one is decoration. If you cannot say which real candidate your liquidity floor would have excluded, you do not yet know what the floor is doing.
RULE 02Write the rule, then write its false positive
On-chain fields prove less than they suggest
A revoked mint authority is a fact about one account field. It says nothing about who holds the supply, whether the pool tokens are locked, or whether a transfer hook can interfere later. Each claim needs its own check.
RULE 03One field, one claim, no bundling
Delivery is a separate problem
Whether the transaction lands is a question about priority fees, blockhash lifetime and retries, and it is answered elsewhere by people who specialise in it. This desk assumes the send path works and asks what you told it to buy.
RULE 04Out of scope here, deliberately
Start with these four
The shortest route through the material: how the decision is structured, how to assemble rules that fail cheaply, what the authority and liquidity fields really prove, and why an early fill is so often a bad one.
Building a filter set
How to assemble rules in an order that fails cheap, how to write a threshold you can defend, and how to test a set against history without fooling yourself.
FLT-01 Open the pageAuthority and liquidity filters
Mint and freeze authority, transfer hooks, pool ownership and lock claims: what each field proves, what it does not, and where the honeypot check actually sits.
FLT-02 Open the pageWhy most early entries lose
Adverse selection stated plainly: what it means to be filled by someone who knows more than you, and why speed does not rescue a bad filter set.
OUT-02 Open the pageThree ways in
Detection covers where the signal comes from. Filters covers what the program does with it. Terms is the shared vocabulary, because half the disagreements about screening are really disagreements about what a word means.
Detection Where the event comes from Which event a bot is actually subscribed to, how much of the token state exists at that instant, and why hearing earliest and hearing usefully are different goals. Filters What gets rejected Rule ordering, defensible thresholds, authority and liquidity gates, distribution reads, and the arithmetic of a set that rejects far more than it admits. Terms The vocabulary, defined once Mint authority, rent exemption, adverse selection, honeypot, effective float and the rest, defined in the sense this site uses rather than the sense a sales page uses. The desk Method and limits What gets checked before a page goes up, which claims this desk refuses to make, and how a correction changes a page that is already published.
Outcomes: what the entry was worth
A fill is not a result. These two pages deal with the part of the problem that begins once the position exists: the exit rule that should have been written first, the depth that has to be there to close into, and the plain statement that a fast entry into a bad candidate is still a bad entry.
What happens after the fill
Exit rules written before entry, the depth that has to exist for a position to be closeable, and why the sell side of a sniper is harder than the buy side.
OUT-01 Open the pageWhy most early entries lose
Adverse selection stated plainly: what it means to be filled by someone who knows more than you, and why speed does not rescue a bad filter set.
OUT-02 Open the pageEvery page on this site
Seven pages, each one a decision with a stated cost. Read in order they build; read alone they still stand up.
- DEC-01How Solana sniper bots work
- DEC-02Detecting a new token
- FLT-01Building a filter set
- FLT-02Authority and liquidity filters
- FLT-03Distribution and holder filters
- OUT-01What happens after the fill
- OUT-02Why most early entries lose
When the plumbing stops being the interesting part
Building detection, screening, sizing and exit logic yourself is worth it when the decision layer is the thing you want to own. Plenty of operators do not want to own it: they want flow through a pool on a schedule, with the wallet handling, routing and reporting already built.
That is a different product with different questions attached, and the useful ones are about reporting rather than speed. Can it hand back signatures and slots? Does it separate what it attempted from what it landed? A console that answers those can be checked against chain data; one that answers with a single headline number cannot be checked at all.
How this desk works
Narrow scope, stated limits, no numbers we cannot source. The longer version, including what happens when a page turns out to be wrong, is on the page about this desk.
Mechanism before advice
A page starts from something you can read on chain or in public documentation, and reaches a recommendation only after the mechanism is on the page. If a rule cannot be traced back to a field or an account, it does not get published as a rule.
Thresholds are examples, never settings
Numbers appear here as worked arithmetic with inputs you can change, or as protocol constants, or not at all. No page tells you to use a particular liquidity floor, because the correct floor depends on a position size only you know.
No results, ever
This desk publishes no win rates, no profit figures, no backtests and no case studies. Screening advice built on those is the most common way to be confidently wrong, and refusing to supply them is the one editorial rule with no exceptions.