How Solana Sniper Bots Work, Decision by Decision

A Solana sniper bot makes four decisions: what it heard about, whether that thing clears its rules, how much to buy, and what it will do with the position afterwards. Only the second and fourth are within the operator's real control, and almost all of the variance between one bot and another lives there rather than in how quickly either of them signs a transaction.

The four decisions

It helps to separate the stages, because they fail differently and are fixed by different work. A program that is slow and a program that is buying the wrong things look identical from the outside: both produce a wallet full of positions that did not go anywhere. Only the internal split tells you which problem you have.

The middle two are where the money is. Detection sets a ceiling on how good the screening can be, since a rule cannot evaluate state that has not been written. Exit prices the mistakes the screen made. That leaves screening as the one stage where a careful operator can genuinely outperform a careless one on the same infrastructure.

Decision one: detect

Detection is a subscription. A program listens for something specific: logs emitted by a particular program, writes to a particular account, the creation of a bonding curve, the initialisation of a liquidity pool, or a third-party feed that is itself watching one of those. The important property is not how quickly the event arrives but how much the event contains.

An event that fires at the moment a mint account is created carries almost no useful screening material. There is a mint address, an authority configuration and a supply figure. There is no pool, so there are no reserves; there are usually no holders beyond the deployer; and metadata may not have been written yet. An event that fires when a pool is initialised carries more, because reserves exist by definition, but it arrives later and the candidate has been visible to other participants for the intervening period.

This is the first real trade in the system, and it is frequently made by accident. Choosing the earliest possible trigger is choosing to screen on less information. Choosing a later trigger is choosing to arrive after everyone using the earlier one. Neither is right in general; what is wrong is not knowing which one you picked. The Solana account model that makes this readable at all is documented in the official Solana developer documentation, and it is worth reading the account and program sections before designing any detection path.

Two secondary problems live here as well. The first is duplication: a single launch usually produces several events across several programs, and a detector without a notion of token identity will evaluate the same candidate two or three times. The second is the arrival gap, which includes network transport, deserialisation and any queueing your own process adds. A detector that logs the wall time of the event and the wall time of its own decision will usually find the second number less flattering than expected.

Decision two: screen

Screening is the only stage that is fully yours. Everything else is bounded by the network, the pool or the counterparty; the rule set is bounded by nothing except how carefully it was written. It is also the stage most often described in vague terms, because a specific rule invites the obvious question of what it misses.

A filter set is a rejection machine. On an active day it turns down nearly everything it sees, and its quality is decided by which rare candidate it admits and which kind of failure it accepts in exchange. The two errors are not symmetric. Rejecting something that would have worked costs an opportunity that you never see. Admitting something that traps the position costs the position, and you see that one every time.

Rules divide cleanly into three families, and mixing them into a single score destroys the information that makes them useful:

• Authority rules ask what the deployer can still do to the token: whether the mint authority can create more supply, whether a freeze authority can immobilise a holder's account, whether metadata is still mutable, whether the token program in use supports extensions that alter transfer behaviour.
• Liquidity rules ask what the market looks like: what is actually in the pool, whether the quote side is a real asset, who owns the pool tokens, and whether any lock claim can be verified rather than asserted.
• Distribution rules ask who holds the supply: how much sits in the largest accounts, how much is in the pool, and how much is genuinely circulating and able to arrive as sell pressure the moment price moves.

Each family answers a different question, and a candidate can pass two and fail the third in ways that matter enormously. A token with revoked authorities and a clean-looking holder chart can still have its entire float in wallets funded by the same source ten minutes earlier. A token with excellent distribution can still be paired against a quote asset that nobody wants.

Decision three: size

Size is where an abstract rule set meets a concrete pool, and it is the stage most likely to be handled by a constant in a configuration file. A fixed buy amount ignores the only variable that matters: how much depth is available to trade against.

The arithmetic is easy enough to do in a sentence. In a constant-product pool, the price impact of a buy is governed by the ratio of your input to the reserve on the side you are paying with. Ignoring fees, paying in an amount equal to five percent of the quote reserve moves the pool price by roughly ten percent against you, and the average price you receive is worse than the price you saw quoted. The same relationship works in reverse on the way out, and by then the reserve may be smaller.

Two consequences follow. First, a liquidity floor is not a safety threshold, it is a sizing constraint: the floor exists so that the size you intend to trade is small relative to the reserve. If the size changes, the floor changes with it or it stops meaning anything. Second, the round trip is the unit of account. An entry that looks cheap in isolation is not cheap if the same position has to be unwound into the same pool.

Decision four: exit

The exit rule is written before entry or it is not written at all. This sounds like a slogan and is actually a statement about information. Before entry, the reasoning is clean: you have a thesis, a size, and an idea of what would make the thesis wrong. After entry, you have an open position, a moving price, and a strong incentive to reinterpret the evidence.

Exit rules come in a small number of shapes, and the useful ones are conditional on something observable rather than on a feeling. A time-based rule closes the position after a fixed interval regardless of price, on the theory that the information advantage a filter set provides decays quickly. A depth-based rule closes when the reserve on the exit side falls below the level required to close the whole size at acceptable impact. A structural rule closes when something that was true at entry stops being true, such as pool ownership changing hands.

What all of them have in common is that they can be evaluated by a program without a judgement call. A rule that requires the operator to look at a chart is not an exit rule, it is an intention. The sell side is also harder than the buy side in a mechanical sense: buying into a thin pool is a choice you control, while selling out of it requires someone on the other side, and the other side is thinnest exactly when you most want it.

Where each decision goes wrong

Failures are much easier to diagnose when the stage is identified first. The same symptom, a portfolio full of positions that went nowhere, has four completely different causes with four different fixes.

The row worth staring at is the second screening row. Copied thresholds are the most common defect in the whole system, because they look like knowledge. A liquidity floor taken from a forum post encodes somebody else's position size, somebody else's tolerance and somebody else's venue. Carried across, it is a number with no argument behind it.

A worked pass through one candidate

Here is the sequence a well-ordered program runs, with the cost of each step noted. The ordering principle is simple: anything that can reject the candidate without a network call happens first, because the common case is rejection and rejections should be free.

1. Receive the event and establish identity. Extract the mint address and check it against a short-lived set of recently seen mints. If it is already there, stop. This costs nothing and removes the duplicate class entirely.
2. Apply purely local rules. Anything decidable from the event payload alone runs here: program identity, obviously malformed names, addresses on a local blocklist. No round trips, no cost.
3. Fetch the mint account. One call gives you supply, decimals and the authority configuration. This is the cheapest network step and it rejects a large share of candidates on authority grounds alone.
4. Fetch the pool or curve state. Reserves on both sides, the identity of the quote asset, and the owner of the pool token account. Anything that cannot be read here is treated as a failure, not as a pass.
5. Derive the size before deciding admission. Compute the position size the reserve would support at your impact tolerance. If that size is below the amount you are willing to bother with, reject now and skip the remaining checks.
6. Read distribution. The largest token accounts, the pool's own holding, and the resulting effective float. This is the most expensive check and therefore the last one.
7. Record the decision with its reason. Every rejection is logged with the rule that fired and the value that failed. The rejection log is the only place the rule set can be improved from later.

Notice that sizing sits in the middle rather than at the end. Treating size as an admission criterion removes a whole class of pointless work: if the pool cannot support a position worth taking, nothing about its holder distribution matters. This is also the step where operators discover that their liquidity floor and their buy amount were never reconciled.

How this differs from other automation

Entry automation is one tool class among several, and the distinctions get blurred constantly in tool marketing. A sniper decides whether to open a position in something new. A bundler groups several transactions so they execute together. A volume engine routes flow through an existing pool on a schedule to produce trading activity on a token that already exists. They share plumbing and share almost nothing else, which is why a comparison like volume bot vs bundler is worth reading before assuming one product can do another's job.

The practical difference is what each one is uncertain about. A sniper is uncertain about the token: it is making a judgement under time pressure with partial information, and the counterparty may know far more than it does. A Solana volume bot is not making that judgement at all; the token is already chosen and the work is routing, scheduling and wallet management, where the questions are about cost per swap and about what the tool reports back. Uncertainty about a token and uncertainty about execution are different problems, and confusing them produces tools that do neither well.

There is a third discipline, which this site deliberately leaves alone: whether the transaction lands at all, which is a matter of priority fees, blockhash lifetime and retry behaviour. It is real, it is well documented, and it is somebody else's page. Everything here assumes the send path works and asks what you told it to buy.

The honest summary

A sniper bot is a rule set with a transaction attached. The transaction part is engineering with published constants and a known cost curve. The rule set is a series of judgements about which errors you are willing to make, encoded as thresholds that can be evaluated in a few hundred milliseconds against state that may be incomplete.

Anyone selling the first part as though it were the second is selling the easy half. You can verify a claim about landing behaviour by reading a block. You cannot verify a claim about filter quality without a rejection log, a definition of what counted as a success, and a window long enough to be more than an anecdote. The chain explorers make the first kind of check trivial; a public Solana explorer will show you every transaction a wallet has signed. Nothing shows you the candidates a filter turned down, which is why that log has to be your own.

The rest of this site takes those four decisions apart one at a time. The next page deals with detection in detail: which sources exist, what each one knows when it fires, and how to decide what you are willing to trade for hearing about a token slightly sooner.

Questions this page keeps getting