FlowLens
About the research desk
FlowLens is an on-chain intelligence hub operated from Mountain View, California. We publish tooling and research for analysts who need to trace wallet behavior and token flows, and we are explicit about the limits of what public ledger data can support. This page explains who produces the work, how it is reviewed, and what standards apply.
Small on purpose
Methods stay consistent when the same few people review each other's work every week.
FlowLens is run by a small research team working on blockchain data analysis, wallet labeling, and token flow tracing. The office is at 2455 Bennett Avenue, Suite 400, in Mountain View, California 94043, and the research desk can be reached at [email protected] or +1-650-552-9923.
Focus
On-chain research built around wallet behavior analysis, token flow analysis, and transaction records that can be re-checked against the same source later.
Team size
Deliberately small. A handover across ten people would blur how a label was applied and which window a trace used, so the desk stays narrow and the review loop stays tight.
Reach
Methodology questions, corrections, and collaboration notes all land with the same team that writes the analysis. There is no separate public-relations layer.
From question to published note
A note starts with a question worth documenting, not with a data pull in search of a headline. The analyst defines the window, collects the activity, applies labeling and clustering, and writes the method alongside the finding. Drafts include the parts that did not resolve.
The question
The window, the chain, and the addresses are fixed before any data is collected, so the scope cannot drift toward whichever result looks most interesting.
Collection and labeling
Activity is gathered for that window, then labeled and grouped. Wallet clustering groups addresses only where the evidence supports a shared controller; uncertain groupings stay marked as uncertain.
Draft with the method
The method is written next to the finding, not after it. Drafts keep the parts that did not resolve, because a dead end often explains why a conclusion stays narrow.
Second review
Before publication, a second analyst checks the labels, reruns a sample of the traces, and challenges any conclusion that goes past the evidence. Notes are not published until that review is complete.
A note that cannot survive being reread a month later did not meet the standard.
Method notes in the guidesThree standards apply to everything we publish. They are written here as rules rather than values, so a reader can check a note against them.
Observation, inference, attribution
Every claim is sorted into one of the three. What a transaction shows is an observation. What it likely means is inference. Who controls an address is attribution, and it needs the strongest evidence of the three.
Stated confidence
Confidence is stated rather than implied. If a cluster rests on a single heuristic, the note says so, and a reader can decide how much weight to put on it without guessing.
Visible corrections
Corrections appear in the note rather than being applied silently. A revised trace or a changed label is dated and left in place, so anyone who cited the earlier version can see what moved.
What stays out
We do not publish price predictions, and we do not recommend tokens or wallets. A note that reads as a trading suggestion has failed its own review, and it comes down.
The Wallet Tracker, Wallet Clusters, and AI Activity Summary exist to shorten the mechanical parts of on-chain research: pulling activity, grouping addresses, and producing a first-pass summary. They are not designed to produce conclusions. The judgement stays with the analyst.
Pull the activity of a set of addresses into one ruled view. The tracker keeps the raw rows in front of you, so a label applied in the tool can be checked against the transfers that produced it rather than trusted as a finished answer.
Groups addresses that share evidence of one controller. Each cluster carries the reasoning that produced it, and a thin cluster is shown as thin instead of being flattened into a single confident label.
Summarizes what the transactions show as a starting point. It is expected to be checked against the raw data before anything is built on it, and it is never the last word on an address.
No single source covers the whole picture, so our methods reference outside products where they fit. Each name below appears in the research because it answers a specific question better than the alternatives we have tried. None of them is a FlowLens partner, and none of them endorses this site.
Nansen
Labeled wallets. Used when an address already carries a public identity and we need to check that identity against the trace.
DeFiLlama
DeFi market structure. Used to place a flow in context, so a single wallet movement is read against the size of the pool it entered.
CryptoQuant
Exchange flows. Used where the question is whether activity is moving toward or away from venues, and by how much.
CoinGlass
Derivatives data. Used when a spot movement needs to be read next to positioning on futures markets.
Flipside
Query work. Used to run the same question across a full history rather than a hand-picked sample of addresses.
Elliptic
Risk and investigations. Used where a trace touches addresses that carry an external risk classification.
GMGN
Supported as a third-party analytical data source. Where its coverage helps a question, it is named in the method next to the other references. It is not a FlowLens partner, and FlowLens does not endorse or operate it.
We do not provide investment, legal, or tax advice.
We do not sell trading signals or run paid rankings of tools or tokens.
We do not accept placement in research notes, and no source pays for a mention.
If a page on this site could be read as recommending a trade, that is a failure on our part, and we would want to hear about it. Send the address, the note, and the evidence in one message.
Contact the research desk
FlowLens is designed to add data sources and analytical modules over time. When a new chain or source is connected, the coverage and freshness limits are documented before it becomes part of a default workflow. Modules ship with a method note first, so a reader can tell what changed and when.
That approach keeps the site honest as it expands, and it keeps older notes comparable with newer ones. A method note written last year should still explain the shape of an analysis run today.
New source
Coverage, update frequency, and what it does not see are written down before it feeds any default view.
New module
Ships with a method note that explains what it measures and where its confidence ends, before it appears in day-to-day work.
Older notes
Kept in the library unchanged, with a visible note where a later source has added context or moved a figure.
Coverage limits documented before a source goes live
Method first, then defaults
Four routes into the site, ordered by how often a reader needs them after leaving this page.
Research
Published notes with their windows, labels, and limits attached to each finding.
Read the library
Wallet Intelligence
Wallet behavior analysis, clustering results, and the reasoning behind each grouped address.
Open wallet intelligence
Token Flows
Inflow and outflow rows for the tokens we follow, with exchange movement read alongside venue context.
Trace token flows
Guides
Method notes and practical walkthroughs for the parts of blockchain transaction analysis that reward patience.
Read the guides
The questions that arrive most often at the research desk, answered in the same terms we would use in a note.
Labels are working conclusions, not permanent facts. When new transfers connect an address to a different controller, the label moves, and the earlier note keeps its original wording with a dated correction beside it.
It depends on how many independent signals point the same way. A cluster built from one funding path is weaker than one confirmed across repeated interactions, and each cluster states which signals it used.
No. It summarizes what the transactions show, and it is expected to be checked against the raw data before anything is built on it. Treat it as a first pass that saves the mechanical reading, not as a conclusion.
The address, the note it appears in, and the evidence in one message. Corrections are read before general inquiries, and a clear evidence trail usually shortens the turnaround.
Corrections, methodology questions, and collaboration inquiries all go to the same place. The contact page explains what to include, and it helps to send the address, the note, and the evidence in one message. We read everything, and we reply to corrections first.
The desk is open Monday through Friday, 9:00 AM to 6:00 PM Pacific Time. Written requests reach the team faster than a phone call, because the note and the evidence can travel with them.
Office
2455 Bennett Avenue, Suite 400
Mountain View, CA 94043, USA
Hours
Monday–Friday, 9:00 AM – 6:00 PM Pacific