{ "generated_at": "2026-08-17T22:06:57.304Z", "note": "Agentic-payments mapping table. Node/chain references are resolved live from chaingraph.json at generation time, so a renamed or removed node fails generation rather than shipping a dangling link. Every claim cites a pinned snapshot from research/AGENTIC-PAY-SNAPSHOT-INDEX-2026-08-17.md; cells with no governing text say so rather than inventing a citation.", "snapshot_index": "research/AGENTIC-PAY-SNAPSHOT-INDEX-2026-08-17.md", "sources": { "x402": { "n": 1, "doc": "x402 v2 spec" }, "vpsf": { "n": 2, "doc": "draft-vauban-x402-vpsf-algebra-01" }, "stark": { "n": 3, "doc": "draft-vauban-x402-stark-receipts-00" }, "starkconf": { "n": 4, "doc": "x402-stark-receipts-conformance" }, "acp": { "n": 5, "doc": "ACP stable spec" }, "ap2": { "n": 6, "doc": "AP2 (FIDO-governed)" }, "cookbook": { "n": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook" }, "circle": { "n": 8, "doc": "Circle, \"Building the open agentic economy\"" }, "erc8004": { "n": 9, "doc": "ERC-8004" }, "mpp": { "n": 10, "doc": "MPP (Machine Payments Protocol, Tempo/Stripe)" } }, "rows": [ { "concept": "Bounded pre-authorization to spend", "agentcore_cookbook": "ApprovalGrant{approval_id, request_id, resource_url, purpose, maximum_amount, approved_by, expires_at, currency}. App-issued; the model never sets these values.", "x402_v2": "No pre-authorization primitive. x402 payment is settled per-request rather than pre-scoped.", "mpp": "No direct equivalent in the pinned core/tempo specs", "vpsf_claim_operator": "DelegationGrant (§3.2): a principal authorises an agent to spawn PaymentIntents within a scoped constraint set", "acp_object": "delegate_payment / delegate_authentication schema objects", "ap2_mandate_type": "Checkout Mandate / Payment Mandate (current FIDO-governed spec text; the earlier \"Intent/Cart Mandate\" naming does not appear in the pinned spec)", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-01", "tool_id": "art-01-ap2-mandate-chain-validator", "title": "AP2 Mandate-Chain Validator", "url": "art-01-ap2-mandate-chain-validator.html", "status": "live" }, { "id": "art-16", "tool_id": "art-16-google-ap2-mandate-builder", "title": "Google AP2 Mandate Builder", "url": "art-16-google-ap2-mandate-builder.html", "status": "live" }, { "id": "art-17", "tool_id": "art-17-ap2-mcp-policy-validator", "title": "AP2/MCP Policy Validator", "url": "art-17-ap2-mcp-policy-validator.html", "status": "live" }, { "id": "art-274", "tool_id": "art-274-compile-work-mandate", "title": "Work Mandate Compiler", "url": "art-274-compile-work-mandate.html", "status": "live" }, { "id": "art-476", "tool_id": "art-476-map-agent-payment-mandate", "title": "Agent Payment Mandate Cross-Protocol Mapper", "url": "art-476-map-agent-payment-mandate.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "Mandate-chain signature, scope, and limit-consistency integrity across the Intent→Cart→Payment trio (art-01); translation of a mandate declared under one protocol into another's fields (art-476).", "we_do_not_assert": "Whether the merchant actually honored the approval at settlement time is a separate question, covered below.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "ApprovalGrant field shape" }, { "src": 2, "doc": "draft-vauban-x402-vpsf-algebra-01", "section": "§3.2 DelegationGrant" }, { "src": 5, "doc": "ACP stable spec", "section": "delegate_payment / delegate_authentication schemas" }, { "src": 6, "doc": "AP2 (FIDO-governed)", "section": "specification.md, Mandate types: Checkout Mandate and Payment Mandate" } ] }, { "concept": "A specific purchase the agent wants to make", "agentcore_cookbook": "PurchaseRequest{request_id, resource_url, purpose, idempotency_key}", "x402_v2": "PAYMENT-SIGNATURE request header: the client presents payment proof for the resource", "mpp": "draft-httpauth-payment-00 payment-request field (core HTTP auth scheme, generic across tempo methods)", "vpsf_claim_operator": "PaymentIntent (§3.2): the initiating state, records the payer's commitment", "acp_object": "agentic_checkout schema object", "ap2_mandate_type": "No distinct object; folded into Checkout/Payment Mandate above", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-26", "tool_id": "art-26-x402-payload-decoder-flow-simulator", "title": "x402 Header Decoder, Payload Linter & 402 Flow Simulator", "url": "art-26-x402-payload-decoder-flow-simulator.html", "status": "live" }, { "id": "art-01", "tool_id": "art-01-ap2-mandate-chain-validator", "title": "AP2 Mandate-Chain Validator", "url": "art-01-ap2-mandate-chain-validator.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "Decodes and lints the base64 PAYMENT-SIGNATURE header shape against the exact-scheme x402 flow (art-26).", "we_do_not_assert": "Does not verify the merchant actually fulfilled the purchase.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "PurchaseRequest field shape, idempotency_key" }, { "src": 1, "doc": "x402 v2 spec", "section": "PAYMENT-SIGNATURE header" }, { "src": 2, "doc": "draft-vauban-x402-vpsf-algebra-01", "section": "§3.2 PaymentIntent" }, { "src": 5, "doc": "ACP stable spec", "section": "json-schema/schema.agentic_checkout.json" } ] }, { "concept": "Evidence the payment settled", "agentcore_cookbook": "Receipt{receipt_id, amount, currency, network, reused}", "x402_v2": "PAYMENT-RESPONSE header / SettleResponse.transaction (§5.3.2)", "mpp": "Tempo session voucher/receipt (see the MPP row below: same shape, its own row for the field-level divergences found)", "vpsf_claim_operator": "SettlementReceipt (§3.2): the terminal successful state, linked to its originating PaymentIntent by JCS Preimage Hash", "acp_object": "No distinct receipt object in the pinned spec beyond checkout completion", "ap2_mandate_type": "No distinct object; receipt evidence is carried inside the Payment Mandate flow", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-26", "tool_id": "art-26-x402-payload-decoder-flow-simulator", "title": "x402 Header Decoder, Payload Linter & 402 Flow Simulator", "url": "art-26-x402-payload-decoder-flow-simulator.html", "status": "live" }, { "id": "art-513", "tool_id": "art-513-public-money-settlement-receipt", "title": "Public-Money Settlement Receipt", "url": "art-513-public-money-settlement-receipt.html", "status": "live" } ], "ainumbers_chain": { "name": "x402-spend-evidence", "title": "x402 Spend Evidence Pack", "url": "chains/x402-spend-evidence.html" }, "no_verifier_note": null, "see_also": null, "we_assert": "Turns one caller-transcribed payment into settlement evidence an audit authority can check (art-513); recomputes the EIP-712 digest, signer recovery, and domain-nonce-window trust signals behind an x402 authorization (x402-spend-evidence chain), described by the chain itself as an evidence bundle rather than a settlement proof.", "we_do_not_assert": "Independent confirmation of on-chain settlement finality is out of scope: x402's own SettleResponse.transaction is \"Blockchain transaction hash (empty string if settlement failed),\" a chain-lookup reference rather than a self-contained artifact. That is exactly the gap the STARK-receipts extension (source 3) exists to close, and the estate has not implemented it.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "Receipt field shape" }, { "src": 1, "doc": "x402 v2 spec", "section": "§5.3.2 SettleResponse.transaction" }, { "src": 3, "doc": "draft-vauban-x402-stark-receipts-00", "section": "line 17: \"reference but does not provide a self-contained, offline-verifiable [receipt]\"" }, { "src": 2, "doc": "draft-vauban-x402-vpsf-algebra-01", "section": "§3.2 SettlementReceipt" } ] }, { "concept": "Audit trail of what happened, in order", "agentcore_cookbook": "audit {sequence, event_type}", "x402_v2": "No audit-log primitive in the pinned spec", "mpp": "No audit-log primitive in the pinned specs", "vpsf_claim_operator": "No audit-log primitive: the composite preimage links claims but does not sequence events", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [], "ainumbers_chain": null, "no_verifier_note": "No single node verifies an audit sequence as such: execution_hash is a property of every node's own run. See How the Kernel VM Works for the mechanism.", "see_also": null, "we_assert": "Every AINumbers node run carries an execution_hash: a deterministic SHA-256 over the RFC 8785 (JCS) canonical form of {policy_parameters, output_payload}, computed by the one shared chaingraph/kernels/_hash.mjs path. That is a content-addressed receipt of one computation rather than an ordered event log.", "we_do_not_assert": "This is a different mechanism than AgentCore's own internal audit sequence numbers, and it is a receipt scheme rather than a blockchain audit trail.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "audit {sequence, event_type}" } ] }, { "concept": "Whether settlement actually finalized", "agentcore_cookbook": "settlement_verified=false. \"Merchant acceptance establishes that the paid request completed. Independent settlement and transaction finality require separate evidence.\"", "x402_v2": "SettleResponse.transaction (§5.3.2): a chain-lookup reference rather than a finality attestation", "mpp": "Tempo channel settled/cumulativeAmount fields (uint128) record state; they are not an independent finality confirmation", "vpsf_claim_operator": "SettlementReceipt claims settlement occurred; the algebra does not itself define a finality check", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-03", "tool_id": "art-03-x402-settlement-modeler", "title": "x402 Settlement Cost & Finality Modeler", "url": "art-03-x402-settlement-modeler.html", "status": "live" }, { "id": "art-492", "tool_id": "art-492-classify-settlement-finality", "title": "Settlement Finality Classifier", "url": "art-492-classify-settlement-finality.html", "status": "live" }, { "id": "art-394", "tool_id": "art-394-x402-deferred-handshake-validator", "title": "x402 Deferred-Scheme Handshake Validator", "url": "art-394-x402-deferred-handshake-validator.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "art-492 classifies which of three settlement-finality models applies and its evidentiary weight, vendor-neutral; art-03 recommends a settlement rail based on finality needs across x402/Stripe-USDC/card/ACH/SWIFT; art-394 validates the shape of a Cloudflare deferred x402 handshake.", "we_do_not_assert": "None of the three independently observes on-chain confirmation for a specific transaction. That is the same gap AgentCore names with settlement_verified=false.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "settlement_verified=false, \"settlement still needs separate evidence\"" }, { "src": 1, "doc": "x402 v2 spec", "section": "§5.3.2 SettleResponse.transaction" } ] }, { "concept": "A per-run spend cap", "agentcore_cookbook": "policy.per_run_limit", "x402_v2": "No run-level budget field; scoping is the caller's own responsibility", "mpp": "n/a", "vpsf_claim_operator": "Closest is DelegationGrant's \"scoped constraint set\" (§3.2), which is not itself a named field", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-02", "tool_id": "art-02-agent-spend-policy-simulator", "title": "Agent Spend-Policy Simulator", "url": "art-02-agent-spend-policy-simulator.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "Simulates thousands of synthetic agent transactions against a user-authored spend policy (per-merchant, per-day, per-transaction caps) and reports policy compliance.", "we_do_not_assert": "This is an offline policy simulator; it does not enforce the limit live inside any run.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "policy.per_run_limit" } ] }, { "concept": "A merchant-initiated reversal", "agentcore_cookbook": "Not present in the pinned cookbook text", "x402_v2": "Not present in the pinned x402 v2 spec", "mpp": "n/a", "vpsf_claim_operator": "RefundClaim (§3.2): the reversal state, merchant-initiated, cryptographically linked to the SettlementReceipt it reverses", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [], "ainumbers_chain": null, "no_verifier_note": "No node. A genuine coverage gap, named here rather than left as a silent omission.", "see_also": null, "we_assert": "n/a", "we_do_not_assert": "No AINumbers node computes or verifies a refund/reversal claim today. This is stated plainly here rather than mapped to a node that does not exist.", "cites": [ { "src": 2, "doc": "draft-vauban-x402-vpsf-algebra-01", "section": "§3.2 RefundClaim" } ] }, { "concept": "De-duplicating a retried purchase", "agentcore_cookbook": "PurchaseRequest.idempotency_key", "x402_v2": "Not present in the pinned x402 v2 spec", "mpp": "n/a", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [], "ainumbers_chain": null, "no_verifier_note": "No node. A genuine coverage gap, named here rather than left as a silent omission.", "see_also": null, "we_assert": "n/a", "we_do_not_assert": "No AINumbers node checks or enforces idempotency. This is stated plainly here rather than mapped to a node that does not exist.", "cites": [ { "src": 7, "doc": "OpenAI×AWS AgentCore Payments cookbook", "section": "idempotency_key=\"purchase-cookbook-001\"" } ] }, { "concept": "Who the agent claims to be", "agentcore_cookbook": "approved_by field is the closest analog; the pinned cookbook text carries no identity-registry concept", "x402_v2": "n/a", "mpp": "n/a", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "Identity Registry: ERC-721 plus URIStorage extension resolving agentId/agentURI to a portable, censorship-resistant registration file", "ainumbers_verifiers": [ { "id": "art-604", "tool_id": "art-604-erc8004-registry-entry-verifier", "title": "ERC-8004 Registry Entry Verifier", "url": "art-604-erc8004-registry-entry-verifier.html", "status": "live" }, { "id": "art-04", "tool_id": "art-04-agent-identity-attestation-checker", "title": "Agent Identity & Authorization Attestation Checker", "url": "art-04-agent-identity-attestation-checker.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "art-604 checks a caller-supplied claimed ERC-8004 registry entry field-by-field against the registry type it declares (Identity, Reputation, or Validation), with no hardcoded per-registry field names by design. art-04 checks a separate DIF Trusted AI Agents WG credential-chain attestation (KYA-OS), a different standard aimed at the same general question.", "we_do_not_assert": "art-04 does not implement ERC-8004. The retrieval pass for this page (see the source list below) checked both its HTML and JSON node files and found zero ERC-8004 citations there, so this table makes no such claim.", "cites": [ { "src": 9, "doc": "ERC-8004", "section": "Identity Registry: agentId/agentURI, ERC-721+URIStorage" } ] }, { "concept": "Whether the agent has a track record", "agentcore_cookbook": "n/a", "x402_v2": "n/a", "mpp": "n/a", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "Reputation Registry: standard interface for posting and fetching feedback signals (giveFeedback), scored both on-chain and off-chain", "ainumbers_verifiers": [ { "id": "art-278", "tool_id": "art-278-reputation-score-aggregator", "title": "Provable Reputation Score Aggregator", "url": "art-278-reputation-score-aggregator.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "Aggregates a set of OCG execution receipts (attestations) into a deterministic, groth16-provable reputation score.", "we_do_not_assert": "This aggregates our own OCG receipts, a parallel scheme over a different evidence source. It does not implement ERC-8004's on-chain giveFeedback interface, and it is not a registry client.", "cites": [ { "src": 9, "doc": "ERC-8004", "section": "Reputation Registry: giveFeedback, on-chain and off-chain scoring" } ] }, { "concept": "A Tempo/Stripe MPP session voucher or receipt", "agentcore_cookbook": "n/a", "x402_v2": "n/a", "mpp": "methodDetails.sessionProtocol, cumulativeAmount (uint128 for both v1 and v2)", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-594", "tool_id": "art-594-tempo-mpp-voucher-receipt-verifier", "title": "Tempo MPP Voucher & Receipt Verifier", "url": "art-594-tempo-mpp-voucher-receipt-verifier.html", "status": "live" }, { "id": "art-36", "tool_id": "art-36-tempo-mpp-agent-mandate", "title": "Tempo MPP Agent Mandate", "url": "art-36-tempo-mpp-agent-mandate.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": null, "we_assert": "art-594 verifies a Tempo MPP cumulative EIP-712 session voucher offline (ecrecover, no network call); art-36 parses an MPP session and maps its terms to HTTP-request fields.", "we_do_not_assert": "The retrieval pass for this page found two open divergences against the pinned spec, left unfixed here since this is a mapping page rather than a kernel edit: art-594's input field is named protocolVersion where the spec's field is methodDetails.sessionProtocol, and art-594 states v2 uses uint96 where the pinned spec states uint128 for both v1 and v2. Separately, art-36's hero copy expands \"MPP\" as \"Money Payment Protocol,\" where the spec repo's own title is \"Machine Payments Protocol.\"", "cites": [ { "src": 10, "doc": "MPP (Machine Payments Protocol, Tempo/Stripe)", "section": "draft-tempo-session-00.md §\"Protocol Versions\", Contract-Backed Channel State table" } ] }, { "concept": "USDC settlement over Circle's Arc network", "agentcore_cookbook": "n/a", "x402_v2": "n/a", "mpp": "n/a", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [ { "id": "art-492", "tool_id": "art-492-classify-settlement-finality", "title": "Settlement Finality Classifier", "url": "art-492-classify-settlement-finality.html", "status": "live" }, { "id": "art-110", "tool_id": "art-110-arc-partner-stablecoin-onboarding", "title": "Arc Partner Stablecoin Onboarding Conformance", "url": "art-110-arc-partner-stablecoin-onboarding.html", "status": "live" }, { "id": "art-111", "tool_id": "art-111-arc-corridor-jurisdiction-router", "title": "Arc Multi-Currency Corridor Jurisdiction Router", "url": "art-111-arc-corridor-jurisdiction-router.html", "status": "live" } ], "ainumbers_chain": null, "no_verifier_note": null, "see_also": { "label": "Arc / USDC network guide", "url": "guide-arc.html" }, "we_assert": "art-110 scores a non-USD stablecoin issuer's readiness to join Circle Partner Stablecoins on Arc; art-111 routes each leg of a multi-currency Arc corridor to its per-currency home regime; art-492's vendor-neutral finality classification applies to Arc settlements as one of its covered models.", "we_do_not_assert": "None of the ten pinned sources for this page is an Arc-specific settlement spec, so this table cites no clause for the Arc mechanics themselves. See the Arc network guide linked here for that detail instead of restating it.", "cites": [] }, { "concept": "\"Verifiable compute\" as a validation primitive", "agentcore_cookbook": "n/a", "x402_v2": "n/a", "mpp": "n/a", "vpsf_claim_operator": "n/a", "acp_object": "n/a", "ap2_mandate_type": "n/a", "erc8004_registry": "n/a", "ainumbers_verifiers": [], "ainumbers_chain": null, "no_verifier_note": null, "see_also": { "label": "How the Formal-Verification Pilot Works (Panel 5: execution binding)", "url": "../fv-explainer.html" }, "we_assert": "Circle's own market map lists \"Validation: ERC-8004 + verifiable compute\" as an \"Emerging\" capability. Nodes carrying compute_proof in this estate ship a zk proof of execution bound to a kernel digest, spec digest, and toolchain digest, the same triple-identity binding the formal-verification pilot documents, which is the same general shape Circle names.", "we_do_not_assert": "Coverage is never quoted as a fixed number here; it is a live-derived count (node scripts/check-compute-proof-coverage.mjs), per this estate's own standing rule against publishing a duty-bound figure that can silently go stale. This table also makes no claim that our compute_proof and Circle's \"verifiable compute\" category are the same mechanism, only that they name the same general shape.", "cites": [ { "src": 8, "doc": "Circle, \"Building the open agentic economy\"", "section": "\"Validation: ERC-8004 + verifiable compute,\" Emerging" } ] } ] }