Detecting a New Mint on Chain, Source by Source

A new launchpad token becomes visible in stages: a mint account is initialised, a launchpad state account is created for it, a token account owned by that state is funded with the curve supply, and an event is written describing the creation. A detector attaches to one of those moments, and the moment it attaches to determines what it can know, what it will miss and how often it will see the same launch twice.

Almost every argument about detection is really an argument about that choice, conducted in the vocabulary of speed. Speed is a genuine constraint, but it is downstream of a more basic question: at the instant your listener fires, which accounts exist, and what do they contain?

What detection actually means

Detection is the conversion of a chain event into a decision-ready record. The chain does not emit "a new token launched". It emits account writes, and a program that wants to act has to notice a write, decide which launch it belongs to, and assemble a picture of that launch from accounts that may still be arriving.

Two properties matter for any detector and they trade against each other. Coverage is the fraction of real launches the detector reports at all. Completeness is how much of the launch state is available at the moment of the report. A source with excellent coverage and poor completeness produces early reports about tokens you know almost nothing about, which is exactly the situation most launchpad listeners are actually in.

The writes a launch produces, in order

The sequence below is the general shape for a launchpad of this kind. The exact grouping into transactions and the presence of individual steps depend on the deployed program version, so treat the ordering as structural rather than as a fixed script.

1. A mint account is created and initialised: decimals, supply and authority fields are written.
2. Metadata is attached, giving the token a name, a symbol and a link to off-chain content.
3. The launchpad program creates its state account for the mint, typically at a derived address, and funds it to rent exemption.
4. A token account owned by that state account is created and receives the portion of supply that will be sold along the curve.
5. The program writes an event describing the creation, which is what a log-based listener actually reads.
6. The first trades arrive, each one updating the reserve figures in the state account.

Steps three and four are the ones that matter for trading, because until both have landed there is nothing to trade against. A listener that fires on step one is early in a way that is not useful: the token exists, but the market for it does not.

The sources you can subscribe to

There are four broad families of source, and each is a different vantage point on the same sequence rather than a faster version of the same thing. The subscription mechanisms themselves are documented as part of the node interface in the Solana developer docs.

Discovery and tracking are different jobs

Notice that none of the rows is strictly better. A log subscription gives the tightest population and the weakest structure. A block stream gives complete structure and the widest firehose. The right answer depends on whether the detector is being built for discovery or for tracking, and those are different jobs that get conflated constantly.

What exists when each source fires

This is the crux. A rule can only be evaluated against state that has been written, and the early events fire before most of the interesting state exists.

Read that table as a constraint list rather than as a timeline. Any admission rule that mentions holders cannot run at the first three rows. Any rule about trade velocity cannot run before there are trades. An operator who believes their filters are running early and strictly is usually running them at the fourth row and calling it the first.

One launch, several events

A single launch can produce a mint creation event, a metadata write, a state account creation, a token account creation and a first trade, and a naive detector will treat several of those as separate discoveries. The symptom is a detector that reports more launches than exist, or that acts twice on the same token.

The problem is worse with mixed sources. A listener subscribed to both program logs and program accounts will hear about the same state account twice by design, once as a log line and once as a write notification, with no guaranteed ordering between them. Deduplication is therefore not an optimisation; it is a correctness requirement, and it has to be built before the detector is trusted for anything.

• Key on the mint, not on the event. The mint address is the stable identity of a launch. Everything else is a view of it.
• Record first-seen slot separately from first-seen wall clock. Slots are the chain's ordering; local time is your machine's opinion.
• Expect out-of-order arrival. Two subscriptions on the same connection carry no ordering guarantee relative to each other.
• Keep the rejected entries. A detector that logs only what it accepted cannot be audited later, and audit is the whole point.

Building a stable identity for a launch

The mint address is the natural key, but a detector needs slightly more than a key to be useful. A minimal launch record holds the mint, the derived curve state address, the slot at which the state account first appeared, the signature of the transaction that created it, and a flag for whether metadata has been observed yet.

That last flag matters because metadata often arrives in a different transaction from the state account creation. A record that waits for a name before reporting anything will be late on every launch; a record that reports without a name and fills it in later is correct and awkward. Choosing between those is a design decision that should be made explicitly rather than discovered in production.

Reconnection and backpressure

Two operational details sit alongside the record design and are worth planning before they bite. The first is reconnection. A subscription is a long-lived connection and long-lived connections drop, which means a detector needs to know what it missed while it was away rather than resuming as if nothing happened. The honest recovery is a backfill from history over the gap, keyed on the same mint identity, so the record has no silent hole in it.

The second is backpressure. Around a busy period a stream can deliver events faster than a decoder handles them, and the failure is rarely dramatic: the queue grows, reports arrive later, and the detector reports the same launches it always did while being progressively less early. Measuring the gap between the slot in an event and the slot at the moment it is processed makes that drift visible, and it is a far more useful health metric than a connection status indicator.

The completeness trade

Every detector makes the same trade, usually without noticing. Reporting at the earliest possible event maximises how much time remains before others act, and minimises how much is known. Waiting a few slots reduces the time advantage and makes every rule downstream enforceable.

The trade is not symmetric, and that is the useful observation. Time advantage is only valuable if the decision made with it is good, whereas information improves the decision directly. An operator who cannot articulate what their extra half-second buys them is optimising the side of the trade that is easy to measure rather than the side that decides the outcome.

There is a third option that is often the right one: report early and decide late. The detector emits a record as soon as the state account exists, and the decision layer subscribes to that record and to subsequent writes, acting when its rules become evaluable. That separates coverage from admission, which are genuinely different concerns and are almost always tangled together in practice.

A worked ordering example

Suppose a launch produces its state account in one slot, and its metadata write lands two slots later. Solana targets roughly four hundred milliseconds per slot, so two slots is on the order of eight hundred milliseconds, though actual slot times vary with network conditions and the target is a design goal rather than a guarantee. Validator behaviour around slot production is documented by the client maintainers at the Agave documentation site.

A detector that requires metadata before reporting therefore reports at least two slots after one that does not. If the first three trades against that curve land in those same two slots, the metadata-waiting detector has not merely arrived late; it has arrived after the reserve figures it will read have already moved, and any rule it applies about entry price is being applied to a different curve state than the one it was designed for.

Neither behaviour is wrong. What is wrong is holding both beliefs at once: that the detector is early, and that it screens on metadata. Writing down which slot each rule becomes evaluable at resolves the contradiction in about ten minutes and is the most useful exercise in this note.

Verifying a detector against history

Detection quality is measurable without any live experiment, because the chain keeps the answer. The procedure is a replay: fix a past window, build the ground-truth list of launches from history, compare it against what the detector reported, and attribute every difference.

The reason to insist on a fixed historical window rather than a live comparison is that live conditions change between runs, so two live tests measure two different markets. A replay against identical history measures the change you made. That distinction is the difference between engineering and superstition, and it costs nothing but discipline.

The same discipline applies to any tool you did not write. When a hosted service reports what it detected or executed, the honest form of that report is a list of signatures you can reconcile against history yourself. This is as true for Pump.fun volume automation as it is for a detector you built in a weekend: a claim that resolves to signatures is checkable, and a claim that resolves to a headline number is not.

What a detector cannot know

It cannot know intent. A newly created curve account is a fact about state, not about the person who created it, and nothing in the creation transaction says whether the launch is serious. Detection produces candidates; it does not produce judgement, and any tool that markets detection as if it were judgement has quietly changed the subject.

It cannot know the future ordering of other people's transactions. Two detectors seeing the same event at the same instant will still land in an order determined by leader scheduling and fee markets, which is outside both of their control. This is why detection quality should be measured as coverage and completeness rather than as position in a race.

Finally, it cannot know that its own view of the program is current. A detector decodes a struct according to a layout, and that layout belongs to a deployed version. When a launchpad program is redeployed, a detector that is not re-validated will keep producing confident output from a stale schema, and nothing in the data stream will tell it. Periodic re-derivation from a recent confirmed transaction is the only defence, and it is the same defence that runs through every note on this site.