Building a pump.fun launch bot data pipeline honestly: data path, costs and limits

A pump.fun bot is usually described by what it buys. Most of the engineering is earlier and duller: noticing that a token exists, reading what it is, and deciding in a few hundred milliseconds whether the thing in front of you is worth a transaction. That half is a data pipeline, and it can be described honestly, with its costs and its failure modes. The other half, whether entering a launch makes money, is not something this post will claim anything about. Most launches are worthless, many are built to take money from the people who buy first, and a faster feed does not change that.

What follows is the data path, in the order a candidate moves through it.

Step 1: how the bot learns a token exists

Pump.fun is an on-chain program. Its address in the published IDL (the pump-fun/pump-public-docs repository, read 2026-11-01) is 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P. Every launch is a transaction that calls the program's create or create_v2 instruction, so "a token exists" means "a transaction touched that address". You have three ways to see such transactions, and they are not interchangeable.

Basic is $20 a month and Pro is $249, so the floor for the executed gRPC view is about twelve times the floor for logs. The shred stream is the earliest view and the least informative. A frame carries the signature, the raw transaction and the resolved addresses, so you can see that someone is calling create_v2 and read the arguments out of the instruction data, but you cannot know whether the call will succeed or whether the slot will be skipped. The shred stream reference states this plainly: the transaction may fail, may be dropped, and the slot itself may be skipped. Anything you do on it needs a confirmation channel next to it.

The executed feeds are later and complete. For a bot that must read the new bonding curve's reserves and the creator before deciding, the gRPC transaction already contains what it needs, which saves a read per candidate. We do not publish a figure for how much earlier one feed is than another on your route, and you should not trust anyone's number that was measured from somewhere else. Run both from your own host and compare arrival times on the same signatures; shreds and transaction reconstruction explains why the gap exists.

Step 2: decode from the IDL, and expect the IDL to move

Pump.fun's instructions and events are Anchor-style. An Anchor instruction starts with an 8-byte discriminator, and so does every event. From the IDL read on 2026-11-01:

Two things matter about this table. First, the instruction side has been growing. The same IDL lists 56 instructions, including buy, buy_v2, buy_v3, buy_exact_sol_in, sell, sell_v2 and sell_v3. A decoder that matches only buy and sell reads old traffic correctly and quietly misses everything that goes through a newer variant. There is no error. Your volume chart just looks quieter than the chain is.

Second, the cure is to read the event, not the instruction. TradeEvent has 35 fields in this IDL, including mint, sol_amount, token_amount, is_buy, the four reserve fields and the fee fields. It is emitted whichever instruction variant produced the trade, so one decoder covers all of them. It also grows (the repository's own release notes mention fields added for holder rewards), and Anchor deserialization is positional, so a new field changes the byte layout. Pin the IDL version you decode with, store it with the data, and alert when the decoder meets an unknown discriminator or a trailing-bytes mismatch instead of skipping it.

How the event reaches you depends on how the program emits it. Anchor can write it as a Program data: log line, or as a self-call whose instruction data starts with a fixed tag; the Anchor source calls the second form more reliable because "RPCs are less likely to truncate CPI information than program logs". With logsSubscribe you only get the first. With gRPC you can read both the logs and the inner instructions of the transaction. Test against a recent real transaction to see which carrier you receive, and handle the case where the log was truncated by falling back to a getTransaction read.

Step 3: enrich, and count the reads

A CreateEvent gives you the mint, the bonding curve, the creator and the initial reserves. It does not tell you anything about the creator's history, whether the metadata URI resolves, or whether the same creator launched forty tokens this week. Each of those is a read, and reads have a budget.

Take the plan numbers from the Solana limits table. Read RPC is 60 requests per second sustained on Basic, 200 on Pro and 600 on Business, each with a 2x burst. Suppose a candidate costs three reads: the creator's recent signatures, the creator's token holdings and one getTransaction. Then the sustained candidate rate you can enrich is the budget divided by three:

• Basic: 60 / 3 = 20 candidates per second
• Pro: 200 / 3, about 66 per second
• Business: 600 / 3 = 200 per second

Compare that with the launch rate you actually observe, which you can count yourself in an hour of logs. If launches arrive at a handful per second, any plan is fine and the bottleneck is your own code. If a burst of launches exceeds the number, you queue, and a queued candidate is a stale candidate. The remedy is rarely a bigger plan; it is to enrich lazily, only the candidates that pass a cheap filter you can compute from the event alone. The heavy history reads (getTransactionsForAddress and getProgramAccounts) sit in a separate, much smaller budget of 20 requests per second on Pro, so keep them off the hot path.

Step 4: sending, and what it costs per attempt

Landing a buy is covered in depth in its own right (why a Solana transaction never lands is the short version). For budgeting, a send has three cost parts: the base fee, a priority fee, and optionally a tip.

The priority fee is a price per compute unit multiplied by the compute-unit limit you request. Set a limit of 200,000 and a price of 1,000,000 micro-lamports per unit and you pay 200,000 x 1,000,000 micro-lamports, which is 200,000 lamports or 0.0002 SOL, on top of the base fee. Overstating the limit raises the bill with no benefit, which is why simulating first and setting a tight limit is standard. A tip to a block-engine tip account is a separate plain transfer. Jito's documentation (read 2026-11-01) states a minimum bundle tip of 1,000 lamports and recommends a 70/30 split between priority fee and tip for sendTransaction; during contention the minimum will not win anything.

A fee schedule like this makes the true cost of a losing strategy easy to compute: attempts per day times fee per attempt, paid whether or not the buy lands or the token is worth anything. The send routes we run and their headers are in the sendTransaction reference, and sendTransaction is throttled separately from reads (50 requests per second on Pro, 150 on Business).

What to log so you can tell what is working

Without records you cannot tell a good filter from luck. Log, per candidate: the signature that created it, the feed and the local receive time, the slot, each read and its duration, the decision, and, if you sent, the outcome (landed, landed with error, expired). Measure the delay between the create landing and your decision in your own process before blaming the network. Check the consumer first: a synchronous database write on the socket thread, or a JSON parse of every frame, adds delay that no feed can remove. A slow consumer is also punished by the server, because the buffers are bounded: on the WebSocket streams frames for a client that cannot keep up are dropped, and on gRPC a stream that falls behind is dropped under load.

When this is the wrong approach

If your plan is to be first to a launch by buying a faster feed, expect disappointment. Launches are contested by bots on the same public data, and the winner is decided by landing mechanics and fee bidding, not only by who saw the create. A pipeline like this one tells you what happened; it does not give you a reliable edge.

If you want to understand launches rather than trade them, you do not need the shred stream or Yellowstone. A logsSubscribe on Basic, written to a database, answers most analytical questions. If you only want to look at launches, an existing scanner is cheaper than a pipeline; our own writeup of how a launchpad indexer works shows what such a product does for you.

And if you cannot afford to lose the amount you send, do not send. Every part of this stack tells you about the past or the very near present. None of it tells you whether the token will have buyers in a minute.

Sources

• pump.fun public documentation and IDL, pump-fun/pump-public-docs (program address, 56 instructions, 32 events, TradeEvent and CreateEvent layouts, discriminators), read 2026-11-01: https://github.com/pump-fun/pump-public-docs
• Anchor source, emit! and emit_cpi! event encoding, read 2026-11-01: https://github.com/coral-xyz/anchor
• Jito documentation, low-latency transaction send (minimum bundle tip, 70/30 split recommendation), read 2026-11-01: https://docs.jito.wtf/lowlatencytxnsend/
• Triport Solana limits, read 2026-11-01: per-plan read, heavy-read and send rates.
• Shred stream reference and Solana gRPC reference, read 2026-11-01: filters, plan floors, stream caps.
• Plan prices: Basic $20, Pro $249, Business $499 per month, proxy-agg/configs/tier-matrix.yaml, 2026-11-01.