← Back to docs
Detection Methodology

Blockchain Labeling Methodology

This document defines the production methodology used to detect, classify, score, and maintain on-chain flow signals.

Versionv1.1
Last updated2026-02-17
ScopeBTC, ETH, USDT and major centralized exchange routes

Confirmation logic

  • Event status transitions through `detected -> pending-confirmation -> confirmed` states.
  • Confirmation requires block finality plus route-level ownership confidence above minimum thresholds.
  • Reorg safety window is chain-specific and blocks are revalidated before status promotion.
  • Events are invalidated when downstream route checks fail ownership continuity or settlement intent checks.

Threshold logic

  • Base thresholds are defined in native units and USD notional, with both required for trigger activation.
  • USD normalization uses short-window reference pricing and is recalculated at ingestion time.
  • Volatility multipliers widen or tighten trigger bands by asset regime.
  • Threshold overrides are scoped by asset, chain, venue, and transfer class.

Entity clustering

  • Cluster seeds come from verified public disclosures, exchange disclosures, and internally validated labels.
  • Graph expansion uses transaction adjacency, reuse heuristics, and temporal co-movement patterns.
  • Cluster merges require score consensus across multiple independent signals.
  • Low-confidence branches are retained but excluded from high-confidence alert paths.

Exchange labeling approach

  • Exchange labels are split into hot-wallet, cold-wallet, internal-routing, and omnibus classes.
  • Internal exchange edges are maintained to suppress false directional interpretation.
  • Label confidence is versioned and attached to each edge used in route interpretation.
  • Exchange re-maps are deployed only after regression checks against historical event sets.

Update frequency

  • Ingestion pipeline runs continuously with per-chain confirmation windows.
  • Entity and exchange label revisions are released in scheduled batches plus emergency hotfix mode.
  • Scoring and threshold parameters are reviewed weekly and after volatility regime breaks.
  • Historical event backfills are executed when label confidence materially changes.

This blockchain labeling methodology defines how OnChainFlows converts raw transfer activity into flow signals without collapsing nuance into headline transaction size. The framework is explicitly an on chain analysis methodology rather than a single rule set: each stage carries confidence metadata forward so downstream interpretation can condition on evidence quality, not just observed value movement. The objective is to preserve directional signal quality under noisy venue routing, mixed custody patterns, and shifting liquidity regimes across BTC, ETH, USDT, and major exchange corridors.

Method choices in this document are designed for production constraints, not static research snapshots. Confirmation windows, threshold bands, and entity mappings are evaluated as interacting controls. If one control changes, the others are revalidated against replay windows before promotion. This keeps model behavior stable when market structure shifts, and it limits hidden regressions where a harmless label update silently changes event directionality in historical backfills.

Pipeline overview

  1. Ingest raw transactions and normalize asset-denominated values.
  2. Run route decomposition and entity mapping.
  3. Apply threshold and persistence filters.
  4. Score signal quality and publish status updates.

The ingest layer standardizes heterogeneous chain payloads into a chain-aware event model, then attaches synchronized reference pricing so native amounts and USD notional can be evaluated together at trigger time. This dual representation matters because transfer relevance depends on both token unit size and contemporaneous market depth. A large nominal transfer in a low-liquidity window can have higher informational value than a larger notional transfer during deep liquidity conditions.

Route decomposition reconstructs transactional intent from observable hops by modeling direct transfers, exchange ingress or egress edges, and internal venue redistribution patterns. Entity mapping then attaches ownership-confidence scores to each hop candidate, including unresolved branches that remain visible for analyst review. For crypto entity identification, unresolved paths are not discarded; they are retained with explicit uncertainty bands so inference pressure does not force premature label merges.

Threshold filtering is applied after route construction, not before. This ordering avoids suppressing meaningful events where value fragments across multiple linked transfers that only become material after route aggregation. Persistence gates then test whether the signal repeats within asset-specific rolling windows. A one-off transfer can be informational, but repeated directional pressure with coherent ownership continuity typically carries stronger interpretation value for monitoring and escalation workflows.

Scoring converts validated route events into operational priority while preserving status-state semantics (detected, pending-confirmation, confirmed). A status upgrade is not just a size check; it requires finality plus attribution continuity and route-intent consistency. This prevents high-notional but attribution-weak flows from entering high-priority paths solely because they pass nominal thresholds. Detailed coefficients, weighting logic, and escalation bands are documented in the signal scoring framework.

On chain analysis methodology for confirmation and threshold logic

Confirmation logic is chain-specific by design. Finality assumptions differ across monitored networks, so the reorg safety window is parameterized per chain and enforced before a status promotion can occur. During that window, route ownership checks are rerun to detect branch invalidation caused by updated chain state or newly conflicting attribution evidence. Events that lose continuity are downgraded or invalidated instead of silently retained.

Threshold logic uses two concurrent gates: native-unit floor and USD-notional floor. Both must pass for activation, and both are adjusted by volatility-aware multipliers. This reduces distortion during regime transitions where static thresholds either over-trigger in stressed conditions or under-trigger in compressing volatility periods. Overrides are allowed but constrained to explicit scopes (asset, chain, venue, transfer class) so operational exceptions do not leak into unrelated event classes.

A practical example is a high-value ETH transfer into a known exchange hot wallet during abrupt volatility expansion. Base notional may clear immediately, but if route confidence is degraded due to unresolved intermediate hops, the event remains pending-confirmation until ownership continuity recovers. Conversely, a moderate notional transfer repeated across a coherent route in short intervals can escalate faster because persistence and attribution quality jointly support intent interpretation.

The methodology also distinguishes signal generation from analyst interpretation. Signal generation is deterministic and replayable; interpretation can incorporate broader context such as venue inventory cycles. Keeping these layers separate protects consistency and enables controlled policy changes without rewriting historical detection logic.

Edge handling is a major source of reliability gains. Wallet clustering crypto workflows can overfit if merges are driven by adjacency alone, so cluster merges require consensus across independent signals, including temporal co-movement and reuse heuristics. Low-confidence branches stay attached to the graph but are excluded from strict alert paths. This preserves optionality for research while protecting production precision.

Exchange wallet detection and route interpretation

Exchange mapping is maintained as a taxonomy of hot-wallet, cold-wallet, internal-routing, and omnibus classes. The class assignment affects directional interpretation coefficients and controls whether a transfer is treated as potential external flow or operational venue movement. The most common false-positive source in exchange monitoring is internal treasury routing misread as customer-driven inflow or outflow. Classification guardrails and confidence-band policy are maintained in the entity and exchange labeling system.

To reduce that risk, internal exchange edges are first-class graph objects with versioned confidence. Route interpretation uses those edges to collapse same-venue maintenance paths before directional scoring. This is where exchange wallet detection quality directly influences downstream alert quality: if internal paths are incomplete, directionality can flip from neutral to misleadingly aggressive.

Consider a scenario where a venue rotates inventory from cold storage to multiple hot-wallet shards before settlement routing. Without explicit internal-edge modeling, the sequence can appear as repeated external inflow bursts. With internal-route suppression, only the net venue boundary crossings remain directional candidates. This materially lowers alert noise during exchange rebalance windows.

Label updates are released in scheduled batches with hotfix capability for high-impact mapping errors. Every map release is replay-checked against historical event sets so analysts can quantify attribution deltas before and after deployment. If regression thresholds are breached, the release is rolled back or scoped to non-critical classes until confidence recovers.

Because ownership footprints evolve, wallet clustering crypto should be treated as a continuous maintenance process rather than a one-time clustering exercise. Structural changes such as omnibus resharding, custody migrations, and new settlement intermediaries are expected operational events; methodology quality is measured by controlled adaptation speed, not by pretending the graph is static.

Quality controls

  • Deterministic replay on sampled windows.
  • Regression checks after label-map updates.
  • Drift alerts for attribution confidence changes.

Deterministic replay verifies that identical inputs and parameter versions reproduce identical outputs across event status, route composition, and priority bands. Replay windows are sampled across volatility regimes so control performance is evaluated under both normal and stressed market conditions. This catches subtle interactions between threshold multipliers and confirmation windows that are easy to miss in narrow test slices.

Regression checks are run whenever label maps, threshold parameters, or scoring coefficients change. The check suite tracks not only aggregate alert counts, but also route-level directional flips, confidence downgrades, and time-to-confirmation shifts by asset and venue. A release can pass headline metrics while still introducing harmful micro-regressions in specific exchange corridors; those are blocked before promotion.

Drift monitoring focuses on confidence movement, not only volume movement. Sudden growth in low-confidence branches, repeated invalidations after pending state, or widening disagreement between independent ownership signals are treated as operational warnings. These signals often precede visible performance degradation and can indicate external behavior changes that require targeted mapping updates.

Operational governance is enforced through versioned artifacts and explicit release policy. Each production update is tagged with parameter snapshots, label-map versions, and replay evidence so historical event interpretations remain reproducible. Emergency hotfixes are allowed for data-quality incidents, but they still require post-release replay and documented rationale. Release timing and control workflow align with the update cadence and change-control policy.

For analysts, interpretation discipline is as important as detection quality. High-confidence events support directional inference; medium-confidence events are better treated as contextual pressure unless corroborated. That distinction is central to reliable crypto entity identification under changing market structure. In practice, this framework keeps attribution accuracy and response speed aligned while preserving transparent auditability across the full lifecycle.

FAQ

What condition promotes an event to confirmed status?

Finality plus route validation and ownership confidence checks must all pass.

Can thresholds differ by chain and venue?

Yes. Thresholds are parameterized by asset, chain, venue, and transfer class.

How are low-confidence labels handled?

They remain available for analysis but are excluded from high-confidence alert generation.

How often is methodology tuned?

Routine tuning is weekly, with additional updates after regime or data-quality shifts.

Implementation step

Put this logic into production alerts.

Use the documented rules in your live monitoring workflow to capture high-signal moves without rebuilding the stack from scratch.