One WebSocket, eight Solana data streams

Product teams often bolt a second and third data vendor when the first RPC feed cannot express wallet-scoped trades or migration events. That multiplies auth, reconnect logic, invoice lines, and failure modes. The fix is rarely “more vendors” — it is one connection with selective fan-in.

Tessium’s model is intentional: eight named streams on one authenticated WebSocket. You subscribe to what the product needs tonight and leave the rest quiet. Tomorrow you add a channel without opening a new client, a new API key dance, or a new reconnect story.

The eight streams, grouped by job

• Discovery: launches, migrations, pool_creations
• Market: token_trades, token_transfers, candles
• Wallet: wallet_trades, wallet_transfers

You do not need all eight on day one. A launch bot may start on launches alone. A portfolio view may only need wallet_trades and wallet_transfers. The socket stays the same; subscriptions change. That is the point of a multiplexed API: grow surface area without growing connection sprawl.

Subscribe globally, by token, or by wallet

Tessium lets each stream take the scope your product actually has. Global feeds power research and heatmaps. Token scope keeps a mint page honest. Wallet scope powers copy-trading and portfolio alerts without downloading the whole chain.

Scope is also a cost and reliability control. A global token_trades subscription is a research tool. A mint-scoped subscription is a product tool. Mixing them on the same consumer without clear intent is how dashboards and bots fight for CPU.

Operational rules that keep one socket healthy

• Authenticate once; multiplex subscriptions instead of opening parallel clients
• Treat reconnect as normal — resume subscriptions from your app state
• Bound queues in your process so a slow consumer cannot pretend the stream is fine
• Log drop reasons when filters reject events; silence is how bugs hide
• Separate research firehoses from production subscriptions at the process boundary

Example product shapes

• Launch alert bot: launches (+ optional venue filter)
• Mint terminal: token_trades + candles for one mint
• Copy desk: wallet_trades for a watchlist, with a hard allowlist
• Migration watcher: migrations alone until you need trade confirmation

Each shape is a subscription set, not a new integration. That is how a small team stays coherent while the product menu grows. Write the subscription map next to the deploy checklist so “what are we listening to?” is not tribal knowledge.

Anti-patterns that recreate multi-vendor pain

• One WebSocket per React widget or per microservice replica without a shared fan-out
• Subscribing globally “for now” and filtering in every consumer forever
• Ignoring reconnect and assuming the OS will keep a long-lived socket honest
• Treating candles as a substitute for trades when you need fill-level detail

Build on the event, not the block

If your roadmap is bots, dashboards, or alerts — not running a validator stack — start from structured events. That is the product thesis behind Tessium: Solana activity in a form you can ship against. The Streams page walks each channel and its filters; the quickstart gets a key into a working client in minutes.

When someone on the team asks for “just one more RPC poller,” ask which stream already answers the question. Often the answer is already on the socket — unused because the first integration only wired launches. Inventory subscriptions quarterly; dead channels are cheaper to remove than to debug under incident pressure. Prefer boring clarity over clever fan-out.