Distinct payer count

What it measures

Distinct from_wallet payers in the last 30 complete UTC days before the current partial day. For the validation recorded in the source note, the window is 2026-05-09T00:00:00 <= timestamp < 2026-06-08T00:00:00, with chain='base' AND amount_usdc BETWEEN 0.0005 AND 5.

How it is produced

The canonical query fixes the network, amount band, and complete-day window before counting distinct payer strings. Supporting queries compare raw and lowercased payer strings and test whether any recipient dominates distinct payer reach.

Canonical query

WITH w AS (
  SELECT from_wallet, to_wallet
  FROM payments
  WHERE chain='base'
    AND amount_usdc BETWEEN 0.0005 AND 5
    AND timestamp >= '2026-05-09T00:00:00'
    AND timestamp < '2026-06-08T00:00:00'
),
total AS (
  SELECT COUNT(DISTINCT from_wallet) AS distinct_payers
  FROM w
)
SELECT distinct_payers
FROM total;

Case-normalization check

WITH w AS (
  SELECT from_wallet
  FROM payments
  WHERE chain='base'
    AND amount_usdc BETWEEN 0.0005 AND 5
    AND timestamp >= '2026-05-09T00:00:00'
    AND timestamp < '2026-06-08T00:00:00'
)
SELECT
  COUNT(DISTINCT from_wallet) AS distinct_raw_from_wallet,
  COUNT(DISTINCT lower(from_wallet)) AS distinct_lower_from_wallet
FROM w;

Recipient concentration check

WITH w AS (
  SELECT from_wallet, to_wallet
  FROM payments
  WHERE chain='base'
    AND amount_usdc BETWEEN 0.0005 AND 5
    AND timestamp >= '2026-05-09T00:00:00'
    AND timestamp < '2026-06-08T00:00:00'
),
total AS (
  SELECT COUNT(DISTINCT from_wallet) AS distinct_payers
  FROM w
),
by_to AS (
  SELECT to_wallet, COUNT(DISTINCT from_wallet) AS payers
  FROM w
  GROUP BY to_wallet
)
SELECT
  to_wallet,
  payers,
  ROUND(100.0 * payers / (SELECT distinct_payers FROM total), 6) AS pct_of_distinct_payers
FROM by_to
ORDER BY payers DESC
LIMIT 10;

Limits and assumptions

• This is a gross count of every payer address in the band. No quality, deduplication, or classification filter is applied.
• It is not a clean-payer count; it includes wash-flagged and facilitator-mediated rows.
• The count uses distinct raw from_wallet values. The source validation found the raw and lowercased counts identical for this window.
• The result depends on tracker completeness and the exact 30-day UTC window.
• No hand-maintained address list is used. The static elements are the chain, micro-band, and time-window definitions.

How to refute this

1. Re-run the canonical SQL and get a different distinct payer count.
2. Show that lowercasing, address validation, or null filtering changes the distinct count.
3. Show tracker gaps or duplicated records in the 2026-05-09 to 2026-06-07 window.

Last validated

2026-06-08