Define the claim before calculating the total
Agent-payment research becomes misleading when a visible number receives a stronger label than its evidence supports. An observed transfer total is not automatically agent spending. An active wallet is not automatically a customer. A settled payment is not automatically a useful outcome.
The practical solution is to define each metric before collecting its numerator. State its unit, inclusion rule, evidence requirement and coverage window. Readers should be able to reproduce the result without guessing what the chart's title means.
Choose the unit you actually observe
A blockchain transaction, a token transfer, an HTTP request and a service purchase are distinct units. Tempo supports multiple transfers in one transaction, as its payment guide demonstrates. Meanwhile, x402 separates requesting a resource, payment verification, service work and settlement in its payment flow. Counting intermediate steps together creates an inflated activity number.
Use a transaction hash plus network to deduplicate chain transactions. Use an event identifier when counting transfer legs. For service purchases, use a verified order or request identifier with a documented mapping to its payments. One identifier rarely works across every layer.
Decide how to handle repeated requests, failed attempts, refunds and multiple payments for one order before comparing providers or periods. Maintain both gross and net quantities when refunds are reliably linked. If they are not linked, report that limitation instead of guessing.
Keep a small set of clearly defined metrics
| Metric | What it can establish | Important limit |
|---|---|---|
| Retained transactions | Unique observed chain operations | Depends on collection coverage |
| Known transferred quantity | Sum for one contract under a stated rule | Unknown values and intermediate legs need treatment |
| Initiating addresses | Distinct observed sender accounts | Does not count people or agents |
| Linked service payments | Payments matched to identified requests or orders | Requires additional service evidence |
| Validated outcomes | Linked purchases passing a stated result test | Cannot be inferred from settlement |
Keep agent attribution separate from payment attribution. A seller receipt may establish what was purchased without establishing who operated the buyer. Likewise, knowing that software controlled a wallet does not show which task a transfer served.
The AP2 specification describes linked Checkout and Payment Mandates for authorizing purchases and payments. These illustrate the kind of evidence needed for an authorization claim. They are not a public activity feed automatically attached to every blockchain transaction.
A worked example: correct the headline
The following figures are illustrative only. Suppose a research export contains 1,000 rows covering six contiguous hours of a requested 24-hour day. After removing repeated transaction hashes, 900 distinct transactions remain. Only 720 have known amounts under the chosen decoding rule, totalling 360 units of the same token.
Three tempting calculations need correction:
- Daily volume: The defensible finding is 360 known token units observed during the covered six hours, with 180 transactions lacking known values. Multiplying by four would be a model based on an untested assumption, not a measured daily total.
- Average amount: The known-value average is 360 ÷ 720 = 0.5 tokens. Dividing by all 900 transactions would incorrectly treat unknown amounts as zero. Include known zero amounts in the denominator.
- Agent activity: If 40 transactions are linked to service orders, that establishes a linked subset under your matching rule. It does not establish that all 900 transactions were agent purchases, or that the 40 orders produced correct results.
The appropriate headline might be: “900 transactions observed across six covered hours; 40 linked to service orders.” The subtitle should explain that the example's linkage evidence is additional to the blockchain records. These figures are not InferenceView's current dataset statistics.
Compare periods with the same rules
Before announcing growth, compare networks, currency contracts, UTC boundaries, coverage and decoder versions. A newly connected source or repaired collection gap can increase observed activity without any change in underlying demand.
Separate continuous collection from historical samples. Publish the unknown-value count alongside the known-value total. If you change a classification rule, restate the earlier period when possible; otherwise mark the break in the series.
What InferenceView supports today
InferenceView provides retained Tempo observations, recognized amounts, execution states and limited record-consistency evidence. It does not currently establish agent identity, authorized service purchases, delivery or task correctness. Its active-wallet metric counts initiating addresses. Selected stablecoin totals use a nominal one-dollar convention, with fees separate.
Use the Tempo dataset, coverage endpoint and methodology together. If your research needs a defined extract or a service-evidence integration, request a curated dataset with your time window, counting unit and required evidence fields.