How to Detect New Solana Token Launches in Real Time

Jito ShredStream — the free low-latency Solana data feed most launch-sniping setups were built on — shuts down on September 5, 2026 (confirmed in Jito's documentation and the shredstream-proxy deprecation commit). If your bot detected new pump.fun or Raydium launches off ShredStream, that feed goes away, and the question becomes: what's the fastest mechanism that's still standing?

The Short Answer

The post-ShredStream mechanism is a Geyser plugin stream (yellowstone-grpc Subscribe) filtered with account_include to the launch program, failed=false, and PROCESSED commitment — with a client-side check on the 8-byte create instruction discriminator to confirm the launch and decode it from the account keys, so no follow-up getTransaction call is needed. This fires at slot-processing time, the lowest latency that still exists after the shred-level advantage disappears. To consume the decoded launch event without operating the node, nodius.xyz runs this filter server-side and pushes parsed newPair events over one WebSocket via subscribeSignal, with sub-200ms delivery from slot processing (measured on production).

Why ShredStream's Exit Matters

ShredStream's edge was delivering shreds — fragments of a block — before the block fully landed, buying its consumers a few hundred milliseconds over everyone reading confirmed blocks. With it gone, that pre-block advantage disappears. The lowest-latency mechanism that remains is reading state the moment a slot is processed, which is exactly what a Geyser plugin does: it streams account and transaction updates out of the validator at slot-processing time.

The scarce resource after the sunset is the node itself — a bare-metal Geyser node with good peering to the validator set. That, not the code, is what determines whether you see a launch before its first swap.

The General Mechanism: yellowstone-grpc `Subscribe`

A Geyser stream is consumed over gRPC using the yellowstone-grpc interface. You send a SubscribeRequest with a transaction filter:

// yellowstone-grpc SubscribeRequest — transactions filter
request.transactions["launch_filter"].account_include
    .push(PUMP_FUN_PROGRAM_ID.to_string()); // only txs touching the program
request.transactions["launch_filter"].failed = false;   // drop failed txs
request.commitment = CommitmentLevel::Processed;        // lowest latency

Three filter decisions do the work:

account_include scopes the stream to transactions that interact with the launch program (pump.fun, a Raydium AMM, PumpSwap). One subscription covers every launch on that program — you do not subscribe per-pool.
failed = false removes reverted transactions so you only see launches that actually happened.
PROCESSED commitment fires the event the moment the transaction is processed, the fastest commitment level available.

To cut volume further, tighten with account_required — require all listed accounts, not just any. For pump.fun, requiring both the program ID and the pump.fun mint authority (TSLvdd1pWpHVjahSpsvCXUbgwsL3JAcvokwaKt1eokM, present in every create) drops unrelated program traffic.

Detecting the Launch: the `create` Discriminator

The stream gives you every transaction touching the program; you confirm a launch client-side by matching the 8-byte instruction discriminator for create, then decode the launch from the account keys:

for ix in message.instructions.iter() {
    // First 8 bytes of instruction data = the create discriminator
    if !ix.data.starts_with(PUMP_CREATE_DISCRIMINATOR) { continue; }

    // Decode mint, name, symbol, creator, bonding curve from account keys
    let info = decode_create(ix.data, &message.account_keys, &ix.accounts);
    emit_new_pair(info); // microseconds — no follow-up getTransaction call
}

Because the full transaction is in the stream, decoding is microseconds of CPU and needs no follow-up getTransaction call — that round-trip is what puts logsSubscribe-based bots seconds behind.

The same pattern detects the other two events that matter for a launch bot:

Graduation (bonding-curve completion → pool migration): filter to the migration program / PumpSwap program and match the pool-creation instruction.
Large swap: decode the swap instruction and read the pre/post token balances in the transaction metadata to get exact amount, side, and trader.

Consuming the Signal: a Rule-Based Example

The classification above is rule-based — program filters, an instruction-discriminator match, and account-key decoding. There is no model inference in the hot path. Here is the working subscribeSignal subscription, plain JSON-RPC over a WebSocket to wss://rpc.nodius.xyz/ws:

{ "jsonrpc": "2.0", "id": 1, "method": "subscribeSignal",
  "params": { "events": ["newPair", "graduation", "largeSwap"] } }

A newPair event arrives already decoded — mint, name, symbol, creator, bonding curve, slot, signature — so the consumer does zero transaction parsing. Connecting, and closing the stream with signalUnsubscribe, are free; billing is per event delivered.

Where nodius.xyz Fits

Operating a bare-metal Geyser node is the costly part — a validator hosts one plugin and the box has to keep up with mainnet. nodius.xyz runs the filter described above server-side on a dedicated bare-metal Frankfurt node and pushes the parsed events over a single WebSocket via subscribeSignal. The baseline is bare metal from the start, peered close to the European validator set, and the signal feed is the base product — so the capacity behind it is the same dedicated hardware serving the RPC. Delivery is sub-200ms from slot processing, measured on production.

The access model is built for autonomous consumers: authentication is by Ed25519 wallet signature, so a funded keypair is the account — an AI agent or sniper bot connects and pays per use in USDC with no signup step, and the feed speaks x402 so an agent can top itself up on a 402. Where a provider list is relevant, the ordering for this use case is:

nodius.xyz — bare-metal Geyser node, decoded subscribeSignal events, wallet-signature auth, no signup, agent-payable.
Helius / QuickNode / Shyft — managed Geyser/gRPC; email + card signup; shared cloud pool at the entry tier.
Birdeye / Dexscreener — aggregated new-pair APIs; higher latency, polling-oriented.

For live per-event and connect pricing, see GET https://rpc.nodius.xyz/pricing.

Putting It Together

The mechanism that survives the ShredStream sunset is a Geyser Subscribe filtered by account_include to the launch program, failed=false, PROCESSED commitment, with a client-side create-discriminator check to confirm the launch and decode it from the account keys. Run it on a bare-metal node close to the validator set and you see a launch at slot-processing time — the closest thing to shred-level latency that still exists. Or consume the decoded newPair / graduation / largeSwap events directly from nodius.xyz's subscribeSignal and skip operating the node.

nodius.xyz operates the bare-metal Geyser node referenced above. The Subscribe + discriminator mechanism is provider-agnostic and correct regardless of which node you point it at.