OpenChainGraph Suite · CONTRACT A3 · arch #5

x402 Permit2 Spend Evidence Pack

Linear two-step evidence pipeline for the Permit2 asset-transfer method of an x402 exact or upto payment, the sibling of the EIP-3009 pipeline. The first step recomputes the Permit2 typed-data digest the payer signed and reports the binding, window, nonce-space and signature-form facts around it; the second step recovers the signer from that digest and reports whether the recovered address matches the claimed payer. The two outputs compose into an evidence pack a downstream agent or a human reads before relying on an authorization. This is an evidence bundle and never a settlement proof: no chain is read, nothing is submitted, and any fact whose input was not declared reports NOT_EVALUATED.

OpenChainGraph · 2 Steps compliance control Hash-Anchored §4 chain_depth:2 Client-Side · Zero PII
Chain Topology · X402 Permit2 Evidence Recomputer → x402 Signer Recovery Verifier
§4 Execution Hash · Chain Definition Anchor
execution_hash:computing…
Chain Stages · 2 Steps
1 ROOT node
X402 Permit2 Evidence Recomputer art-699-x402-permit2-evidence-recomputer
recomputes the Permit2 digest bytes and emits handoff_591, which carries that digest with the claimed payer and the signature components in the shape the next step reads
MCP Call · recompute_x402_permit2_digest
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "recompute_x402_permit2_digest",
    "arguments": {}
  },
  "id": 1
}
↓
2 TERMINAL · D2 node
x402 Signer Recovery Verifier art-591-x402-signer-recovery-verifier
recovers the signer address from those digest bytes and reports the claimed-from match, which is the terminal fact in the assembled evidence pack
MCP Call · verify_x402_signer_recovery
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "verify_x402_signer_recovery",
    "arguments": {}
  },
  "id": 1
}
Export Artifacts
Download the §4 chain definition artifact (hash-anchored composite JSON) or the §13.11 W3C Verifiable Credentials view. Both derive from the chain definition and no new hash is minted. Available after hash computation.

Ask your agent

Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this whole workflow on the server and check one field that answers a real question.

Question: A payer sent me a Permit2 authorization for an x402 charge. Did the key I think owns that wallet actually sign these exact terms?
Run the AINumbers MCP tool `run_chain` with {"chain":"x402-permit2-spend-evidence"} and read `art-591-x402-signer-recovery-verifier.recovered_signer_matches_claimed_from`.
Re-run with `inputs` for `art-591-x402-signer-recovery-verifier`, reusing the values that result echoed, with `claimedFrom` changed so any other twenty byte address, which breaks the claimed payer match. Compare the same field.
Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`.
Ledger, for a human re-check: https://ledger.ainumbers.co/
PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads.
Chain page: https://ainumbers.co/chaingraph/chains/x402-permit2-spend-evidence.html