Flow Monitor writes about how live Solana data is produced and delivered. The rules below govern every page on the site. They are published so that a reader can hold the desk to them, and so that a claim can be judged by its sourcing rather than by its tone.
Sourcing
Claims about protocol behaviour come from Solana's own documentation and from the implementation it describes. Claims about a specific service come from that operator's published reference. Where a page explains a mechanism, the reader is pointed at the primary source rather than asked to accept a summary, including this site's summary.
Where documentation and observed behaviour appear to disagree, the page says so and describes both. Where a behaviour is version-dependent, marked unstable, or disabled by default on most endpoints, that condition is stated next to the claim rather than left for the reader to discover. A mechanism this desk has not verified against a primary source does not get described as if it had been.
Numbers
A number may appear on this site under three conditions and no others.
- Protocol constants. Values fixed by the network or its consensus implementation, such as the target slot duration or the lockout depth required for a block to be rooted. These are stated with what they mean and where they come from.
- Values published by the operator. Limits, quotas and guarantees published by whoever runs the service being described, presented as their published figure and not as an independent measurement.
- Labelled illustrative arithmetic. Worked examples shown in full, using round numbers, explicitly marked as illustrative, so a reader can substitute their own inputs. These describe no real market, wallet, endpoint or deployment.
Specifically banned: measured latency figures for any provider or endpoint, throughput benchmarks, performance comparisons, and any statistic presented without a source. Latency depends on your node, your region, your plan and the minute you asked, so a published figure would be a fact about somebody else's afternoon presented as guidance.
Naming providers
Infrastructure providers are named when naming them is the only accurate way to describe a mechanism. Their capabilities are described from public documentation. They are not ranked, scored, compared on price, or presented as recommended. No provider named on this site has paid for or reviewed its inclusion.
The same applies to protocols, venues and programs. A venue is named because a decoder has to know about it, and a program identifier appears because a pipeline needs it. Every identifier published here carries an instruction to verify it against the project's own documentation before use, because programs are deployed, migrated and superseded.
Fabrication
Nothing on this site is invented. No statistics without a source, no review counts, no aggregate ratings, no testimonials, no case studies, no wallet numbers, no profit or loss figures, no named individuals with credentials that do not exist. Articles are attributed to The Flow Monitor Desk, which is an editorial identity and is described as one on the about page.
Publication dates are the real build date and revision dates are the real revision date. Nothing is backdated to look established, and nothing is refreshed to look current without an actual change to the page.
Commercial links
This site carries commercial links to a third-party volume console. They appear in the header, in the hero and one contextual block on the home page, at the end of each article, and occasionally inside a paragraph where the subject genuinely matches. They open in a new tab.
The desk does not operate that product, does not verify its output, and does not use figures from it as evidence for any claim on this site. An in-body commercial link is only placed where the surrounding paragraph was already about the thing the linked page answers; where no paragraph fits, no link is added. Several articles carry no in-body commercial reference for that reason.
Links to third-party technical documentation are editorial rather than commercial. They exist to let a reader check a claim at its source, they carry no affiliate parameters, and they are chosen for accuracy rather than for any relationship with the site they point at.
Scope
This desk covers data mechanics. It does not cover, and will not publish on, which token to trade, how to read a chart as a market signal, whether a project is legitimate, or the identity of anyone behind an address. Those questions are outside the competence this site claims, and writing about them would undermine the part it can stand behind.
Nothing here is financial, legal or tax advice. Descriptions of automation tooling explain what a class of software does, never that a reader should use it.
Corrections
Errors are fixed on the page rather than in a note somewhere else, and the revision date updates when they are. A correction that materially changes the meaning of an article is described on that page so a returning reader can see what moved; a typographical fix is made silently.
The fastest route to a correction is the contact page, with the page name, the sentence or table row in question, and a source that contradicts it. Corrections arriving with a primary source are prioritised, because they can be verified immediately rather than researched from the beginning.
Review
Technical pages are reviewed when the mechanism they describe changes, when a reader reports a discrepancy, and on a periodic sweep of the whole site. Program identifiers, method names and documented defaults are the fields most likely to age, and they are checked first. Where a page has been reviewed and left unchanged, the revision date still moves, because a verified date is more useful to a reader than a frozen one.