Watching Solana volume as it happens
Flow Monitor is a reading desk for live Solana activity. Not which token is moving: where the number came from, how many hops it crossed, what the feed is allowed to promise at each one, and what it means when the panel goes quiet.
mechanisms, not measurements · every figure is a constant or labelled arithmetic
The four data paths
Every live Solana feed you will ever read is one of these four, or a stack of them. The choice decides your delay, your failure mode and what you can honestly claim the number represents.
Ask on a timer
You call an RPC method on a loop and keep whatever the answer was at that instant. Simple, bounded, and blind to everything that happened between two calls.
Subscribe to a socket
The node pushes a notification when something you asked about happens. Lower delay than a poll, and nothing is replayed to you if the connection drops.
Let a provider call you
A hosted service watches addresses and posts to your endpoint. You give up control of retries and ordering, and you gain a pipeline you do not run.
Read the validator itself
A Geyser plugin receives account, slot and transaction updates from inside the validator process, before any RPC layer shapes them into a response.
Monitor notes
Four notes that answer the questions this desk is asked most: where the number comes from, when it is safe to believe, how to read it out of a transaction, and why the screen is behind.
Real time Solana volume data
Four routes carry a live volume number, and each one hands you a different promise. Start here if two dashboards are showing you two different figures for the same token.
SourcesRead the noteConfirmed versus finalized
Three commitment levels, three different meanings of the word real. Which one belongs in a running counter, and which one belongs in a number you publish.
LatencyRead the noteDecoding a swap event
Solana has no EVM-style event log. The trustworthy reading of a swap comes from balance deltas in the transaction meta, not from a string a program printed.
Building a viewRead the noteWhy dashboards lag
Six places a live chart can wait before it reaches you. How to work out which stage owns your delay instead of blaming the chain for a cache.
LatencyRead the noteThree sections, three questions
Where the data comes from, how far behind it is, and how you assemble the pieces into a view you would put your own name on.
Sources
Transports and their guarantees: request-response, subscriptions, provider callbacks and validator-level streams.
- Real time Solana volume data
- WebSockets versus polling
- Log subscriptions explained
- Webhooks and push data
Latency
Confirmation semantics and pipeline delay: what the chain owes you, and what your own stack added on top of it.
- Confirmed versus finalized
- Why dashboards lag
- Data gaps and backfill
Building a view
From a raw transaction to a number on a panel: decoding, aggregation windows, deduplication and alert design.
- Decoding a swap event
- Building a live volume view
- Alerting without noise
The stages a number passes through
Nothing on this table is a measurement of your endpoint. It is the ordered list of states a piece of Solana activity occupies on its way to a chart, so that when the panel is stale you can name the stage instead of guessing at it.
The first three rows are protocol behaviour and are the same for everyone. The last three belong to whoever built the pipeline, which is usually where the delay you are complaining about actually lives.
Open the latency section| Stage | What has happened | What you can rely on |
|---|---|---|
| Slot | A leader had its turn to produce a block; the target slot duration on Solana is 400 milliseconds | Slot numbers advance whether or not a block was produced in each one |
| Processed | Your node has executed the block and can answer questions about it | Nothing about the cluster; the block may still sit on a fork that loses |
| Confirmed | The block carries a supermajority vote from the cluster | Practically stable for a live counter; still not the strongest promise available |
| Finalized | The block is rooted, with the lockout depth of 31 confirmed blocks on top of it | The strongest commitment an RPC node offers, and the slowest to arrive |
| Indexed | A pipeline has decoded the transaction into rows it can aggregate | Only what the decoder understood; unrecognised programs are silently missing |
| Rendered | An aggregate has passed through cache and transport to a screen | Whatever the cache policy allows, which is rarely published anywhere |
When watching turns into operating
Most readers arrive here because a chart disagreed with the chain. Some of them leave because they no longer want to watch a market, they want to act inside it, and that is a different discipline with different failure modes.
This desk does not run execution software and does not publish results from any. What it can do is name the line where reading stops and operating starts, because the two need different tools and different guarantees.
- Reading needs completeness: every swap counted once, gaps detected and refilled.
- Operating needs landing: a transaction that reaches a leader while the quote is still true.
- Reading tolerates a second of delay; operating spends its whole budget in that second.
- Reading can be rebuilt from history; a missed execution window cannot be replayed.
See live volume tooling
If the next question is what a hosted, multi-venue tool does with the same stream, the console referenced across this site is a third-party product that routes activity across Solana venues. Look at it as an example of the operating side, not as an endorsement.
See live volume toolingThird-party tool, new tab. This desk does not operate it and does not verify its output.
How this desk tests a data source
Three habits decide whether a page here is worth reading. They also explain why you will not find a latency leaderboard on this site.
Read the specification, not the marketing
Method names, parameters, commitment defaults and delivery guarantees are taken from protocol documentation and from the provider's own reference. Where a behaviour is version-dependent or marked unstable, the page says so instead of rounding it off.
No invented timings, ever
Latency depends on your node, your region, your plan and the minute you asked. This desk publishes no measured milliseconds. Numbers here are protocol constants, values published by the operator of a service, or arithmetic marked as illustrative.
Name providers, do not rank them
Vendors are named when naming them is the only accurate way to describe a mechanism, and their capabilities are described from public documentation. There is no scoreboard, no pricing table and no affiliate ranking. Read the editorial policy for the full rule set.