Created
Decode the successful creation transaction. Verify the mint, Token-2022 program and bonding-curve address.
Check identityHome / Solana token launch monitoring
Solana token launch monitoring.
Monitor Solana token launches and venue state before your client decides to trade.
Observed on chainYour client
Token createdValidate mint
Curve completeWait for migration
Pool validatedQuote + simulate
Observe the event.
Validate the candidate.
One mint. Several trading states.
A token can exist before the market you want is ready. Follow one concrete lifecycle: Pump bonding curve to PumpSwap.
This walkthrough covers regular, SOL-paired Pump create_v2 coins. Mayhem, cashback and custom quote assets need their own integration paths. The sample client skips them.
Trading candidate
Read current reserves, fees and complete. A supported curve can trade before a PumpSwap pool exists.
Wait
Further curve buys and sells fail until migration. CompleteEvent does not mean the pool is ready.
Validate again
Link the migration to its pool. Check the pool, mint pair, vaults and configuration before a new quote.
New venue checksThe final curve buy has a special path.
Under the documented v3 rules, a completing buy can also use the future pool's reserves before the pool exists. Its events can include TradeEvent, CompleteEvent and PostCompleteBuyEvent. This sample client does not attempt that terminal trade. Once it observes a completed curve, it waits for migration.
Creation and a buy can share one transaction. Follow the actual instruction sequence and account state when deciding whether the client can act.
Choose what your client receives.
Build the data path for a Solana sniper bot. Detect a launch, check the venue's current state and let your own client decide whether to trade.
Supanode supplies data transport and queries. Your decoder turns those bytes into a venue-specific launch event and checks whether the transaction succeeded.
Scroll the table horizontally to compare all fields.
| Source | What arrives | What your client must do |
|---|---|---|
| RPC reads | Account state and available transaction data at the requested commitment. | Know which accounts to read; decode them and refresh state. A read does not discover every new launch automatically. |
| WebSocket | Account updates contain account state and context slot. Matching transaction logs contain slot, signature, error and logs. | Decode the selected program's events. logsSubscribe mentions one address per subscription; unfiltered all-logs is blocked on shared plans. |
| Yellowstone gRPC | On-chain transaction updates selected by standard filters. | Validate actual program calls, error status, instruction data and events. Use RPC for current mint, curve and pool checks. |
| Raw ShredStream | Native block fragments delivered to your host over UDP. | Run a receiver, reconstruct and decode data, resolve transaction accounts and verify the chain result. Raw fragments are not parsed launch alerts. |
Processed is provisional.
A processed update can revert. Confirmed and finalized observations offer different assurance and reaction timing. Select commitment explicitly and carry that status through your client.
A filter is a starting point.
Validate your key, program-specific filter configuration, incoming messages and traffic during integration.
Measure end-to-end detection across network delivery, decoding, queueing and recovery in your deployment.
Turn detection into a bounded decision.
Your client evaluates each candidate and signs the transaction.
Validate the program and mint.
Allowlist exact Pump and PumpSwap program IDs. Check successful execution, instruction discriminator and inner calls. Derive the curve or pool accounts and verify their owners and mint pair. A ticker, name or program mention is insufficient.
Read token controls.
Check mint authorities, account freeze state and Token-2022 extensions. Transfer fees, hooks or other restrictions can change the required accounts or prevent a transfer. Skip unknown layouts or unsupported rules. Token-2022 support does not imply support for every extension.
Verify the market you will use.
Read current curve state, or validate the migrated pool, its vaults and enabled operations. PumpSwap quotes use effective quote reserves, including the signed virtual reserve adjustment. Pool creation alone is insufficient.
Set the amount and output floor.
Quote the exact size with current fees and reserves. For an exact-quote v3 buy, set min_tokens_out; an exact-base buy uses max_sol_cost. A sell needs its own fresh quote and output bound. Your client owns size, slippage and fee budgets.
Simulate. Sign. Persist. Send.
Build and simulate the intended transaction, validate the final instructions, then sign locally. Save signed bytes and the locally known signature before the first send. Simulation checks a snapshot; it does not reserve liquidity.
Reconcile the chain outcome.
Track the signature's error and confirmation status, then verify actual token and quote balance changes.
Before every sale, recheck liquidity, account controls, venue configuration and price. These can change after a successful buy.
The correct action can be “wait”.
A new coin appears. Your client recognizes a supported launch, but its next read finds a completed curve. The detection was useful: it prevented a stale curve order.
Observed
Valid creation event for symbolic mint M.
Read current curveState
complete = true; no validated pool.
Next event
Migration links mint M to pool P.
Validate P, refresh quoteClient pseudocode
event = decode_supported_event(update)
if !valid_program_mint_and_mode(event):
return SKIP
state = read_current_venue_state(event.mint)
if state.curve_complete and !state.valid_pool:
return WAIT_MIGRATION
quote = quote_supported_venue(state, size)
tx = build_with_output_bound(quote, min_out)
if !simulate(tx).ok:
return REFRESH_OR_SKIP
signed = local_sign(validate_instructions(tx))
persist(signed.bytes, signed.signature)
submit(signed.bytes)
reconcile(signed.signature)Implement these pseudocode functions with the protocol SDK version you support.
An illustrative output floor
Suppose a refreshed quote gives 1,000 tokens for a 0.1 SOL trade budget. With 6 decimals, the quoted output is 1,000,000,000 base units.
- Invented tolerance
- 300 bps (3%)
- Minimum output
- 970,000,000 base units
- Token amount
- 970 tokens
Sample quote and slippage for the output-floor calculation.
Budget venue fees, network fees and account funding separately. Requote and apply your own policy before trading.
After sending
SUBMITTED → inspect signature status and err → verify balances → record CONFIRMED or failure. On a lost response, reconcile the signature already saved before sending.
Start with the data path you can operate.
For launch discovery, use a documented gRPC transaction filter for the selected program and RPC reads for candidates. Your application supplies the decoder, state machine, limits, signer and transaction ledger.
Solana
RPC + WebSocket + gRPC
FOCUS · optional filtered eventsFor backends that need Yellowstone account or transaction events.
- 25 RPS · 10 TPS
- 1 gRPC subscription · up to 100 addresses
- 20 WebSocket connections
- WebSocket included · gRPC replay: 100 slots
From $99
/ 30 days
Request a free trial up to 24h; our team confirms availability and setup. Check subscription and watched-address limits.
RPC is already included in the FOCUS Bundle.
One filter has a fixed cap of 2,000 addresses; one subscription has at most 10 filters. Filter changes are capped at 30 per minute. The plan's total quota still applies.
Read the subscription and filter limits Solana
RPC + WebSocket
STARTER · entry BundleFor a focused account list and a measured workload.
- 15 RPS · 5 TPS
- 10 WebSocket connections
- 100 subscriptions / connection · 1,000 total
- No gRPC in this tier
From $40
/ 30 days
Request a free trial up to 24h; our team confirms availability and setup. Purchase with a Solana wallet and USDC portal balance.
Use it to follow a manageable set of known curve or pool accounts. Whole-program traffic can be busy; verify the actual workload rather than treating a low address count as a capacity estimate.
Read the WebSocket pathSize the plan for your selected Pump traffic.
Measure messages per second, decode backlog, state-read weights, active account counts and recovery work. Fit those results to the published limits before choosing a tier.
Solana
TPU Sender
Optional · transaction deliveryForward signed transactions through parallel delivery channels, including staked TPU connections with SWQoS. Use your RPC for reads, simulation, network confirmation and execution status.
- 50 requests/s per client profile by default
- Plus Solana network fees
- No monthly subscription · trial on request
0.00015 SOL
minimum tip / transaction
Request an API key or a free trial up to 24h through Supanode on Telegram. Our team confirms trial availability and setup.
Private HTTP minimum tip: 150,000 lamports (0.00015 SOL). Budget any priority fees in addition to network fees.
Include the required tip before signing and track the transaction through confirmation. Check the terms for the access mode you use.
Solana
ShredStream Raw
Separate subscriptionRaw Solana shreds delivered to your receiver over UDP.
- Frankfurt · one IP:port
- B2B only · 7-90 day periods
- No filters; confirm amount for chosen period
- Redistribution requires a separate agreement
$200
/ month · per destination IP
Free trial up to 24h on request; our team confirms availability and receiver setup.
FRA is included in GROW and PROFESSIONAL. Our team provisions your receiver IP and port.
Operate the UDP receiver and data processing. Add raw only when your team can support it and measurements justify it.
Budget for your compute and storage, network/priority fees, venue fees and account funding. Add Sender tips or standalone Raw only when used. Bundle prices use 30-day periods; standalone Raw uses its published monthly period.
Try the Bundle path.
Request a free trial up to 24 hours from our team; availability and setup are confirmed separately. Paid Bundles use a Solana wallet in the portal. Choose FOCUS or above for gRPC. Raw activation is separate; request Sender keys through Telegram.
[ OPEN THE PORTAL ]Check fit before scaling.
Bring your selected program, filters, expected volume and receiver requirements. Confirm current plan limits and access details for the configuration you will use.
Talk to SupanodeKeep failures in the state machine.
| What changes | What your client should do |
|---|---|
| Unknown program, layout or token rule | Skip or quarantine the candidate. Update the decoder and compatibility policy before enabling that path. |
| Repeated updates or several events in one transaction | Deduplicate by signature, instruction/event location and mint. Preserve the complete transition sequence. |
| Curve completes or quote goes stale | Stop the old curve order. Re-read the venue, re-quote and simulate again, or skip. |
| Processed event reverts | Keep provisional and confirmed state separate. Cancel the candidate and reconcile current state. |
| Stream disconnect or queue overload | Pause execution, reconnect and refresh watched state. Drop stale candidates. Solana RPC provides 2 days of replay; gRPC provides 100 slots. Validate recovery coverage and record unresolved gaps explicitly. |
| Send times out or blockhash expires | Inspect the signature saved before send. Check status and expiry before rebuilding an economic action. A missing response is not proof of failure. |
Available RPC history can help investigate a bounded gap. Its retention and method limits still apply. Refreshing current accounts does not reconstruct every launch or trade missed during an outage.
Questions before you connect.
Does a launch event mean the token is tradeable?
Check the selected venue. Pump curve trading can begin without a separate AMM pool, but a completed curve stops trading until migration. Validate current state and the exact instruction you intend to use.
Is this a pending transaction or mempool feed?
No public mempool is assumed. WS/gRPC here observe on-chain execution updates at the selected commitment. Raw shreds are block fragments in propagation and require client reconstruction, decoding and subsequent result verification.
What does my sniper client implement?
Build your client around the Pump/PumpSwap decoder, policy, signing, state recovery and outcome ledger shown in this conceptual workflow.
Which Pump versions does this page describe?
This page follows official Pump documentation at commit 639b87fb45c3adeffa6f7c4a1bf0cb85e392bf22, checked on 20 October 2026. It announces pump-sdk 4.1.0 and pump-swap-sdk 2.1.0. Pin your SDK versions and validate compatibility with the deployed programs.
Do I need Raw ShredStream and Sender together?
Choose them separately. gRPC plus RPC can support the documented client workflow. Raw adds a receiver and processing burden; Sender adds a delivery route and tips. Use either when your measured workload justifies it.
Technical references
Use these protocol definitions and product references to implement and validate your client.
- Pump official docs at the researched commit - program, SDK versions and release chronology.
- Coin creation and Pump IDL - mint, account and event definitions.
- V3 trade instructions and synthetic migration - trade bounds and completion behavior.
- PumpSwap and signed reserve update - pool state and quotes.
- Solana logsSubscribe - commitment, filter and notification fields.
- simulateTransaction, sendTransaction and getSignatureStatuses - execution and confirmation boundaries.
- Token-2022 extension guide - transfer rules and authorities.
- Supanode streams, restrictions and limits - published provider scope.
- Plans, Sender access, tips and Raw ShredStream - prices and separate activation paths.