WebSocket Subscriptions on Solana

If you're polling getAccountInfo in a loop to watch for changes, you're doing it the expensive, slow way. Solana RPC supports push-based subscriptions over WebSocket and gRPC, and for any reactive workload — bots, monitors, agents — they're the right tool. Here's how they work and how they're billed.

The Short Answer

Instead of asking "did it change?" every few hundred milliseconds, you open a persistent connection and the node tells you when it changes. Lower latency (you see the update the slot it happens), lower cost (no wasted polls), and less code. Use polling for one-shot reads; use subscriptions for anything that watches.

The Main Subscription Types

Solana's WebSocket API mirrors the read methods you're already using:

Subscription	Pushes an update when…	Typical use
`accountSubscribe`	A specific account's data changes	Watching a position, a token account, an oracle price
`logsSubscribe`	A transaction matching a filter is processed	Detecting program activity, tracking mentions of an address
`programSubscribe`	Any account owned by a program changes	Monitoring an entire protocol's state
`slotSubscribe`	A new slot is processed	Driving a per-slot loop (bot tick)
`signatureSubscribe`	A specific transaction reaches a commitment level	Confirming a send landed

The mechanics are simple: connect to the WS endpoint, send a subscribe request with the account/log filter/program you care about, and the node streams notifications until you unsubscribe.

When to Stream vs. When to Poll

The decision rule:

One-shot or rare reads → poll. Fetching a balance once at startup is a plain getBalance.
Watching for a change → subscribe. Anything that would otherwise be a setInterval polling loop should be a subscription.
Very high throughput / many accounts → graduate to Yellowstone gRPC, which streams far more data than WebSocket efficiently.

The trap to avoid is aggressive polling of fast-changing data. It costs more than a subscription, it's slower (you only see state at your poll interval), and it's the pattern most likely to slam into rate limits.

How Subscriptions Are Billed on Nodius

Subscriptions aren't free — the node does real work pushing you updates — but they're priced to be cheaper than the polling they'd replace:

Event	Cost
Opening a subscription	5 credits
Each notification pushed to you	1 credit
Unsubscribing / connecting	Free

So the cost is driven by how chatty the thing you're watching is, not by how often you check. A quiet account you watch for an hour costs almost nothing. A logsSubscribe("all") firehose is expensive — because it's pushing you thousands of notifications — and for that you'd move to gRPC, which bills a flat per-minute rate with no per-notification charge.

Two guardrails to know: you need a small minimum balance to open a connection, and the connection closes if the balance runs out mid-stream (top up and reconnect).

A Minimal Example

import { Connection, PublicKey } from "@solana/web3.js";

// ?api-key= makes standard Solana libraries work unmodified
const conn = new Connection(
  "https://rpc.nodius.xyz/?api-key=" + process.env.NODIUS_API_KEY,
  { wsEndpoint: "wss://rpc.nodius.xyz/ws?api-key=" + process.env.NODIUS_API_KEY }
);

const id = conn.onAccountChange(
  new PublicKey("TargetAccountHere"),
  (info, ctx) => {
    console.log("changed at slot", ctx.slot, "lamports:", info.lamports);
  }
);

// later: await conn.removeAccountChangeListener(id);

The important detail is that Nodius's ?api-key= URL parameter means stock @solana/web3.js code works with no SDK changes — subscriptions included.

The Takeaway

Polling is a habit from APIs that couldn't push. On Solana, the node can push — so for anything that watches state, subscribe instead. You'll see changes faster, spend less than the polling loop would cost, and write simpler code. For very high-throughput streaming, step up to Yellowstone gRPC.