# Blockchain Flow Map methodology v1

By Jake Percy. The dashboard is at https://flows.jakepercy.com/ and its plain-text description is at https://flows.jakepercy.com/llms.txt.

An address does not reveal its owner's physical location. Endpoints represent evidenced jurisdiction associations of specific operating entities, not customers, beneficial owners, users, IP locations or headquarters by default. Borders are cartographic references and do not assert sovereignty.

Observed value is all priced qualifying allowlisted USDT/USDC transfer logs in the captured dataset. Amounts retain atomic strings; USD is derived from a time-stamped price. Unpriced events are counted separately, never valued at an assumed peg. Deduplication uses chain + transaction hash/signature + event/instruction index; a transaction may contain many transfers.

Adjusted value excludes confirmed mint/burn, bridge legs, self/same-entity transfers, exchange treasury, bots and infrastructure. Unresolved and DeFi activity is retained and separately identified: this is a candidate economic activity estimate, not proof of payment. Classification is versioned.

Mapped value requires included adjusted events with two specific jurisdiction associations, different jurisdictions, at least HIGH confidence (score >= .80), inspectable source/evidence, and verification within 180 days. MEDIUM and UNKNOWN never draw a route. Scores are ordinal analyst assessments, not calibrated probabilities. The live build accepts only decoded onchain records with real registry evidence. Headquarters alone are insufficient.

Global coverage = mapped cross-border USD / adjusted USD. Domestic, unresolved and unknown geography remain in the denominator. Country coverage = mapped inbound + outbound / adjusted value touching at least one admissible endpoint in that country. Unknown endpoints cannot enter a country's denominator. This describes dataset coverage, not national payment coverage.

Ranking uses log USD value, recency, confidence and anomaly, with 15% incumbent hysteresis. The renderer retains objects and interpolates width/opacity. Width uses bounded log10 USD. Color shows the dominant value-weighted chain, asset or confidence category; inspection shows all components. Particle speed, the short comet tail behind each particle and arc height carry no quantity, on the globe or on the map (the tail only repeats the direction); the brighter end of a line is its destination. Anchors are jurisdiction references, not cities. The globe's dotted land is cartography only (dot density carries no data) and its day/night shading is the real solar position at the current UTC time, astronomy rather than data. Up to 32 routes are drawn on desktop and 24 on phones and tablets.

Jurisdiction activity glow (client build): a jurisdiction anchor is lit in proportion to adjusted value touching at least one admissible endpoint there (the same known-endpoint denominator used for country coverage). A glow is one-sided evidenced activity and never draws or implies a route; routes still require two admissible endpoints in different jurisdictions. On the globe the same value also lights a thin vertical beam and brightens the jurisdiction's land dots; these are the same encoding, not additional ones.

Inferred deposit addresses (client build): exchange customers deposit to per-customer addresses that the exchange sweeps into a labelled hot wallet. Within the retained buffer, an unlabelled address whose only outgoing transfers go to one registry entity, after receiving from outside that entity, and which forwarded at least 80% of what it received, is treated as that entity's deposit address. Such evidence is marked INFERRED in its category, source and note, cites the sweep transaction, carries HIGH confidence at the minimum admissible score, and is never persisted. It is inference from on-chain behaviour, not a published label; inspect any route to see which endpoints rest on it.

Client feeds (client build): reading every stablecoin transfer costs a visitor about 23 MB an hour on Ethereum and 100 MB on Base, so each chain's settlement feed requests only transfers with an evidenced address in one of the two indexed positions of the ERC-20 Transfer event. A corridor needs an evidenced wallet at each end, and the deposit sweeps inference rests on are funded by an exchange hot wallet, so both legs still match; nothing that can draw a route is lost. The client's observed, adjusted and classification totals therefore describe evidenced settlement, not all on-chain activity, and are labelled so. To state how small the evidenced share is without extrapolating, a small unfiltered slice of chain time is read periodically and accounted identically; it is reported as an exact sum over the sampled seconds and never scaled up. Backfill chunks that a public endpoint fails to serve are counted and reported as partial coverage with a stated start time; they never become silent gaps.

Derived cross-chain evidence (client build): a public name tag read on Etherscan is evidence about Ethereum. A plain key-controlled account's address derives from its key, so the same key holder controls that address on every EVM chain. Where eth_getCode returns no contract code for a labelled address on Ethereum and on another EVM chain the build reads (Base, Arbitrum, Avalanche, Polygon or Optimism), the Ethereum label is reused there as DERIVED evidence: HIGH confidence at the minimum admissible score, never VERIFIED, with the derivation and both code-probe results stated in the note. Contract addresses never derive, because the same address on another chain may be an unrelated deployment. A first-party label read on that chain's own explorer always takes precedence, and only a first-party label may anchor a deposit-address inference; derived evidence never does. Anyone can send to an address on another chain without the owner's cooperation, so derived evidence is weaker as a receiver than as a sender. Tron is not an EVM chain in this sense and nothing derives onto it: every Tron address carries the public name tag Tronscan, Tron's own explorer, shows for it, and Tronscan's risk flags never admit an address.

Allowlisted contracts: a stablecoin contract is admitted only where its own issuer publishes it - Circle's USDC contract registry or Tether's supported-protocols page. That is what makes "USDC" and "USDT" here claims about a Circle or Tether liability rather than about any token using the ticker. A bridge-issued pegged token is therefore excluded even where it dominates a chain's volume: BNB Smart Chain's Binance-Peg BSC-USD is a Binance liability, so BNB Chain is not read at all, and on Polygon only Circle-issued USDC is read, never the bridge-issued USDT (decided 2026-09-25). Optimism is read for Circle-issued USDC only, because Tether publishes no USDT contract for it. Tron is read for Tether's USDT only; Circle no longer issues USDC there. Decimals are declared per contract, never assumed.

Recorded history and the longer windows (client build): with no server, the 5M and 1H windows are computed from the transfers the page holds in memory, and nothing else would survive a reload. So each completed 15 minutes is reduced once, per chain, to the accounting it supports - totals, corridors, jurisdictions, classifications and the unmapped aggregate - and kept in that visitor's own browser. It is never uploaded, never shared between visitors and never merged with anyone else's; it is one browser's record of what it watched. Sealing uses the same accounting function a live window uses, over a half-open span, so consecutive spans tile the timeline exactly once and a 24H total from 96 spans equals the total the raw transfers would give. Coverage is measured rather than assumed: a feed records only the block ranges it actually read, a failed chunk lowers the coverage of the spans it touches, and a window's coverage is that of its least-covered chain. A window is not offered until at least 80% of it has been observed, because a partly watched day is a measurement of part of a day and presenting it as "24H" would invite reading it as the day's settlement. Sealed spans keep no per-transfer detail, so a long window carries no transfer list, no counterparty ranking and no per-endpoint evidence cards; a stored citation would also freeze evidence the registry may since have corrected. A span sealed under an earlier registry attributed fewer wallets than the current one would, which is a true property of that observation, so such spans are kept and the mixed span is disclosed. The unfiltered denominator sample is not sealed: it describes recently read chain time, not a whole day.

Baselines use preceding same-duration windows from that recorded history; four are required, and each must clear the same coverage bar as the window on screen, so a stretch the page was not open for cannot read as a collapse in volume. The prior windows are anchored to the last sealed quarter-hour, so each is tiled by whole spans and up to one span of not-yet-sealed time separates the last of them from the window on screen; the 1H window has baselines on the same terms, the 5M window none. Because the anomaly term enters the ranking, the order of the leading corridors on 1H can differ between browsers with different recorded history. A corridor that did not trade in an observed window contributes a real zero, which is not the same as a missing sample. Ratio = current / mean; z-score uses sample standard deviation and is omitted when the samples have no spread. Unusual activity is not evidence of illegality.

Feed LIVE requires configured streams to be fresh and caught up. A browser connection alone is not proof of health. Unknown attribution yields an empty map even when onchain data flows.