Methodology

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 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.

Tape implements the third-party attestation pattern the x402 offer-and-receipt extension explicitly contemplates. From §8:

Signed offers and receipts can be embedded as evidence in attestations. Those attestations can support discovery, filtering, and reputation scoring for paid API/service endpoints — an area that typically lacks the trust provided by user reviews in app stores and ecommerce sites.

From §9 of the same extension: the offer and receipt objects are "designed to be usable as proof artifacts in attestation systems" and "intentionally self-contained so they can be lifted verbatim into external proof or attestation formats without reconstruction." That is the spec language Tape implements as infrastructure.

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, a separate product layer that consumes Tape data among other sources. The two-layer separation is itself spec-aligned: Tape collects the proof artifacts; Intel implements the §8 "attestation-backed discovery and trust" use case on top of them.

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.

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 /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 beyond P5.7 so facilitators can backfill missing metadata from our observed record. (Spec-canonical on-chain markers shipped in P5.7 and are live; see "Known limitations" below.)
• 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.

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

1. No interpretation. No rankings, recommendations, trust scores, opportunity flags, or anomaly markers. Counts, sums, last-seen, and attribution tier only.
2. Provenance in every aggregation payload. Every response carries "source": "Agent 402 Tape" and a "confidence" field.
3. 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.
4. 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.
5. 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.)
6. Versioned semantics. All endpoints live under /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.

07

Confidence levels in responses

Two confidence axes. The aggregation-response confidence describes how cleanly the recipient maps back to a specific service. The per-event x402_certainty describes how cleanly the observation maps back to the x402 protocol itself.

Aggregation confidence

Per-event x402 certainty

Each event in /api/v1/recent and per-service history responses carries an x402_certainty tier and an open-shaped x402_markers dict. The tier reflects which spec-canonical markers were observed alongside the underlying USDC transfer.

08

Reorg policy

Live ingestion scans only the confirmed window (current tip minus the per-chain confirmation depth: 30 blocks on most EVM chains, 64 on Polygon, 32 slots on Solana under finalized commitment), so every event is written with confirmed: true on first observation. The confirmed bit remains on per-event responses for forward compatibility with future near-tip ingest modes that may capture events earlier.

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 (USDT, native ETH, native SOL, etc.) are not yet observed. The capture filter is asset-keyed today; a future revision (P5.7+) will switch to facilitator-signer-keyed capture so any asset accepted by a known facilitator is automatically indexed without code change.
• 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.
• Spec-canonical markers shipped, signed receipts queued. Per-event x402_markers + x402_certainty are live as of P5.7: EVM events cross-reference the x402ExactPermit2Proxy at 0x402085c248EeA27D92E8b30b2C58ed07f9E20001 and transaction sender against the facilitator-signer registry crawled daily from /supported. Solana events cross-reference Memo program instructions and the transaction fee payer. EIP-3009 AuthorizationUsed is retained as a marker, but is no longer sufficient by itself for public certain-tier x402 attribution. spec_verified remains reserved for signed-receipt verification (offer-and-receipt §9) and is not yet emitted.
• Signed receipts not yet captured (queued P5.7). The offer-and-receipt extension defines a signed receipt artifact returned in SettlementResponse.extensions["offer-receipt"].info.receipt on success. Per §9 of that extension these are "designed to be usable as proof artifacts in attestation systems." Tape will capture them as the second observation channel alongside on-chain transfers; until then, we have the chain side-effect but not the resource-server-signed proof of delivery. P5.7 closes this gap.
• 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. P5.7 will replace this heuristic with deterministic facilitator-signer-registry lookup where the data exists.

10

Version history

v1 (current). Schema and field semantics locked. All endpoints under /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:.