Agent 402 Tape methodology: how the consolidated tape works

01

What Agent 402 Tape is

Agent 402 Tape is the consolidated settlement tape for the x402 protocol ecosystem. Agent 402 operates it as a neutral, multi-chain observer of USDC settlement events attributable to x402 services. It is read-only, append-only, and free to query. The institutional template is the Consolidated Tape Association in U.S. equities: the tape disseminates raw trade data without editorializing it.

Nothing in the public Tape API ranks, scores, recommends, or interprets observed events. Rankings, opportunity flags, and trust tiers live in Agent 402 Demand Intel, which is a separate product layer that consumes Tape data among other sources.

02

What we observe

USDC Transfer events on EVM chains, and SPL Token transfer instructions on Solana, where the recipient address is a known x402 payTo (recovered from facilitator discovery endpoints and indexed publisher 402 responses). Per-chain ingest cadence is roughly two minutes for the live tail.

Network	Live tail	Confirmation depth	Adapter
Base	live	30 blocks (~60s)	`base_evm.py`
Polygon	live	64 blocks	`evm.py` (generic)
Solana	live	32 slots (finalized commitment)	`solana.py`
Optimism	wired, off	30 blocks	`evm.py`
Arbitrum	wired, off	30 blocks	`evm.py`

Historical backfill walks each chain backward toward the start of meaningful x402 settlement activity (approximately Q1 2024 on Base). Backfill state can be inspected via GET /tape/api/v1/health.

03

What we do not observe

Tokens other than USDC. At v1, only USDC settlements are tracked. The Phase 1 audit found USDC accounts for nearly 100% of catalogued x402 traffic. Other tokens are deferred.
Chains not in the table above. Hedera (REST API paradigm) is deferred. New EVM chains and additional non-EVM chains are added behind feature flags.
Off-chain payment rails. Stripe-rail MPP settlements, Lightning, and Tempo-USDC are out of scope at v1. These belong to a future MPP-rail observation pipeline.
Signed receipts or offers. The x402 offer-and-receipt extension data is not yet ingested. Capturing it is a planned follow-up (P5.7) so facilitators can backfill missing metadata from our observed record.
Anything published off-chain by facilitators about transactions that did not settle on chain. Tape is a chain observer.

04

Attribution tiering

From chain data alone, a USDC transfer to a known payTo cannot always be attributed to a specific service. Some facilitator wallets serve hundreds of providers from a single pooled address. Pretending otherwise would be false precision, so we tier honestly.

Tier	When	Behavior
direct	Recipient wallet serves 1 to 5 known providers.	Event is attributed to a specific `service_id`. Aggregations roll up per service.
pool	Recipient wallet serves 6 or more known providers (facilitator gas pool).	Event is attributed to the pool wallet. Aggregations roll up per pool, never claimed for a single service.
unattributed	Recipient is not in our known payTo set.	Event is kept in an audit table for backfill investigation. Not surfaced in service aggregations.

The threshold (POOL_PROVIDER_THRESHOLD = 6) is set in services/tape/attribution.py. It is conservative: panel-vs-census trade-off favoring honesty over coverage breadth.

05

The 6 API design principles

No interpretation. No rankings, recommendations, trust scores, opportunity flags, or anomaly markers. Counts, sums, last-seen, and attribution tier only.
Provenance in every aggregation payload. Every response carries "source": "Agent 402 Tape" and a "confidence" field.
Methodology link in every aggregation response. Body-level _links.methodology points back here. Body, not HTTP header, because LLM consumers commonly drop headers in tool chains.
Pool vs direct exposed honestly. The attribution_tier field is always present on per-event responses. Pool-attributed services get confidence: "pool" so consumers can skip-score them.
Read-only forever. No POST, PUT, PATCH, or DELETE that mutates tape state. (POST /aggregate/batch is a read-shaped POST: it queries, it does not write.)
Versioned semantics. All endpoints live under /tape/api/v1/*. Field meanings defined here are locked at v1. Changes require a v2 cutover, not a silent semantic shift.

06

Read endpoints

Full OpenAPI documentation: https://agent402.app/api/docs#tag/tape. The /aggregate endpoint is also listed as a free x402 service on the Agent 402 Marketplace.

Endpoint	Purpose
`GET /tape/api/v1/health`	Per-chain ingest lag and coverage attestation.
`GET /tape/api/v1/recent`	Recent events across all networks, polling source for the ticker.
`GET /tape/api/v1/aggregate`	Observed settlement aggregate for one service.
`POST /tape/api/v1/aggregate/batch`	Up to 100 services in one call. Read-shaped POST, no writes.
`GET /tape/api/v1/service/{id}/history`	Paginated per-service event stream.
`GET /tape/api/v1/network/{slug}/top`	Top services on a chain by direct-attributed volume.
`GET /tape/api/v1/payer/{addr}/spending`	What a wallet has paid for, per recipient.
`GET /tape/api/v1/pool/{addr}/stats`	Aggregate stats for a facilitator pool wallet.

07

Confidence levels in responses

Confidence	Meaning
`high`	Direct-attributed observations exist for this service in the requested window. Counts and sums map one-to-one to real on-chain events.
`pool`	The service's payTo is a pool wallet. Returned aggregates are pool-level, summed across all providers sharing that wallet. Per-service comparison is not meaningful; downstream consumers should skip-score these.
`none`	Service is not resolved, or resolved with no observations in window. Counts and sums are zero.

08

Reorg policy

Events are written with confirmed: false when first observed. After the per-chain confirmation depth (30 blocks on most EVM chains, 64 on Polygon, 32 slots on Solana under finalized commitment) they are flipped to confirmed: true. Aggregations include unconfirmed events but expose the confirmed bit on per-event responses so consumers can filter when needed.

Re-orgs that invalidate previously-observed events are rare at the confirmation depths above. When they do occur, the next ingest cycle reconciles, and a nightly integrity sweep (tape_rollup_rebuild at 04:00 UTC) rebuilds every rollup row from tape_events ground truth.

09

Known limitations

Historical backfill is in progress. Base history is being walked by four parallel workers; remaining segments complete over days, not hours. Polygon and Solana historical backfill is queued behind Base.
Pool aggregation loses per-service signal. Around facilitator gas-pool wallets (CDP, PayAI, and others depending on the wallet), services sharing a pool show confidence: "pool" instead of direct attribution. This is honest, not a bug.
USDC only. Other settlement assets are not yet observed.
x402-recognized services only. Transfers to wallets we have not indexed as x402 payTos are kept in an audit table but not surfaced through the public API.
Network share reflects events, not USD. The network-share bar on /tape weights by observed event count. A future iteration may toggle to USD-weighted share.
Inferred facilitator is a model output, not an observation. When responses include a facilitator slug, that value comes from services/facilitator_inference.py based on payTo + hostname + feePayer signals. It is best-effort attribution. The raw on-chain destination is always exposed and authoritative.

10

Version history

v1 (current). Schema and field semantics locked. All endpoints under /tape/api/v1/*. The following are NOT guaranteed for future versions: addition of new fields (additive only, safe), addition of new chains (additive, safe), addition of new endpoints (additive, safe). The following WOULD require a v2 cutover: renaming or repurposing existing fields, changing the meaning of attribution tiers, changing the confidence-tier vocabulary, lowering the pool threshold below 6.

11

Contact

Data quality reports, attribution disputes, or methodology questions: open an issue on GitHub. Include service ID or resource URL, the affected window, and what you observed vs what you expected.

For collaboration on the x402 observed-settlements extension proposal, contact us via the issue tracker above with the prefix spec:.