Stream Solana data with TypeScript.

The client constructor takes three arguments: the endpoint URL, an authentication token (or undefined if you pass credentials via metadata instead), and an options object for gRPC channel configuration. The most important option is grpc.max_receive_message_length, which controls the maximum size of inbound messages. Solana blocks can be large — especially when they contain many transactions — so setting this to 64 MB prevents unexpected stream terminations on high-throughput slots.

Authentication varies by provider. Most Yellowstone endpoints accept an x-token header, which the client sends automatically when you pass a token string as the second constructor argument. Subglow and some other providers use x-api-key instead — you can pass this via the metadata parameter when calling subscribe(). Either approach works; the difference is purely which header the provider expects.

Account subscriptions let you watch for state changes on specific accounts or all accounts owned by a particular program. This is fundamentally different from transaction subscriptions — instead of getting notified when a program is invoked, you get notified when an account's data changes, regardless of which program caused the change. This makes account subscriptions ideal for use cases like copy trading (watching whale wallets for balance changes), portfolio tracking (monitoring your own token accounts), and liquidation monitoring (watching margin accounts approaching liquidation thresholds).

You can filter accounts by owner — which gives you every account owned by a specific program — or by specific account public keys. Owner-based filters are broader: subscribing to the Token Program owner gives you updates for every SPL token account on Solana. Pubkey-based filters are precise: you specify exactly which accounts to watch. For most trading applications, you'll use pubkey filters to track known wallets or liquidity pool accounts.

gRPC streams are long-lived connections, and every long-lived connection will eventually disconnect. Network partitions, load balancer rotations, server deployments, and transient DNS failures all cause stream interruptions. A production TypeScript bot that doesn't implement reconnection logic will silently stop receiving data after the first interruption — and in trading, silent data gaps are expensive.

The standard approach is a reconnection wrapper with exponential backoff. When the stream emits an error or ends unexpectedly, you wait a short interval, then attempt to reconnect. If the reconnection fails, you double the wait interval up to a configurable maximum, preventing your client from flooding the server during an outage. Tracking the last processed slot gives you a resumption checkpoint — after reconnecting, you can detect gaps in the slot sequence and take corrective action.

Different gRPC error codes require different handling strategies. UNAVAILABLE is transient — retry with backoff. CANCELLED usually means the server closed the stream — reconnect immediately. DEADLINE_EXCEEDED means your timeout was too short — increase the deadline and retry. UNAUTHENTICATED is permanent — your API key is invalid and retrying won't help. Distinguishing between retryable and non-retryable errors prevents your bot from wasting cycles on reconnections that will never succeed.