Skip to main content

What are the Behavioral Flow products?

A single transfer cannot reveal whether it is an invoice settlement or a marketplace payout — amount bands cannot distinguish a 40kinvoicefroma40k invoice from a 40k payout. What can distinguish them is the shape of a sender’s activity over time:
  • Payouts are a star — one platform pays many recipients, in bursts. Measured per (payer, day) in stablecoins.intelligence.merchant_payout_runs.
  • AP/AR settlement is a line — one business pays another, repeatedly, over months. Measured per (payer, payee) relationship in stablecoins.intelligence.apar_flows.
Both are estimated behavioral activity — the models report measurable shape (fan-out, recurrence, cadence, ticket uniformity), never inferred intent. “Invoice”, “salary”, “affiliate” are interpretations you apply; the data gives you cadence and ticket bands. Coverage: ethereum, tron, base, polygon, arbitrum, solana, bsc, plasma, stable, tempo — full history from 2020.
Consumption rules. Four rules keep queries honest:
  1. Never sum the identified and estimated payout populations — labeled platforms are identified payment activity; behavioral detections are an estimate that may include unlabeled exchange withdrawal wallets.
  2. Consume per chain — per-chain classifier calibration is ongoing; cross-chain totals are not supported.
  3. Filter is_established_relationship = true for any published AP/AR figure — the rest is discovery data.
  4. Payouts run from exchange accounts live in exchange flows, not here.

merchant_payout_runs

Purpose: every day on which a payer disbursed to ≥ 10 distinct real recipients (or ≥ 5 in a single batching transaction), with platform identity, scale, timing, and ticket-uniformity features. DeFi routers, infrastructure sprays, bot-farm recipients, and platform-internal sweeps are excluded by construction.

Monthly payout volume, populations separate

Payroll-shaped runs (uniform tickets, weekdays, human hours)

apar_flows

Purpose: every business-to-business transfer between wallets with an ongoing relationship, classified point-in-time — each transfer carries its pair’s trailing-180-day statistics as of that moment, so historical analysis has no look-ahead bias. Both sides must type as Business, the sender must not be a payout platform, and protocol-context legs (DEX, lending, bridge), MEV, and bot counterparties are excluded.
Cadence is measured, not assumed. Among recurring pairs eligible under this model, observed transfer gaps are ~3–10 days — a statement about the captured population only. Present relationships by their measured cadence and ticket band rather than assuming invoice cycles.

Published AP/AR-like estimate, monthly by ticket band

One relationship’s full history

Top receiving entities of established settlement