Detecting a New Token Before Anything Is Certain

A program learns that a new Solana token exists because something it subscribed to fired. That subscription is the whole of its knowledge at the decisive moment, so the practical question is not which source is fastest but which source carries enough state to support the rules you intend to enforce. Those two questions have different answers, and confusing them is the most common design error in the detection stage.

The event sources

Every detection route on Solana reduces to watching one of a small number of things. The names change with the venue; the mechanics do not. A program is either subscribed to logs emitted by a program, to writes on accounts that program owns, or to a service that has done one of those on its behalf.

The last row deserves a caution. A feed is a convenience, and it is also an intermediary deciding what you are allowed to know. If the feed normalises away a field your rules need, the rule cannot run, and you will not necessarily notice: it will simply pass everything. Feeds are fine as long as you have read what they emit and confirmed that your rule set only depends on fields that are actually present.

What each source knows when it fires

State on Solana is written by transactions, and transactions arrive in order. A launch is not an atomic event from the outside; it is a sequence, and where you tap into that sequence determines which parts have happened. The token program state model, including how mint and token accounts relate, is described in the Solana program library documentation, and reading it is the fastest way to see which fields are even available to a rule at each stage.

At mint creation, there is a mint account with a supply figure, a decimals value, and authority fields. There is no pool, so reserves do not exist. There are no holders except whichever account received the initial supply. Metadata may or may not have been written. A liquidity floor cannot be evaluated at this point, not because your code is slow but because the number does not exist yet.

At pool or curve creation, reserves exist by construction, and the pairing asset is known. Distribution is still mostly a question about a single account, since the supply has usually just moved into the pool and the deployer's wallet. Whether the pool tokens are locked is generally not knowable at this instant, because a lock is a subsequent transaction.

At the first observed trade, everything above exists plus a demonstration that at least one participant was willing to buy. That is genuine information and it is expensive: by definition somebody was there before you, and the reserve ratio has already moved. This is the source with the most complete state and the least advantage.

The arrival gap and what is inside it

Between the moment an event occurs on the network and the moment your program acts on it, several things happen that are easy to forget. Naming them is useful because most of them are yours to fix, and the one that is not is the one operators usually blame.

• Propagation. The event has to reach the node you are subscribed to. This part is genuinely outside your control and is the smallest component in most setups.
• Transport. The notification travels from that node to your process. Connection type, region and any intermediate service all sit here.
• Deserialisation. Raw account data or log text becomes structures your rules can read. Sloppy parsing is a real cost and shows up under load rather than in testing.
• Queueing in your own process. If detection and screening share a single execution path, a slow screening call on candidate A delays the detection of candidate B. This is usually the largest and least discussed component.
• Rule evaluation. Every network call inside the rule set adds a round trip. Rules ordered so that expensive checks run first pay this cost on every candidate rather than on the few that survive.

A program that records two timestamps for every candidate, the event time reported by the source and the time its own decision completed, will find the gap larger and more variable than expected. That single pair of numbers is worth more than any amount of provider comparison, because it tells you whether your problem is the network or your own pipeline.

Identity, duplicates and replays

A launch is not one event. Depending on the venue, it can produce a mint initialisation, a metadata write, a curve creation, a pool initialisation and several early trades, each of which may match a subscription. A detector that treats every matching event as a new candidate will evaluate the same token repeatedly and, worse, may act on it more than once.

The fix is cheap and belongs before every other rule. Extract the mint address, check it against a set of recently seen mints, and stop if it is present. The set needs a time-to-live long enough to cover the launch sequence and short enough not to grow without bound. This costs no network calls and removes an entire failure class.

Replays are the related problem. Reconnecting a subscription after a dropped connection can deliver events you already processed, and a detector without identity handling will treat a reconnect as a burst of new candidates. The same recently-seen set handles this, provided it survives the reconnect rather than being rebuilt with the connection.

The completeness trade, with numbers

Waiting is the lever nobody wants to admit they are pulling. Every millisecond spent waiting for state to arrive makes the screening better and the entry later. Making that explicit turns a vague preference into a decision with a stated cost.

Consider an illustrative pipeline where the operator chooses a delay before evaluating rules. The numbers below are invented to show the shape of the trade, not measured anywhere, and the point is the direction of each column rather than any individual figure.

The useful discipline is to name the delay in the configuration and treat it as a first-class parameter rather than an emergent property of however long the code happens to take. An operator who cannot say what their effective delay is has one anyway; it is just unmeasured.

Missing state is not clean state

This is the single most expensive default in a detection pipeline. When a lookup fails, times out or returns something unexpected, there are two possible behaviours: treat the candidate as rejected, or continue with the rule skipped. The second is easier to write and converts every network hiccup into an unscreened entry.

Fail closed. A rule that could not be evaluated has not passed. This produces more rejections during unstable periods, which is exactly the correct behaviour, because unstable periods are when your information is worst. The alternative silently loosens the entire rule set at the moment it is least reliable.

The same applies to fields that are absent rather than unreadable. A missing metadata account is not a clean metadata account. A pool whose reserve read returned zero is not a pool with zero reserves; it is a read that did not work. Encoding the difference between unknown and known-good takes one extra state in the code and prevents a category of entries that are impossible to explain afterwards.

Choosing a source deliberately

The choice becomes straightforward once it is worked backwards from the rules rather than forwards from the desire to be early. The sequence below takes an afternoon and settles the question properly.

1. Write the rule set first, in plain language. Every rule, one claim each, with the field it reads named explicitly. Do this before choosing any source.
2. Mark which field each rule needs. Authority fields, reserves, holder accounts, metadata, ownership. Group the rules by the state they depend on.
3. Find the earliest event at which each field exists. Some fields exist at mint creation, some only at pool creation, some only after the launch sequence has completed.
4. Take the latest of those events as your floor. Subscribing earlier than this means some of your rules cannot run, which means they are not rules but decorations.
5. Decide explicitly whether to drop rules or accept the later trigger. Both are legitimate. Only the unexamined version, where rules silently no-op, is not.
6. Instrument the pipeline with two timestamps per candidate. Event time and decision time. Without them you cannot tell a network problem from a code problem, and you will spend money on the wrong one.
7. Log every rejection with the rule that fired. Detection choices are validated by what the rejection log looks like a week later, not by how the pipeline felt on the first day.

Step four is where most designs quietly break. It is very common to see rule sets that reference liquidity or holder distribution while subscribed to an event that predates both, in which case those rules evaluate against defaults and admit everything. The code runs, the log looks healthy, and the filter set is doing a fraction of what its author believes.

Watching more than one venue

Most operators end up subscribed to several launch venues at once, and the failure modes multiply in ways that are worth anticipating. Each venue has its own account layout, its own log format and its own notion of what a launch consists of, so a detector that normalises them into one internal candidate structure has to decide what to do about fields that only some venues provide.

The safe rule is that a normalised candidate carries an explicit unknown value rather than a default. If a venue does not expose pool reserves at the trigger point, the reserve field is unknown, and any rule reading it rejects. Filling that field with zero, or with a plausible-looking placeholder, converts a structural gap into a silent pass and is the most common way a multi-venue detector ends up screening one venue properly and the rest not at all.

Throughput is the second consideration. Several subscriptions produce several event streams that peak at the same times, and a single-threaded pipeline will queue. If detection and rule evaluation share one execution path, a slow lookup on one candidate delays the detection of every candidate behind it, which shows up as apparent latency that no provider change will fix. Separating the two, so that detection only enqueues and evaluation runs independently, costs a little complexity and removes an entire class of confusing measurements.

The third is bookkeeping. Per-venue counters for candidates seen, rules skipped and candidates rejected make it obvious when one subscription has silently stopped delivering. Without them, a dead subscription looks exactly like a quiet day.

What detection cannot buy you

Detection sets a ceiling and nothing else. It decides which candidates are reachable, and it decides how much you know about them when the decision is due. It does not decide anything about quality, and a faster route into a poorly designed rule set produces the same entries slightly sooner.

It also has nothing to do with whether the resulting transaction lands. Landing is governed by fee priority, blockhash lifetime and retry behaviour, all of which are documented in the Anza validator documentation and all of which are somebody else's specialism. Detection and delivery are separate stages that fail separately, and the fastest detector in the world attached to a send path that does not land is a very well-informed observer.

Finally, detection stops mattering entirely once the token is known. An operator working with a token they already hold has a routing and scheduling problem rather than a discovery one, and the questions change accordingly: cost per swap, wallet handling, whether attempted and landed activity are reported separately. A volume bot for Solana is built for that second situation, where the candidate was chosen long before any automation ran. It is a different tool for a different uncertainty, and reading it as a faster sniper is how operators end up with the wrong product.

The next stage is where the discovery actually pays off or does not. Once a candidate has been detected with a known set of available fields, the rules decide whether it is admissible, and that is a design problem with its own ordering, its own arithmetic and its own failure modes.

Questions this page keeps getting