Add provenance-notarization scheme — post-payment proof-of-existence for agent outputs

[GitSerge-crypto]

What

A new experimental scheme in schemes/ that adds post-payment provenance to A2A x402 transactions.

Why

The current A2A x402 flow proves payment intent (AP2) and payment settlement (x402 on-chain). But there is no cryptographic proof that:

1. The merchant agent produced a specific output at a specific time
2. The output was not retroactively modified
3. The output corresponds to the specific payment that funded it

This scheme adds a complementary layer: after payment settlement, the merchant agent notarizes its output hash via an independent notary service (AOTrust), receiving a 239-byte Provenance Data Record (PDR) signed with Ed25519 and anchored on NEAR.

• AP2 proves the client intended to pay
• x402 proves the payment settled on-chain
• Provenance notarization proves the merchant's output existed at a point in time

How it works

After x402 payment settlement:
  Merchant → Notary: work_hash (SHA-256 of output) + payment_hash (EVM tx)
  Notary: verify payment on Base L2 → build PDR → Ed25519 sign → return PDR
  Merchant → Client: Artifact + PDR in metadata
  Client: verify PDR offline (self-contained Ed25519 signature)
  Notary: batch PDRs → Merkle root → NEAR anchor (~16 min)

The PDR is a 239-byte binary record with a self-contained Ed25519 signature. The payment_anchor_type (0x05 = X402_BASE) is inside the signed payload — the PDR self-proves how the service was paid for, without external metadata.

What this is NOT

• Not a payment scheme — does not modify the x402 payment flow
• Not a replacement for existing exact schemes — runs after payment settlement
• Not a storage service — the notary receives only the hash, never the artifact

PDR Format (open standard)

239 bytes, 10 fields, Ed25519/NEP-413 signature. Spec and parser published as open standard:

• Spec: https://github.com/GitSerge-crypto/aotrust-skills/blob/main/pdr-spec.md
• Parser: https://github.com/GitSerge-crypto/aotrust-skills/blob/main/pdr_parser.py (standalone, zero deps, MIT)

Live status

• Mainnet live since June 9, 2026
• 9 PDRs issued on Base Mainnet, all anchored on NEAR (3 anchor transactions)
• API: https://api.aotrust.link
• Verify: https://verify.aotrust.link
• Cost: $0.01 USDC per PDR (10,000 micro-USDC on Base L2)

Changes

• Added schemes/scheme_provenance_notarization.md — full scheme specification
• Updated schemes/README.md — added scheme to the available schemes table

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a new post-payment provenance scheme (provenance-notarization) for the A2A x402 protocol, which enables merchant agents to cryptographically prove the existence and integrity of their output via an independent notary service. The feedback points out a missing base64 import in the Python verification snippet, a discrepancy between the text description and the JSON example for the task state extension, and inconsistent naming between payload_hash and work_hash across the document.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The Python code snippet uses base64.b64decode but does not import the base64 module. Please add import base64 to make the example fully self-contained and runnable.

Suggested change

	from pdr_parser import parse_pdr, verify_pdr
	pdr = parse_pdr(base64.b64decode(pdr_b64))
	is_valid = verify_pdr(pdr, notary_pubkey="490f51f2...")
	# is_valid = True → signature matches, PDR is authentic
	import base64
	from pdr_parser import parse_pdr, verify_pdr
	pdr = parse_pdr(base64.b64decode(pdr_b64))
	is_valid = verify_pdr(pdr, notary_pubkey="490f51f2...")
	# is_valid = True -> signature matches, PDR is authentic

[gemini-code-assist]

The description states that the x402.payment.status metadata field is extended with a provenance-attached state, but the JSON example below shows x402.payment.status as "payment-complete" and introduces a new field "x402.provenance.status": "provenance-attached". Please update the description to clarify that a new metadata field x402.provenance.status is introduced.

[gemini-code-assist]

The field name in the PDR format table is listed as payload_hash, but the protocol flow steps (e.g., Step 1 and Step 4) refer to it as work_hash. To avoid confusion, please clarify in the table or the text that payload_hash corresponds to the work_hash computed by the Merchant Agent.