Pump.fun streaming architecture.
Every piece of a production-grade Pump.fun bot, end to end. On-chain events, graduation detection, sellability checks, Jito bundle submission, and the failure modes that will bite you if you skip any of them.
The six-stage pipeline
Every competitive Pump.fun bot runs this pipeline. Drop any stage and your fill quality drops with it.
- 1Yellowstone gRPC subscription
Subscribe to the Pump.fun main program (6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P) + Raydium AMM v4 program. Include vote=false, failed=false to cut 85%+ of the firehose. Target: 30–80ms slot-to-client on a colocated provider.
- 2Event classification
Parse each transaction into one of five event types: buy, sell, create, graduation, migration. Pump.fun's instruction discriminators are stable and documented in the IDL. Pre-parsed providers (Subglow) do this server-side; standalone clients do it via anchor-client.
- 3Target wallet matcher
For copy trading: index your target wallet list and fast-check every incoming buy/sell against it. Use a hash set, not an array scan — you're matching against 100+ wallets on every message. Sub-1ms match time is expected.
- 4Sellability + rug gate
Before every mirror buy, simulate a sell via Jupiter's quote API and run basic rug heuristics (creator balance, holder concentration, first-minute volume sanity). Typical cost: 20–40ms per candidate trade. Skip rate: 5–15% of candidate buys filtered out.
- 5Sizing + Jupiter route
Apply your per-wallet sizing rule (fixed SOL, % of target, % of your bankroll) and get a Jupiter quote for the exact input amount. Use swap_mode=ExactIn for buys. Build the transaction with priority fee and Jito tip from current-slot percentile data.
- 6Jito bundle submission
Sign the swap transaction and submit as a single-transaction Jito bundle to your nearest Jito block engine. Target: bundle inclusion within 1–2 slots of the target's buy. Failed bundles should auto-retry once with an increased tip; beyond that, accept the miss and move on.
Latency budget
A competitive bot has ~300ms total. Here's where every ms goes:
Shave a single step (no pre-parsed events, no colocated gRPC, no Jito bundling) and you push past 800ms, at which point your fills on fast bonding-curve tokens are 15–40% worse than the target's. Copy trading is entirely a latency game.
Failure modes the docs don't warn about
Graduation race condition. When a token graduates, there's a 1–2 slot window where the bonding curve is drained and the Raydium pool is being seeded. A naive bot tries to buy from the curve and fails, or worse, sells into near-zero liquidity on the way in. Always check for graduation events and switch routing.
Priority fee cliff. During popular launches, priority fees spike from 0.001 SOL to 0.5+ SOL in seconds. Static priority fee config will make you either overpay by 100x during quiet moments or miss every hot launch. Pull the current 40th–80th percentile dynamically per slot.
Jupiter slippage drift. The quote you received at t=0 may not hold at t=150ms when your transaction lands. Build your transaction with the slippage tolerance you actually want, not the quote's expected output. Let Jupiter abort the swap if liquidity shifted past your tolerance — a failed swap is cheaper than a 10% bad fill.
Sell-side execution amnesia. Most bots focus on entries and neglect exits. When a target sells, you need to mirror that sell within the same latency budget or you hold the bag. Treat sell mirrors with the same urgency as buy mirrors — they're often where the edge actually lives.
FAQ
What are the key Pump.fun program IDs to subscribe to?
The main Pump.fun program is 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P. Subscribe to it with a transaction filter (account_include, vote=false, failed=false) and you capture every buy, sell, create, and graduation event. Graduated tokens move to Raydium AMM v4 (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8) or Raydium CPMM — your bot needs to subscribe to both to track a token through its full lifecycle.
How do I detect the graduation moment?
Pump.fun emits a specific instruction (discriminator 0xe8 or similar, confirm in the IDL) when a token crosses the ~$69k market-cap threshold and its liquidity migrates to Raydium. The event includes the new Raydium pool address. A well-built bot watches for this instruction specifically and updates its internal token state to point at the Raydium pool for subsequent trades. Without graduation handling, your bot will try to sell a bonding-curve token that no longer has curve liquidity.
What's the sellability check and why does it matter?
Pump.fun's permissionless token creation means honeypot tokens are routine — tokens where the creator disabled sells or drained the curve. Before every mirror buy, a production bot simulates a sell transaction using Jupiter's quote API. If the quote returns zero output, a suspiciously tight price impact, or a known-bad route, the bot skips the trade. This catches ~99% of honeypots with sub-10ms overhead. Subglow's executor runs this check server-side by default.
What's the minimum latency for a competitive Pump.fun bot?
End-to-end target: 200–400ms from target wallet's on-chain buy to your bot's signed and submitted Jito bundle. Budget: 30–80ms for gRPC detection (using Subglow or equivalent colocated Yellowstone), 20ms for bot decision logic, 50–100ms for Jupiter quote + transaction build, 80–150ms for Jito bundle submission and slot landing. Bots running on public RPC typically see 1.5–3s end-to-end and lose to bots on dedicated gRPC every time.
How do I filter out obvious rug signals in real-time?
Several heuristics apply cheaply: (1) creator wallet has <1 SOL balance and is fresh (<24h old) — skip; (2) first-minute volume is >90% from the creator's wallet — skip; (3) top 3 holders control >50% of supply after the first 100 buys — skip; (4) a Raydium pool exists with obviously manipulated reserves — skip. None of these are perfect, but stacked they reduce rug exposure from ~5% of buys to ~0.5%. Combine with the sellability check for production-grade filtering.
Should I decode the bonding curve state myself or rely on pre-parsed events?
For a production bot on hot-path trading, rely on pre-parsed events — you shave 15–30ms per message that would otherwise go to Borsh decoding and instruction discrimination. For one-off analytics or state reconstruction, decoding yourself from the raw account data is cleaner because you're not at the mercy of a provider's parsing schema changes. Subglow's pre-parsed events cover the common paths (buy, sell, create, graduate); the raw transaction is always included for bot-specific custom logic.