How Each Bot Class Looks in a Transaction Trace

A transaction never says which software produced it. It does record structure, and four structural dimensions separate the common classes of launchpad automation with reasonable confidence: how many wallets act together, where their funding came from, how tightly their transactions are spaced in slots, and what the instructions actually do. Read together, those four narrow the field considerably. Read alone, any one of them will mislead you.

This note is written for reading other people's activity, not for producing your own. The value of the exercise is that it makes marketing claims checkable. When a thread asserts that a token is being traded by a particular kind of tool, the assertion either survives a look at the funding graph and the slot spacing or it does not.

What a trace can establish

A confirmed transaction is unusually rich. It carries the ordered instructions, the nested inner instructions produced by cross-program invocations, the account list with signer and writable flags, the fee payer, the compute budget settings, the program logs, the pre and post lamport balance of every account, the pre and post token balances, and the slot. All of it is public and permanent, and all of it is readable in a standard explorer such as the official Solana explorer.

What it does not carry is identity or intent. There is no user agent, no client fingerprint field and no operator name. Everything in this note is therefore an argument from structure, and structural arguments have a ceiling: they establish what happened and how it was arranged, never who arranged it or why. Keeping that boundary visible is the difference between analysis and accusation.

The four dimensions that separate classes

Rather than memorising patterns, it is more durable to learn the dimensions the patterns are made of. Each one is directly observable and each one answers a different question about the operation behind an address.

• Fan-out. How many distinct wallets participate, and whether they act on the same mint. One wallet acting alone and forty wallets acting in concert are different operations regardless of what they trade.
• Funding shape. Where the lamports came from. A funding graph that converges on a single source is a strong structural fact, visible as system transfers preceding the trading activity.
• Temporal spacing. The slot distance between related transactions. Same-slot or adjacent-slot activity implies coordination at the submission layer; spacing measured in minutes implies a schedule.
• Instruction content. Which instructions are sent, in which direction, and how often the same pair repeats. Direction is the cheapest discriminator available and the most often ignored.

A fifth signal sits slightly apart from the four because it is a property of the transaction rather than of the campaign: the relationship between the fee payer and the signer. Solana allows one account to pay for a transaction another account authorises, and when those differ you are looking at an arrangement rather than an individual. It is a single boolean comparison per transaction and it separates funded structures from ordinary wallets faster than anything else in the record.

Compute settings deserve the same treatment. A declared compute unit limit repeated to the byte across dozens of transactions from unrelated addresses is a fingerprint of a shared default rather than of a shared owner, but defaults travel with software, and software travels with operations. On its own it proves nothing; combined with a funding relationship and tight slot spacing it turns a plausible reading into a well-supported one.

Each dimension can be faked or blurred deliberately, and sophisticated operators do blur them. What is difficult is blurring all four at once while still doing the thing the tool exists to do, because the underlying job constrains the shape. A tool that has to produce repeated activity has to send repeated instructions, however carefully it varies its wallets.

The signature matrix

The most useful column combination is direction against token variety. Many mints bought once each is entry behaviour. One mint traded in both directions for an extended period is activity generation. Those two are almost never confused once you have looked at the pair explicitly, and they are confused constantly when reading a single transaction in isolation.

The entry bot

An entry bot's trace is sparse and directional. A wallet appears, buys a mint that has existed for a very short time, and either sells later in a separate transaction or does nothing further. Its compute unit price around launches is usually elevated, because inclusion urgency is the whole point, and its slippage bounds are tight, because it is trying to enter at a specific point on the curve.

The characteristic tell is the failure pattern. An entry bot that is genuinely competing will show a meaningful number of confirmed failures with bound-related errors, because it is submitting against state that other buyers are also moving. A wallet with no failures at all is either not competing or not operating on new launches, which is worth knowing before drawing conclusions about its performance.

The other tell is variety. Entry selection means evaluating many candidates and buying a few, so the wallet's history shows a range of unrelated mints with short holding relationships. A wallet that only ever touches one token is doing something else, whatever its transactions look like individually.

The bundler

Bundling is about adjacency: getting several transactions included together so that nothing lands between them. In the trace this shows as a group of transactions in the same slot or in immediately adjacent slots, frequently from wallets that were funded from a common source shortly beforehand, all touching the same mint in the same direction.

The funding step is the part people miss. Wallets that participate in a group event have to be funded, and those funding transfers are ordinary system program transfers that appear in the record with timestamps and amounts. A cluster of new addresses receiving near-identical amounts from one source minutes before a launch is one of the most legible patterns on the chain, and it requires no special tooling to see.

The volume engine

A volume engine has already decided which token it is working on, so it makes no entry judgement at all. Its work is routing, scheduling and wallet management, and its trace shows exactly that: repeated buy and sell pairs on a single mint, spread across a set of wallets, spaced at intervals rather than crammed into one slot, with slippage bounds set wide because filling reliably matters more than filling at a particular price.

Balance reconciliation makes the class obvious. Over a run, a wallet's token balance returns close to where it started while its lamport balance declines by roughly the accumulated fees and price impact. That is the arithmetic signature of activity generation, and it is very hard to disguise, because the whole point of the exercise is that the token keeps moving.

This is the class where the tooling market is most visible. Anyone running a Pump.fun volume bot is buying scheduling, wallet handling and reporting rather than a market opinion, which is why the honest way to evaluate one is to ask what it hands back: a list of signatures and slots can be reconciled by anyone against the balance deltas described above, and a summary figure cannot.

It is worth stating the interpretive limit here as clearly as anywhere on this site. Observing repeated two-directional activity on a mint tells you that activity is being produced. It does not tell you who commissioned it, whether the token's team knows, or what anyone intended by it. Those are questions the ledger cannot answer, and confident answers to them are inference wearing the clothes of data.

The copy trader

A copy trader is defined by its dependency: every transaction it sends follows a transaction from somewhere else. In the trace this appears as a consistent lag, usually a small number of slots, behind a specific other wallet, on the same mints and in the same direction.

The identifying test is correlation across many events rather than any single transaction. One wallet buying after another proves nothing. The same wallet buying after the same source across a dozen unrelated mints, always later and never earlier, is a strong structural relationship. It is also, notably, a pattern that can exist without either party knowing, since the source wallet has no say in who watches it.

A worked fan-out read

Here is the shape of the reasoning, using illustrative figures rather than observed ones. Suppose you find one address that sends eleven system transfers of the same amount to eleven fresh addresses inside a two-minute period. Each of those addresses then creates a token account for the same mint and sends a purchase, all within a handful of slots of each other, with identical declared compute unit limits.

What is established: one funder, eleven wallets, one mint, tight temporal clustering, uniform client configuration. Those are facts in the record, each independently checkable from a signature.

What is inferred: that the eleven wallets are operated as a unit. This is a strong inference and still an inference, because a shared service could fund customer wallets the same way. What is not established at all: who the operator is, whether the token's creators are involved, or what the purpose was. A report that stops at the first paragraph is analysis; one that continues into the third is speculation with a chart attached.

Patterns that get misread

• An exchange or router wallet. High-volume addresses that touch many mints in both directions are often infrastructure, not automation. Check whether the wallet's counterparties are diverse and whether it holds balances between events.
• A market maker on an established pair. Two-directional repeated trading also describes legitimate market making, and the trace alone does not distinguish intent. Venue and pair maturity matter more than the pattern here.
• One user with several wallets. Funding convergence is common among individuals who separate holdings by purpose. Cluster size and timing tightness are what distinguish this from an operation.
• Failed transactions counted as activity. Failures confirm, appear in the record, and pay fees. Counting them as trades inflates every derived figure, and it is the single most common arithmetic error in trace analysis.

The fourth one is worth dwelling on because it distorts published numbers regularly. A wallet with many confirmed-but-failed transactions looks busy in any tool that counts signatures instead of successful state changes. The only defence is to filter on transaction status before counting anything, which is a one-line discipline that a surprising amount of public analysis omits.

Where the evidence stops

Structural analysis is powerful and bounded. It establishes what was arranged and how, and it stops at every question about people. This is not a limitation of tooling that better tooling would solve; it is a property of the data. Nothing in the ledger records who held a key, and nothing records why.

It is also bounded in time. Patterns drift as clients change defaults, as operators deliberately vary their shapes, and as launchpad programs are redeployed with different instruction sets. A matrix like the one above should be re-derived against recent data periodically rather than carried forward indefinitely, in exactly the way an account layout should be.

The final caveat is about tool classes themselves. The four categories here are a useful frame, not a taxonomy the chain enforces, and real software mixes them: a single product may detect launches, group submissions and generate activity depending on how it is configured. When somebody says they run a multi-DEX Solana volume bot, the honest reading of that claim is still a set of signatures on specific venues, which is exactly what the next note does for the moment a curve finishes and its liquidity moves elsewhere. Public front ends such as the launchpad's own site are useful mainly for finding those signatures in the first place.

Questions this note keeps getting