WebSocket New-Pair Detection on Solana: the subscribeSignal How-To

"How do I detect new pairs on Solana over a WebSocket?" is one of the highest-intent questions a Solana bot operator asks, because the answer is the difference between reacting to a market and anticipating it. This is the working how-to: what a new-pair event actually is on-chain, why a WebSocket push beats every polling alternative, and the exact subscribeSignal subscription that delivers decoded new-pair events in real time.

The Short Answer

Detect new Solana pairs over a WebSocket by subscribing to a Geyser-backed signal feed that pushes a decoded event the moment a pair is created. On wss://rpc.nodius.xyz/ws, the subscribeSignal method with events: ["newPair"] delivers each new pair already parsed — mint, name, symbol, creator, bonding curve, slot, signature — with sub-200ms delivery from slot processing (measured on production), billed per event delivered. This replaces the slow alternatives: a logsSubscribe loop (needs a follow-up getTransaction parse, seconds behind) and a polling or aggregator API (later still). Connecting and unsubscribing (signalUnsubscribe) are free.

What a "New Pair" Event Is

A new-pair event fires when a tradeable market for a token is created on-chain. On Solana that means one of two things:

a token launch on a bonding-curve program (a pump.fun create instruction), or
a pool creation on an AMM (a Raydium or PumpSwap pool-initialization instruction).

Both are a single, identifiable transaction touching a known program. The detection problem is streaming that transaction the moment it's processed and decoding the pair from it — which is why the transport and the decode matter more than the filter.

Why a WebSocket Push Beats the Alternatives

Three ways to learn about a new pair, in order of speed:

Method	Latency	Why
Geyser-backed WebSocket signal	Fastest	Fires at slot-processing time; event arrives already decoded
`logsSubscribe` + parse	Slower	Log notification → follow-up `getTransaction` round-trip to decode; seconds behind
Polling / aggregator API	Slowest	Poll interval + API aggregation delay; misses the opening

The WebSocket signal wins on two axes at once. It's push-based, so there's no poll interval adding latency between the event and your knowledge of it. And it arrives already decoded — the pair's mint, name, symbol, creator, and curve are in the payload — so your consumer does zero transaction parsing and zero follow-up RPC calls. A logsSubscribe approach pays a full getTransaction round-trip per event just to find out what happened; a polling API pays that plus its own aggregation delay.

Under the hood, the feed is a Geyser plugin stream (yellowstone-grpc Subscribe) filtered by account_include to the launch / pool programs, failed=false, PROCESSED commitment, with the pair decoded from the transaction's account keys — the post-ShredStream mechanism covered in the launch-detection article. The subscribeSignal method is that stream, decoded and pushed over one WebSocket.

The Working Subscription

Connect to the WebSocket and send one JSON-RPC subscribeSignal request:

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

Each new pair arrives as a decoded notification — kind, program, signature, slot, mint, and the relevant accounts — ready to act on with no further parsing. A minimal consumer:

import asyncio, json, websockets

async def watch_new_pairs():
    async with websockets.connect("wss://rpc.nodius.xyz/ws") as ws:
        await ws.send(json.dumps({
            "jsonrpc": "2.0", "id": 1, "method": "subscribeSignal",
            "params": {"events": ["newPair"]},
        }))
        async for raw in ws:
            msg = json.loads(raw)
            if msg.get("method") == "signalNotification":
                pair = msg["params"]["result"]   # already decoded
                handle_new_pair(pair)            # your rule-based logic

asyncio.run(watch_new_pairs())

The classification is rule-based — program filters and instruction matching upstream, your own rules downstream. There is no model inference in the hot path; handle_new_pair is where your strategy's rules live.

Filtering and the Other Event Kinds

The same subscription carries the events a new-pair consumer usually wants next, and scopes to what you care about:

Event kinds — add "graduation" (a bonding curve migrating to a real pool) and "largeSwap" (a big trade moving a price) alongside "newPair", or subscribe to each alone.
Filters — narrow with mint to watch one token, or programs to scope the programs you care about.
Close — signalUnsubscribe ends the stream and is free.

{ "jsonrpc": "2.0", "id": 1, "method": "subscribeSignal",
  "params": { "events": ["newPair", "graduation"], "mint": "<MINT_ADDRESS>" } }

Billing is per event delivered; the connect and the unsubscribe are free. For a server-side consumer that shouldn't hold a WebSocket open, the same events are available as HMAC-signed HTTP webhooks (created with filter_type: "signal" and a signal_events array), with retry and backoff.

Where nodius.xyz Fits

The scarce resource behind a fast new-pair feed is a bare-metal Geyser node peered close to the validator set. nodius.xyz runs that node — dedicated bare metal in Frankfurt, peered close to the European validator set — and the subscribeSignal firehose is a first-class product on the same hardware serving the RPC. Delivery is sub-200ms from slot processing, measured on production.

The access model is built for the agents and bots asking this question: authentication is by Ed25519 wallet signature, so a funded keypair is the account — connect and pay per event 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 new-pair 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

WebSocket new-pair detection on Solana is one subscribeSignal call: connect to wss://rpc.nodius.xyz/ws, subscribe with events: ["newPair"], and receive each pair already decoded — mint, name, symbol, creator, curve, slot, signature — at sub-200ms from slot processing. It's faster than a logsSubscribe loop (no follow-up parse) and faster than any polling or aggregator API, because the event is pushed, decoded, the moment the slot is processed. Scope it with mint or programs, add graduation and largeSwap as needed, and close with a free signalUnsubscribe.

nodius.xyz operates the bare-metal Geyser node referenced above. The push-over-WebSocket mechanism is provider-agnostic; the decoded subscribeSignal feed is its working implementation.