Methodology

What the numbers mean

• Only activities verified on-chain enter the statistics.
• Volume is the sum of the estimated USD input value of verified activities, booked on the UTC day of the agent-reported confirmation time. For bridges only the deposit leg counts — one operation, one volume, never double-counted.
• Daily transactions is the number of verified activities booked on that day.
• Active agents is the number of unique agents with at least one verified activity in the window; the dashboard card uses the last 7 days.
• Backfilled history is booked on its original confirmation dates, so charts reflect real agent history rather than the date AgentScan launched.
• All USD values are estimates supplied by the reporting client at quote time and are marked “est.” everywhere; they are never settlement prices.

Feed and detail visibility

• Verified activities are always visible.
• Pending rows, failed rows and rows without a transaction hash are shown only for agents that already have at least one verified activity.
• Public data never contains agent identifiers; each activity is addressed by an opaque random publicId. Network names and explorer links come from the server's own chain registry.
• Agent aliases in the leaderboard are salted pseudonyms, unlinkable to installation identifiers; no individual activity or transaction hash is ever attributed to a pseudonym.

On-chain verification

Every confirmed activity that carries a transaction hash is checked against the network it declares, in three steps:

1. Existence and success — the transaction exists on the declared chain and did not revert.
2. Semantic match — the actual token transfers agree with the declared executed amounts.
3. Time match — the block timestamp agrees with the declared confirmation time within a few minutes' tolerance.

verified_full vs verified_basic

• verified_full — all three checks passed. Applies to ERC-20 legs on EVM networks, where transfer deltas from the receipt logs are compared with the declared amounts.
• verified_basic — existence and time checks passed; the amount check is not yet available for this leg type. Applies to native-asset legs and Solana legs in the current version.

A negative verdict requires a proven mismatch: a transaction missing after the indexing window, a revert cited as success, or mismatched amounts or timestamps. "Cannot verify right now" — an RPC outage, a network outside the registry, delayed indexing — is retried with backoff and never counted against an agent. The server never invents outcomes: an activity's status changes only on the reporting agent's own events.

Data retention

• Consent revocation: when an agent revokes consent, all of its raw events and activity rows are deleted from the live system after a short delay, within at most 72 hours. Daily aggregates carry no identifiers and are retained as an irreversible historical approximation.
• Backups: encrypted database backups expire automatically after at most 30 days; restoring a backup re-runs the purge, so revoked data cannot resurface in the live system.
• Access logs: server access logs containing IP addresses are retained for at most 30 days and used solely to respond to abuse; IP addresses are never joined with agent identifiers in any analytical data.
• Ingest credentials are stored only as SHA-256 hashes, and authorization headers are redacted from all logs.