Methodology

Data sources & pipeline

On-chain transfers come from public blockchain indexers. On EVM chains we read ERC-20 token transfers — on Ethereum from Etherscan V2 when our key is configured and from Blockscout otherwise, on Arbitrum from Blockscout; native ETH and POL transfers are not read yet. Base is not being collected at the moment. Since early October, Blockscout's public Base explorer has refused our requests. Separately, Blockscout publishes that access to its API for Base requires a paid plan. We have not taken one, so Base wallets are not read: their pages show when each was last read, no wallet report is offered on them, and reports on Base tokens are refused before any credit is taken. Solana: native SOL and SPL token transfers, from Helius, read only from transactions in which the wallet's own address appears; SPL tokens received on one of its token accounts without it (typically exchange withdrawals and payments) are not read yet. Bitcoin: native BTC transfers, from public Esplora instances. Historical daily prices come from CoinGecko. The ingestion pipeline runs hourly and refreshes a bounded slice of the tracked universe on each run — wallets take their turn, with no guaranteed fixed interval per wallet. Each run chains: transfers → daily-price valuation → FIFO position cycles → metrics → score → whale event detection → alert evaluation. Tokens without reliable price coverage are stored but excluded from PnL — we never value a position by guesswork.

Smart Money score (0–100)

Seven factors, each scored 0–100 from observed history, combined by fixed weights:

The score describes past behavior only. It never claims or predicts future performance.

Confidence & shrinkage

Confidence = closed positions ÷ 30, capped at 100%. The final score is pulled toward a neutral 50 in proportion: score = 50 + (weighted − 50) × confidence. A lucky 3-trade wallet cannot outrank a 100-trade track record. Everywhere a score appears, its confidence band appears with it:

• High confidence — 18+ closed positions (≥60%).
• Estimated — 6–17 closed positions (20–59%).
• Insufficient data — fewer than 6 closed positions: the score is mostly neutral filler, not evidence.

The custody rule

Exchange and contract wallets move aggregated customer funds. Their deposits and withdrawals are not trades, so we never rank them as traders, never show them a win rate or ROI, and exclude their holdings from token concentration risk (customer funds ≠ investment ownership). They are monitored separately as exchange-flow intelligence.

Whale event detection

Events are automated observations of past transfers crossing fixed USD thresholds — configurable per chain and per token. Accumulation and distribution are net flows over a trailing 7-day window. Transfers without price coverage never produce events.

A one-sided transfer is never labelled a "buy" or "sell" — transfer-level data cannot distinguish a purchase from an internal move. We DO emit Buy and Sell events only when a single transaction hash carries both legs of a swap (a token out and a different token in): the transfer pattern itself is the evidence, no router calldata needed. These are labelled "observed swap" and require the swap to clear the whale-scale value bar ($50K+) — small rotations are not shown. Every such event links to its transaction on the block explorer.

Token structure scores

Holder risk, liquidity, and overall health are computed from public holder data and market data. Exchange custody wallets are excluded from concentration and reported separately. When an input is missing, the component is marked unavailable and excluded from the average — a token with thin data shows "insufficient data", never a fabricated bad (or good) score. Every score lists the factors that created it, on the page where it appears.

AI research reports

Reports are generated from our own ingested data — curated, truncated context, with missing data stated as missing. Two guardrails apply: a system prompt that forbids recommendations, predictions and profit claims, and an automated post-generation validator that rejects any output containing prohibited wording before it is stored. A report that fails validation twice is discarded, not published.

Known limitations

• Coverage is selective, not exhaustive: we track a capped set of wallets — selected addresses plus counterparties discovered automatically in the past (no new one is admitted until it can be classified) — refreshed in rotation, not every address on-chain. On EVM chains only ERC-20 token transfers are read, one per transaction; native ETH and POL transfers are not yet, and neither are internal transactions or the other ERC-20 transfers of the same transaction. On Solana, only transactions in which the wallet's own address appears are read: SPL tokens received on one of its token accounts without it (typically exchange withdrawals and payments) and transfers signed by a delegate are not read yet, and transaction types Helius does not parse may be missing.
• Data freshness is bounded by the ingestion rotation: the cron runs hourly and refreshes a bounded slice of the tracked universe, so wallets take their turn rather than each being polled continuously — we do not promise a fixed refresh interval per wallet. Where that rotation actually stands right now is published in Data health, alongside provider rate limits.
• Realized metrics depend on price coverage; thin or new tokens may be excluded from PnL.
• Wallet labels come from public information and are best-effort; entity attribution can be wrong.
• Historical behavior, however well measured, does not predict future results.