ChainGraph · agentic payments

What maps to what, across the agentic-payments stack

The OpenAI×AWS AgentCore Payments cookbook, x402 v2, the VPSF/STARK receipt drafts, ACP, AP2, ERC-8004, and MPP each name a piece of the same problem: an agent spends money and someone needs to check it happened correctly. This page lines up their fields side by side with the AINumbers node or chain that verifies each piece, states what we actually assert, and states what we do not, as often as the reverse. Every claim below cites a pinned snapshot retrieved for this page; a cell with nothing to cite says so.

Flow

Where our verification attaches, and what stays unproven

Agent to app approval to payment proof to merchant to receipt: our nodes attach at the receipt and settlement-classification steps. Settlement finality itself, and an offline-verifiable receipt in the STARK sense, are named gaps here rather than silent ones.

Agent App approval ApprovalGrant / DelegationGrant Payment proof PAYMENT-SIGNATURE / PaymentIntent Merchant Receipt our verification attaches here art-26 / art-513 Settlement classification art-492 / art-03 / art-394 Settlement finality settlement_verified=false in the cookbook; SettleResponse.transaction not independently confirmed here Offline-verifiable receipt STARK-receipts extension exists to close this exact gap not implemented in this estate Green = where an AINumbers node attaches. Red = named gaps, stated honestly rather than silently skipped.
Mapping table

Field by field, protocol by protocol

Machine-readable twin at chaingraph/data/agentic-payments-map.json, generated by the same script from the same source table. Node and chain links are resolved from chaingraph.json at generation time, so a link here cannot dangle.

Concept AgentCore cookbook x402 v2 MPP VPSF claim/operator ACP object AP2 mandate type ERC-8004 registry AINumbers verifier We assert We do NOT assert Cites
Bounded pre-authorization to spend ApprovalGrant{approval_id, request_id, resource_url, purpose, maximum_amount, approved_by, expires_at, currency}. App-issued; the model never sets these values. No pre-authorization primitive. x402 payment is settled per-request rather than pre-scoped. No direct equivalent in the pinned core/tempo specs DelegationGrant (§3.2): a principal authorises an agent to spawn PaymentIntents within a scoped constraint set delegate_payment / delegate_authentication schema objects Checkout Mandate / Payment Mandate (current FIDO-governed spec text; the earlier "Intent/Cart Mandate" naming does not appear in the pinned spec) n/a art-01-ap2-mandate-chain-validator
art-16-google-ap2-mandate-builder
art-17-ap2-mcp-policy-validator
art-274-compile-work-mandate
art-476-map-agent-payment-mandate		 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). Whether the merchant actually honored the approval at settlement time is a separate question, covered below. [7] [2] [5] [6]
A specific purchase the agent wants to make PurchaseRequest{request_id, resource_url, purpose, idempotency_key} PAYMENT-SIGNATURE request header: the client presents payment proof for the resource draft-httpauth-payment-00 payment-request field (core HTTP auth scheme, generic across tempo methods) PaymentIntent (§3.2): the initiating state, records the payer's commitment agentic_checkout schema object No distinct object; folded into Checkout/Payment Mandate above n/a art-26-x402-payload-decoder-flow-simulator
art-01-ap2-mandate-chain-validator		 Decodes and lints the base64 PAYMENT-SIGNATURE header shape against the exact-scheme x402 flow (art-26). Does not verify the merchant actually fulfilled the purchase. [7] [1] [2] [5]
Evidence the payment settled Receipt{receipt_id, amount, currency, network, reused} PAYMENT-RESPONSE header / SettleResponse.transaction (§5.3.2) Tempo session voucher/receipt (see the MPP row below: same shape, its own row for the field-level divergences found) SettlementReceipt (§3.2): the terminal successful state, linked to its originating PaymentIntent by JCS Preimage Hash No distinct receipt object in the pinned spec beyond checkout completion No distinct object; receipt evidence is carried inside the Payment Mandate flow n/a art-26-x402-payload-decoder-flow-simulator
art-513-public-money-settlement-receipt
chain: x402 Spend Evidence Pack		 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. 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. [7] [1] [3] [2]
Audit trail of what happened, in order audit {sequence, event_type} No audit-log primitive in the pinned spec No audit-log primitive in the pinned specs No audit-log primitive: the composite preimage links claims but does not sequence events n/a n/a n/a 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. 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. 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. [7]
Whether settlement actually finalized settlement_verified=false. "Merchant acceptance establishes that the paid request completed. Independent settlement and transaction finality require separate evidence." SettleResponse.transaction (§5.3.2): a chain-lookup reference rather than a finality attestation Tempo channel settled/cumulativeAmount fields (uint128) record state; they are not an independent finality confirmation SettlementReceipt claims settlement occurred; the algebra does not itself define a finality check n/a n/a n/a art-03-x402-settlement-modeler
art-492-classify-settlement-finality
art-394-x402-deferred-handshake-validator		 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. None of the three independently observes on-chain confirmation for a specific transaction. That is the same gap AgentCore names with settlement_verified=false. [7] [1]
A per-run spend cap policy.per_run_limit No run-level budget field; scoping is the caller's own responsibility n/a Closest is DelegationGrant's "scoped constraint set" (§3.2), which is not itself a named field n/a n/a n/a art-02-agent-spend-policy-simulator Simulates thousands of synthetic agent transactions against a user-authored spend policy (per-merchant, per-day, per-transaction caps) and reports policy compliance. This is an offline policy simulator; it does not enforce the limit live inside any run. [7]
A merchant-initiated reversal Not present in the pinned cookbook text Not present in the pinned x402 v2 spec n/a RefundClaim (§3.2): the reversal state, merchant-initiated, cryptographically linked to the SettlementReceipt it reverses n/a n/a n/a No node. A genuine coverage gap, named here rather than left as a silent omission. n/a 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. [2]
De-duplicating a retried purchase PurchaseRequest.idempotency_key Not present in the pinned x402 v2 spec n/a n/a n/a n/a n/a No node. A genuine coverage gap, named here rather than left as a silent omission. n/a No AINumbers node checks or enforces idempotency. This is stated plainly here rather than mapped to a node that does not exist. [7]
Who the agent claims to be approved_by field is the closest analog; the pinned cookbook text carries no identity-registry concept n/a n/a n/a n/a n/a Identity Registry: ERC-721 plus URIStorage extension resolving agentId/agentURI to a portable, censorship-resistant registration file art-604-erc8004-registry-entry-verifier
art-04-agent-identity-attestation-checker		 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. 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. [9]
Whether the agent has a track record n/a n/a n/a n/a n/a n/a Reputation Registry: standard interface for posting and fetching feedback signals (giveFeedback), scored both on-chain and off-chain art-278-reputation-score-aggregator Aggregates a set of OCG execution receipts (attestations) into a deterministic, groth16-provable reputation score. 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. [9]
A Tempo/Stripe MPP session voucher or receipt n/a n/a methodDetails.sessionProtocol, cumulativeAmount (uint128 for both v1 and v2) n/a n/a n/a n/a art-594-tempo-mpp-voucher-receipt-verifier
art-36-tempo-mpp-agent-mandate		 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. 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." [10]
USDC settlement over Circle's Arc network n/a n/a n/a n/a n/a n/a n/a art-492-classify-settlement-finality
art-110-arc-partner-stablecoin-onboarding
art-111-arc-corridor-jurisdiction-router
Arc / USDC network guide →		 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. 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. no governing text among the ten pinned sources
"Verifiable compute" as a validation primitive n/a n/a n/a n/a n/a n/a n/a no node 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. 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. [8]
Sources

Pinned snapshots cited above

  • [1] x402 v2 spec
  • [2] draft-vauban-x402-vpsf-algebra-01
  • [3] draft-vauban-x402-stark-receipts-00
  • [4] x402-stark-receipts-conformance
  • [5] ACP stable spec
  • [6] AP2 (FIDO-governed)
  • [7] OpenAI×AWS AgentCore Payments cookbook
  • [8] Circle, "Building the open agentic economy"
  • [9] ERC-8004
  • [10] MPP (Machine Payments Protocol, Tempo/Stripe)

Full index with sha256, retrieval date, and section refs: research/AGENTIC-PAY-SNAPSHOT-INDEX-2026-08-17.md (workspace-root, not published).

Scope

What this page is not: it does not integrate with AgentCore, Bedrock, x402 facilitators, ACP, AP2, ERC-8004 registries, or MPP. It maps field names to the nodes that already exist on this estate, and it asserts nothing about a mapped node beyond what that node's own description computes. Where the retrieval pass found an open divergence between a node and its pinned spec (art-594, art-36), that divergence is stated in the table above; it ships no kernel edits.