Real Time Solana Volume Data: Where the Number Comes From

Real time Solana volume data reaches you through one of four transports: HTTP polling of an RPC node, a WebSocket subscription, a provider webhook, or a Geyser stream taken from inside a validator. Each one delivers the same underlying blocks with a different promise about delay, completeness and replay. The transport you choose is the largest single factor in what your number means.

None of these routes hands you a figure labelled volume. They hand you transactions. Volume is something a pipeline computes afterwards by deciding which programs count, which side of each trade to measure, and how to fold multi-hop routes into a single event. That computation is where two honest systems end up disagreeing, and it is the part almost nobody documents.

What volume means before you can measure it

On Solana there is no protocol-level concept of trading volume. There are transactions, and within them instructions, and within those a set of account balance changes the runtime recorded. A swap is a pattern in that data, not a first-class object. The first decision any pipeline makes is which patterns it agrees to recognise, and that decision quietly defines the number for everyone downstream.

The second decision is denomination. A swap of SOL for a token moves value both ways at once. Counting the SOL side gives one figure, counting the token side priced against SOL gives a slightly different one because the pool takes a fee, and counting both sides doubles the total. Most venues and most aggregators count one side, but they do not all pick the same side, and none of them is wrong in isolation.

The third decision is scope. A token trades on a bonding curve, then on an automated market maker, then on several pools at once, possibly with an aggregator splitting a single user order across them. A figure that covers one venue is not comparable with a figure that covers six. When a dashboard shows a token trading at a level your own pipeline cannot reproduce, the venue set is the first thing to check.

The four routes a number can travel

The table below is the shape of the whole subject. Everything else in this section elaborates one row of it. Read the guarantee column rather than the delay column, because delay varies with your provider and your region while the guarantee is a property of the transport itself.

Notice that only the first row has a replay story. HTTP is the only transport in that table where you can go back and ask for something you missed, because a request carries its own coordinates. The other three are live wires: they tell you what is happening now, and if you were not listening then it did not happen as far as your system is concerned.

Route one: asking an RPC node on a timer

Polling means calling JSON-RPC methods on a schedule. For volume work the relevant methods are getSlot to know where the chain is, getBlock to fetch a block with its transactions, getSignaturesForAddress to walk the history of a pool or a wallet, and getTransaction to pull one transaction with its metadata. The full method surface is published in the Solana RPC documentation.

The appeal is that polling is honest about what it does not know. You asked at a moment, you got an answer for that moment, and the coordinates of the answer are explicit. Nothing arrives out of order, nothing arrives twice unless you asked twice, and a failed call is visibly a failed call rather than a silence you have to interpret.

The cost is arithmetic. Solana targets a 400 millisecond slot, so a poll every five seconds means you are reconstructing roughly a dozen slots per cycle, and every one of them may contain thousands of transactions. Fetching whole blocks at that cadence is a serious bandwidth commitment. Fetching only signatures for a handful of addresses is cheap, but then you need a second call per interesting signature and your request count grows with market activity exactly when you least want it to.

Where polling still wins

Polling is the correct tool for anything where completeness matters more than immediacy: end-of-window reconciliation, backfilling a gap, verifying a figure before you publish it, or auditing what a streaming pipeline claims to have seen. It is also the only route that lets you deliberately ask about the past, which makes it the foundation of every recovery procedure in the latency section.

Route two: subscribing over a WebSocket

A Solana RPC node exposes a PubSub interface over WebSocket alongside its HTTP interface. You open a connection, send a subscription request, and receive notifications until you unsubscribe or the socket closes. The relevant subscriptions for market work are logsSubscribe for transactions that mention a given address, accountSubscribe for changes to a specific account such as a pool vault, programSubscribe for accounts owned by a program, and slotSubscribe for the chain clock. The method list and parameters are documented in the Solana WebSocket API reference.

Subscriptions remove the polling interval from your delay budget, which is the entire point. They also remove your ability to reason about coverage. There is no acknowledgement, no cursor and no replay buffer: if your socket drops for eleven seconds, the events from those eleven seconds are gone, and nothing in the protocol will tell you they existed. Detecting that hole is your job, and it is covered in the note on data gaps and backfill.

The second surprise is that a subscription notification is not a full transaction. A log notification carries the signature, an error field and the array of log lines the program printed. To learn what actually moved you still fetch the transaction, which means a subscription is a trigger rather than a data source. Systems that treat the log text itself as the data are the ones that break the first time a program changes a message string.

Route three: letting a provider call you

Several Solana infrastructure providers will watch addresses on your behalf and post matching transactions to an HTTPS endpoint you control. Helius publishes a webhook product with raw and enhanced payload variants, and QuickNode, Triton One, Chainstack, Alchemy, Syndica and Shyft each publish some combination of RPC, streaming or push products with their own delivery semantics. Read each vendor's own reference for the details, because the guarantees differ and this desk does not rank them.

The trade you are making is control for operations. You no longer run a socket, handle reconnects or scale a consumer, and in exchange you accept somebody else's retry policy. Almost every callback system in this category is at-least-once, which means duplicates are normal and ordering is not promised. A receiver that assumes each delivery is unique and in sequence will double count under exactly the load conditions that make the numbers matter.

Webhooks also introduce an availability coupling that surprises people. If your endpoint is down for a deployment, the provider retries on its own schedule and then gives up. Your pipeline now has a hole whose size depends on a policy you did not write. The design that survives this is covered in webhooks and push data, and it comes down to idempotency keys and a durable queue in front of your processing.

Route four: reading the validator directly

Geyser is the plugin interface a Solana validator uses to hand internal state to an external process. A plugin loaded by the validator receives callbacks as accounts are updated, as slots change status, as transactions are processed and as block metadata is produced. Because these callbacks fire inside the node rather than in a request handler, they represent the earliest moment the data exists outside consensus machinery.

Most people meet Geyser through Yellowstone, an open-source gRPC interface built on the plugin API and published by Triton One. It exposes filtered subscriptions over gRPC for accounts, slots, transactions, blocks and block metadata, and it is the mechanism behind several commercial streaming products. The implementation is public in the Yellowstone gRPC repository.

Two cautions belong on this route. The first is that early does not mean settled: a Geyser stream will show you activity at processed status, on a fork that may never be rooted, so consuming it without commitment logic gives you a fast view of things that might not have happened. The second is throughput. A permissive filter on mainnet delivers the whole cluster, and the bottleneck moves from the network to whatever you wrote to parse it.

Why two dashboards disagree about one token

This is the question that brings most readers to this desk, and the answer is almost never that one of them is broken. Six independent choices produce different totals from the same chain, and a serious tool makes all six deliberately.

• Venue coverage. One pipeline decodes four programs, another decodes twelve. Activity on an undecoded venue is not zero, it is invisible.
• Side selection. Counting the input leg, the output leg or a quote-denominated value of the trade gives three different totals for identical activity.
• Route handling. An aggregated order that touches three pools is one user trade and three pool trades. Both counts are legitimate, and mixing them inflates the figure.
• Commitment level. A counter running at processed includes activity a counter running at finalized has not accepted yet, and occasionally includes activity that never gets rooted at all.
• Window boundaries. A rolling window and a fixed clock-hour window report different numbers at the same instant even with identical inputs.
• Pricing reference. Converting token amounts to a currency requires a price, and price sources disagree, especially in the minutes after a launch.

The practical response is not to hunt for the true number but to state your method next to it. A figure that says which venues, which side, which commitment level and which window is a figure somebody can check. This is the same discipline behind a published account of how volume campaigns are measured: without the method, the total is a claim rather than a result.

A worked example: counting a single route

The arithmetic below is illustrative. It uses round numbers to show how one user action becomes several countable events, not to describe any real trade or any real market.

Suppose a wallet submits a single swap of 10 SOL into a token, and an aggregator splits that order across two pools: 6 SOL through pool A and 4 SOL through pool B. Three defensible totals now exist for the same transaction.

The failure mode is mixing rows. A pipeline that emits an event for the user order and an event for each pool fill, then sums all of them, reports 20 SOL of activity for a 10 SOL trade. That mistake is easy to make when a decoder walks inner instructions without asking whether the outer instruction already accounted for the same value, and it is invisible until somebody compares your total against a venue's own figure.

The fix is a deduplication key chosen before you aggregate anything. A key of transaction signature plus instruction index identifies one countable fill exactly once, whatever path your decoder took to find it. The mechanics of building that key are covered in decoding a swap event.

Choosing a transport for your case

Run this checklist before you write any ingestion code. Every line changes the answer, and the wrong answer is expensive to discover after you have built the aggregation on top of it.

• Is a missed event acceptable, or must the record be complete? Completeness rules out a subscription as the only source.
• Is your delay budget measured in seconds or in slots? Seconds allow polling; slots do not.
• How many addresses are you watching? A single pool suits a log subscription; the whole market suits a stream.
• Can your consumer be down for a deploy? If yes, you need a durable buffer in front of it, whatever the transport.
• Will the figure be published or quoted? Published figures need a finalized reconciliation pass, not just a live counter.
• Do you need history older than an RPC node keeps? If yes, plan for an archival source before you start.
• Are you counting user trades or pool fills? Decide now, because the deduplication key depends on it.

Most working systems end up with two transports rather than one: a subscription or stream driving the live panel, and HTTP calls closing the books. That is not indecision, it is the only combination that gets both immediacy and completeness out of a chain that offers them through different doors.

What to write down before you trust a feed

Before a feed becomes something you make decisions with, write four sentences and keep them next to the code. Which venues does this cover. Which side of a trade does it count. At which commitment level does an event become countable. What happens to the number when the connection drops.

A feed that cannot answer those four questions is not necessarily wrong, but it is not yet evidence. This is the same standard readers should apply to any tool that reports activity back to them, whether that is a chart, an indexer or a Solana volume bot reporting on its own run. A number without a stated method is a number you cannot check, and an unverifiable number is worth less than an honest gap.

The rest of this section takes each transport in turn. If you are deciding between pulling and being pushed to, the comparison in WebSockets versus polling is the next note. If you already have a stream and want to know when its contents are safe to believe, start instead with confirmed versus finalized.

Questions this desk keeps getting