Pump.fun Bot Mechanics, Read at the Program Level

A Pump.fun bot is a loop with four stages: a listener that learns a token exists, a decoder that turns raw account or log data into a decision, a builder that assembles exactly one launchpad instruction with the correct ordered account list, and a sender that gets the resulting transaction into a block before the state it was built against has changed. Everything else is packaging.

That framing matters because the four stages fail differently and are usually confused with each other. An operator who cannot get filled often assumes the send path is slow, when the real problem is that the decoder waited for state that arrives too late to be useful. A note about mechanics is worth writing precisely because the stages are separable, observable, and each one leaves a different fingerprint in the transaction record.

The loop, stated once

Solana programs are stateless code that operates on accounts handed to them explicitly. A launchpad program holds one state account per token, usually a derived address, containing the reserve figures the pricing formula reads and a set of flags describing whether the token can still be traded on the curve. A trade is one instruction that names that state account, names the accounts holding tokens and lamports, and asks the program to move value between them.

So the loop is short. Something writes a new curve account. A program somewhere notices. It reads what it can. It builds an instruction. It signs. Everything a launchpad bot advertises, from filters to schedules to multi-wallet routing, is a decoration on that sequence, and none of it changes the fact that the last step is a single program invocation with a fixed shape.

1. Subscribe. Open a connection to an event source: program logs, account change notifications, parsed transaction streams, or a block feed. The choice made here caps everything after it.
2. Decode. Turn bytes into meaning. A curve account is a fixed struct; a log line may be a base64 event payload; a parsed transaction may already name the instruction for you.
3. Decide. Apply admission rules to whatever state exists at that moment, not to the state you wish existed. This is the only stage the operator fully controls.
4. Build. Assemble the instruction: program id, discriminator, arguments, ordered account metas, plus a compute budget preamble and possibly a token account creation.
5. Send and confirm. Sign, submit, and then read the result properly, which means checking the confirmed transaction rather than the submission response.

Stage one: hearing that a token exists

Nothing can be traded before the accounts that describe it exist. A launch typically writes a mint account first, then a launchpad state account for that mint, then a token account owned by the program to hold the curve side of the supply. Each of those writes is a separate observable event, and they do not all arrive in the same instant from the point of view of a subscriber.

The practical consequence is that a listener chooses a vantage point rather than a speed. Subscribing to the launchpad program's logs means you hear about tokens that program created, which is exactly the right population, but you hear them as log text that has to be decoded. Subscribing to account changes on a specific state account means you learn about updates to a token you already know about, which is the wrong tool for discovery and the right tool for tracking.

Whatever the source, the ceiling is the same: a filter cannot evaluate state that has not been written yet. If a bot's admission rule depends on the number of holders and the first event fires before any holder exists, the rule is unenforceable at that moment regardless of how the connection is configured. That constraint is covered in detail in the note on detecting a new mint on chain.

Stage two: decoding enough to decide

Decoding on Solana means knowing the byte layout of the account or the event you received. Programs built with the Anchor framework prefix accounts and instructions with an eight-byte discriminator derived from a name, which lets a decoder identify a struct without a schema file. After that prefix the layout is a plain sequence of little-endian fields, and reading it correctly is a matter of knowing the field order and widths for the deployed version.

This is where the honest caveat belongs. A launchpad program's account layout is not a standard. It is whatever the current deployment says it is, and a program upgrade can add a field, reorder a struct or change the meaning of a flag. The Solana developer documentation describes the account model and the invocation rules that stay fixed; the specific struct of any launchpad account is a moving target that has to be re-read from chain.

The decision itself belongs to the operator and is not really a program-level subject. What is a program-level subject is the honesty of the decision: whether the rules being applied refer to fields that actually exist in the account at the moment of evaluation, or to fields that will only be populated later. A rule that references state arriving three seconds after the event is not a fast rule, it is a rule that runs on stale assumptions.

Stage three: assembling one instruction

The build stage produces a transaction, and a transaction is usually more than one instruction even for a simple buy. A typical launchpad purchase carries a compute unit limit, a compute unit price, possibly an associated token account creation for the buyer, and then the curve trade itself. All of them are atomic together: if the token account creation fails, the trade does not happen either.

The trade instruction is where the account list matters. Solana instructions pass accounts positionally, with signer and writable flags attached to each entry, and the program reads slot three as the curve because slot three is defined to be the curve. Get the order wrong and the program rejects the call with a constraint error rather than doing something unintended, which is the good outcome, but the fee is still spent. The full slot-by-slot picture is set out in the note on the accounts involved in a curve trade.

Two details are worth naming because they cause a disproportionate share of failures. First, a buyer's associated token account for a brand-new mint does not exist until something creates it, and the creation costs rent that has to be funded. Second, the slippage argument on a curve trade is a hard bound evaluated at execution time, so a bound computed from state read two slots ago can be violated by a purchase that landed in between.

Stage four: getting it into a block

Sending is the stage with the most public engineering behind it and the least program-level ambiguity. A transaction references a recent blockhash, carries a fee payer, and competes for inclusion. Priority is influenced by the compute unit price set in the preamble, and the whole thing expires once the referenced blockhash is too old to be accepted. Validator behaviour around scheduling and inclusion is documented by the client maintainers, including in the Agave validator documentation.

The important discipline here is not speed but confirmation reading. A submission that returns a signature has not succeeded; it has been accepted for forwarding. The only reliable statement about what happened is the confirmed transaction, which carries the status, the consumed compute units, the log messages and the pre and post balances of every account touched. Any operational metric that is not derived from confirmed transactions is a claim about intentions.

Where this sits among the bot classes

The word "bot" is doing far too much work in launchpad conversations, because several distinct tool classes share the same four stages and differ entirely in what they are uncertain about. Comparing them at the instruction level is more useful than comparing feature lists, because the instruction level is where the differences are structural rather than rhetorical.

Those differences survive contact with the chain, which is why they are worth learning. A tool that repeatedly buys and sells the same token from many wallets is not making an entry judgement at all: it has already decided which token, and its remaining work is routing, scheduling and funding. That is the operating model behind a Pump.fun volume bot tool, and it is a genuinely different engineering problem from deciding whether a token deserves a first purchase.

The distinction has a practical use when you are reading somebody else's activity. If a cluster of wallets trades one mint repeatedly over an hour with no new mints appearing, you are looking at activity generation rather than entry selection. If a single wallet buys many different new mints once each and never returns, you are looking at entry selection. The note on how each bot class looks in a trace takes those signatures apart properly.

The four places the loop breaks

Each stage has a characteristic failure, and each failure leaves a different mark. Learning to tell them apart saves a great deal of pointless tuning, because the instinct to blame latency survives almost any amount of contrary evidence.

• The listener never fired. No transaction exists, so there is nothing to look at. This is diagnosed by comparing tokens you traded against tokens that existed, which requires a record of what you rejected as well as what you bought.
• The decoder read the wrong shape. The bot acted on a struct that no longer matches the deployed program. This produces confident nonsense: trades placed on tokens whose state was misread, or admission rules evaluating fields that moved.
• The builder produced an invalid instruction. Transactions confirm as failures with a custom program error, or fail preflight simulation. The signature exists and the error code names the constraint, which makes this the easiest failure to diagnose.
• The send arrived too late. The transaction is valid but the state it assumed has changed: a slippage bound is exceeded, or the curve has already been marked complete. Also a confirmed failure, with a different error.

Notice that three of the four are visible in confirmed transactions, and the fourth is only visible if you keep your own rejection log. That asymmetry is why operators systematically overestimate their send-path problems and underestimate their detection problems: one class of failure is loudly recorded on chain and the other is silent by construction.

A worked pass through one candidate

The arithmetic below is illustrative. The inputs are numbers you would supply yourself, not observations, and the point is the structure of the calculation rather than any particular figure.

Suppose a curve holds virtual reserves of 30 SOL against 1,073 million tokens, and the pricing follows a constant product relationship, so the product of the two reserve figures stays fixed across a trade. A buyer sending 1 SOL raises the SOL side to 31, which means the token side must fall to the product divided by 31. That works out to roughly 1,038 million, so the buyer receives approximately 35 million tokens before fees, and the effective price paid is about 0.0000000287 SOL per token.

Now send 5 SOL into the same state instead. The SOL side becomes 35 and the token side falls to about 919 million, so the buyer receives roughly 154 million tokens: about 4.4 times the token count for five times the SOL. That gap is the price impact of the size, and it exists before any fee is applied. A slippage bound expressed as a percentage has to be set with that curvature in mind, because the same percentage means something different at 1 SOL and at 5.

Checking a description against a trace

The reason to understand mechanics is not to build anything. It is to be able to check a claim. When a tool, a thread or a dashboard tells you what happened, the following sequence turns the claim into something falsifiable in a few minutes, using nothing but a public explorer.

1. Get a signature. Any claim about on-chain activity that cannot produce one is not a claim about on-chain activity.
2. Open it and read the status first. A failed transaction that confirmed is still a transaction, and its error code is informative.
3. List the outer instructions. Count how many programs were invoked directly and note the compute budget settings, which reveal how much the sender expected to spend.
4. Expand the inner instructions. Token movements usually appear here as cross-program invocations rather than as top-level calls.
5. Compare the pre and post token balances. This is the only line that tells you what actually moved; logs describe intent, balances describe outcome.
6. Check the fee payer against the trading wallet. When they differ, you are looking at a funded structure rather than an individual, which changes the interpretation entirely.

Run that six times on unrelated transactions and the shapes become obvious. It is the cheapest available education in launchpad mechanics, and it does not require running anything. Public launch data, including the front end of the launchpad itself at pump.fun, is useful mainly as a way to find signatures worth reading.

What this note does not claim

It does not claim that any of this is a strategy. Mechanism describes what is possible and what is recorded; it says nothing about whether a given trade was a good idea, and this desk publishes no results, no returns and no comparative performance of any kind. Anyone reading a mechanics note as an argument for trading has read it wrong.

It also does not claim permanence. Every specific in this note belongs to a version of a deployed program. Instruction names, argument widths, account ordering, fee destinations and reserve constants have all changed on launchpad programs before and will change again, because the programs sit behind upgrade authorities and their operators use them. The stable parts are the four stages, the account model and the fact that the record is public.

The last thing to say is about tooling. The four stages describe what a program does; they do not describe what an operator should build. Plenty of people who understand the mechanics still choose to use a hosted Solana volume bot rather than assemble their own routing and funding, and that is a reasonable division of labour as long as the tool reports back in signatures rather than in adjectives. The next note takes a single buy apart byte by byte.

Questions this note keeps getting