DEV Community: GitSerge-crypto

Two signatures are better than one — bilateral provenance for AI agents

GitSerge-crypto — Sun, 05 Jul 2026 07:44:52 +0000

Two signatures are better than one — bilateral provenance for AI agents

An AI agent produces a financial report. You notarize it — a 239-byte cryptographic record, signed by an independent notary, anchored on NEAR. The record proves: this hash existed at this timestamp, and $0.01 USDC was paid for the attestation.

A week later, someone asks the obvious question: who proved the agent wrote the report?

Nobody. The notary signed a hash the client submitted. Anyone could have submitted that hash. The PDR proves the hash existed — not that the agent authored the content behind it.

This is the gap Bilateral Signature (v0x04) closes. The agent signs its own work hash with its Ed25519 key. That signature gets fused into the PDR. Now the record carries two independent signatures — agent and notary — and neither party can repudiate.

The binding hash

The mechanism is a single hash:

binding_hash = sha256(work_hash + sig_A + agent_pubkey)

work_hash — SHA-256 of the agent's output (32 bytes)
sig_A — agent's Ed25519 signature over work_hash, NEP-413 standard (64 bytes)
agent_pubkey — agent's Ed25519 public key (32 bytes)

This binding hash replaces work_hash in the PDR's payload_hash field. The notary then signs the full 175-byte payload — which already contains the binding hash. So the notary's signature covers a record that embeds the agent's signature inside it.

To forge a v0x04 PDR, you need two private keys: the notary's Ed25519 seed and the agent's Ed25519 key. With the ordinary v0x03, you only need the notary's. Bilateral doubles the compromise requirement.

What actually changed

Almost nothing structurally — and that's the point.

	v0x03 (ordinary)	v0x04 (bilateral)
Version byte	`0x03`	`0x04`
`payload_hash`	`sha256(work_result)`	binding hash
Agent signature	not required	Ed25519 over work_hash
Size	239 bytes	239 bytes
Price	$0.01	$0.01

Same binary layout. Same 239 bytes. Same NEP-413 notary signature. The parser handles both by checking the version byte. All 9 existing mainnet PDRs (v0x03) remain valid — no migration, no fork.

The notary auto-selects the version: if the request includes agent_sig + agent_pubkey → v0x04. If not → v0x03. No explicit version parameter.

The agent signs first

Before anything reaches the notary, the agent signs its own work hash:

import hashlib, struct, base64
from nacl.signing import SigningKey

# Agent's Ed25519 key
agent_key = SigningKey(bytes(32))  # use your real key
agent_pubkey_hex = agent_key.verify_key.encode().hex()

# Agent produced this output
report = b"Q3 revenue projection: $2.4M based on agent analysis..."
work_hash = hashlib.sha256(report).digest()

# NEP-413: Tag(u32 LE) + Len(u32 LE) + message — raw, no pre-hash
nep413_buffer = struct.pack("<II", 2147484061, len(work_hash)) + work_hash
agent_sig = agent_key.sign(nep413_buffer).signature
agent_sig_b64 = base64.b64encode(agent_sig).decode()

NEP-413 signs the raw buffer — no SHA-256 pre-hash. The signature covers Tag + Len + work_hash_bytes directly. Same standard NEAR uses for transaction signing.

Notarize with the agent signature

curl -s https://api.aotrust.link/v1/notarize \
  -H "Content-Type: application/json" \
  -H "X-Payment: <base64-encoded EIP-3009 payload>" \
  -d '{
    "work_hash": "a1b2c3d4...sha256_of_output...",
    "agent_sig": "BASE64_AGENT_ED25519_SIGNATURE",
    "agent_pubkey": "HEX_AGENT_ED25519_PUBLIC_KEY"
  }'

Inside the notary:

Verifies sig_A against agent_pubkey — before payment, before anything else
Verifies EIP-3009 payment on Base (~2s)
Computes binding_hash = sha256(work_hash + sig_A + agent_pubkey)
Builds 239-byte PDR — version 0x04, binding hash in payload_hash
Signs the 175-byte payload with notary Ed25519 key
Returns base64 PDR

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "notarized",
  "pdr_b64": "BQFCAUJ...239_bytes_base64..."
}

The PDR starts with BQ — base64 for 0x04 0x01 (version=bilateral, scheme=Ed25519). An ordinary PDR starts with Aw (0x03 0x01). You can tell which version at a glance.

Two independent verification paths

This is the real payoff. After notarization, you have two separate cryptographic proofs — each verifiable independently, each requiring a different public key.

Path 1: Notary signature (the PDR itself)

curl -s "https://api.aotrust.link/v1/pdr/verify/BQFCAUJ...your_pdr_b64..."

{
  "valid": true,
  "version": 4,
  "binding_hash": true,
  "payload_hash": "b3c4d5e6...",
  "timestamp_utc": 1751700000,
  "payment_anchor_type": 5,
  "anchor": { "near_tx": "H4MaR5...", "confirmed": true }
}

Or fully offline — the parser is a single Python file, zero dependencies:

curl -sO https://raw.githubusercontent.com/GitSerge-crypto/aotrust-skills/main/pdr_parser.py

python3 pdr_parser.py --pdr "BQFCAUJ..." \
  --pubkey "490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462"

PDR v2.4 — Valid ✓
  version:           4 (bilateral)
  payload_hash:      b3c4d5e6... (binding hash)
  signature:         VALID (Ed25519/NEP-413)

This proves: the notary signed the record, the payment was verified, the timestamp is attested, and the record is anchored on NEAR.

Path 2: Agent signature (stored in ledger)

The agent's sig_A isn't in the PDR binary — it's in the notary ledger (the PDR contains the binding hash, not the raw signature). To verify agent authorship:

import struct, base64
from nacl.signing import VerifyKey

agent_sig_b64 = "BASE64_AGENT_SIG"      # from notarize response / DB
agent_pubkey_hex = "HEX_AGENT_PUBKEY"
work_hash_hex = "a1b2c3d4...your_work_hash..."

work_hash = bytes.fromhex(work_hash_hex)
nep413_buffer = struct.pack("<II", 2147484061, len(work_hash)) + work_hash

vk = VerifyKey(bytes.fromhex(agent_pubkey_hex))
vk.verify(nep413_buffer, base64.b64decode(agent_sig_b64))
# → no exception = valid

This proves: the agent's Ed25519 key signed this specific work_hash. The agent cannot deny authorship.

Two signatures. Two keys. Two independent proofs. Forged by compromising either party alone? No. The binding hash ties them together — the notary's signature covers a payload that contains the agent's signature fused into the hash.

When to use bilateral

If the agent has an Ed25519 key — use v0x04. The cost is identical ($0.01), the size is identical (239 bytes), and you get non-repudiation for free.

If the agent has no key (third-party notarizing someone else's work, bulk timestamping) — v0x03 is fine. It's proof-of-existence without identity binding.

The interesting case is multi-agent pipelines. Agent A produces output, agent B refines it, agent C compiles the final report. Each stage can be notarized with a bilateral PDR signed by that stage's agent key. You get a chain of custody where every link has its own Ed25519 signature bound into the record — and the notary attests each link independently.

Backward compatibility

The parser handles both versions transparently:

from pdr_parser import parse_external_pdr

parsed = parse_external_pdr(base64.b64decode(pdr_b64))

if parsed.version == 0x03:
    payload = "work_hash"
elif parsed.version == 0x04:
    payload = "binding hash"

9 existing mainnet PDRs are v0x03. They stay v0x03. New bilateral PDRs are v0x04. No migration, no re-issuance. The version byte is the only thing the parser branches on.

Spec and parser

PDR spec (v2.3 + v2.4): pdr-spec.md
Standalone parser: pdr_parser.py — MIT, zero dependencies, handles v0x02/v0x03/v0x04

Try it

# Health check (no auth)
curl -s https://api.aotrust.link/health

# Get a quote — see the 402 response
curl -s https://api.aotrust.link/v1/notarize/quote \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"0000000000000000000000000000000000000000000000000000000000000000"}'

# MCP discovery (4 tools: notary_quote, notary_notarize, notary_verify, notary_notarize_paid)
curl -s https://api.aotrust.link/.well-known/mcp.json

# Verify page — paste any PDR base64
# https://verify.aotrust.link

API: api.aotrust.link
Docs: docs.aotrust.link
MCP: api.aotrust.link/mcp
Source: github.com/GitSerge-crypto/aotrust-skills

The service is live on mainnet. Bilateral PDRs (v0x04) are supported as of July 2026 — same price, same size, same verification flow. The agent proves it wrote the work. The notary proves it was notarized. Both are math.

How to prove an AI agent output existed — x402 + NEAR anchoring in practice

GitSerge-crypto — Sat, 27 Jun 2026 20:35:22 +0000

How to prove an AI agent output existed — x402 + NEAR anchoring in practice

Why this matters

You deployed an AI agent. It generated a financial report, a code review, a medical summary. A week later, someone questions the output. Did the agent actually produce this? When? Was it modified after the fact?

Logs are mutable. Timestamps lie. Git history can be rewritten.

What you need is a cryptographic proof — signed by an independent notary — that binds a specific artifact hash to a specific point in time. And it should cost less than a cent.

This article walks through a real, working system: AOTrust, a notarization service that issues PDRs (Provenance Data Records) for $0.01 USDC via x402 on Base L2, with Merkle anchoring on NEAR.

What you need

A Base wallet with $0.01 USDC (10,000 micro-USDC)
curl and python3 (for hashing)
No API key. No account. No signup.

The x402 protocol handles payment inline — the API returns HTTP 402, you pay, you retry with the payment header. No billing portal, no subscription, no prepaid credits.

Step 1 — Hash your agent output

import hashlib

# Your agent produced this report
report = b"The Q3 revenue projection based on agent analysis is $2.4M..."

work_hash = hashlib.sha256(report).hexdigest()
print(work_hash)
# → e.g. "a1b2c3d4e5f6...64 hex chars..."

The hash is what gets notarized. You keep the actual artifact — the notary never sees it. This is a blind notarization: the PDR proves the hash existed at a point in time, without revealing the content.

Step 2 — Request a quote (HTTP 402)

curl -s https://api.aotrust.link/v1/notarize/quote \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"a1b2c3d4e5f6...your_sha256_hash..."}'

The API responds with HTTP 402 — Payment Required — in x402 format:

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "10000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA5fE48",
    "resource": "https://api.aotrust.link/v1/notarize"
  }]
}

That maxAmountRequired: 10000 is 10,000 micro-USDC = $0.01. The asset address is USDC on Base. No negotiation, no tiers — flat fee.

Step 3 — Pay and notarize in one call

Sign an EIP-3009 transferWithAuthorization message with your Base wallet (any wallet that supports EIP-3009 — most do). Then send the notarization request with the payment attached:

curl -s https://api.aotrust.link/v1/notarize \
  -H "Content-Type: application/json" \
  -H "X-Payment: <base64-encoded EIP-3009 payload>" \
  -d '{
    "work_hash": "a1b2c3d4e5f6...your_sha256_hash...",
    "agent_account": "your-agent.near",
    "tx_hash": "0x1234...evm_tx_hash_of_usdc_transfer..."
  }'

What happens inside the notary:

Verifies the EIP-3009 signature on-chain (Base L2, ~2s)
Confirms 10,000 micro-USDC reached the sink address
Builds a 239-byte PDR containing your work hash, timestamp, payment hash, and notary signature
Signs the PDR with Ed25519 (NEP-413 standard)
Returns the PDR as base64

Response (HTTP 200):

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "notarized",
  "network": "base",
  "pdr_b64": "AwFCAUJ...base64-encoded 239-byte PDR..."
}

The entire flow takes 2–5 seconds. No polling, no webhooks.

Step 4 — Verify the PDR (offline, no API needed)

The PDR is a 239-byte binary record. The Ed25519 signature is self-contained — you can verify it without calling any API.

Quick check via API (public, no auth)

curl -s "https://api.aotrust.link/v1/pdr/verify/AwFCAUJ...your_pdr_b64..."

{
  "valid": true,
  "version": 3,
  "sig_scheme": 1,
  "payment_anchor_type": 5,
  "timestamp_utc": 1718900000,
  "issuer_id": "notary-node.near",
  "subject_hash": "a1b2...",
  "payload_hash": "b3c4...",
  "merkle_root": "d5e6...",
  "payment_hash": "f7a8...",
  "notary_pubkey": "490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462",
  "anchor": {
    "near_tx": "H4MaR5...",
    "confirmed": true
  }
}

Full offline verification

The PDR binary format is an open standard. The parser is a single Python file with zero dependencies:

# Install the parser
curl -sO https://raw.githubusercontent.com/GitSerge-crypto/aotrust-skills/main/pdr_parser.py

# Verify any PDR offline
python3 pdr_parser.py --pdr "AwFCAUJ...your_pdr_b64..." \
  --pubkey "490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462"

Output:

PDR v2.3 — Valid ✓
  version:           3
  sig_scheme:        Ed25519
  payment_anchor:    X402_BASE (0x05)
  timestamp:         2026-06-20 14:32:11 UTC
  issuer:            notary-node.near
  subject_hash:      a1b2c3d4...
  payload_hash:      b3c4d5e6...
  merkle_root:       d5e6f7a8...
  payment_hash:      f7a8b9c0...
  signature:         VALID (Ed25519/NEP-413)

No network calls. No API keys. No trust in any server. The signature is math.

Step 5 — On-chain anchor (NEAR Mainnet)

The notary batches PDRs into Merkle trees every ~16 minutes and anchors the root on NEAR:

PDR₁ ─┐
PDR₂ ─┤── Merkle Tree ── Root ── NEAR tx (merkle_anchor contract)
PDR₃ ─┤
PDR₄ ─┘

This means:

Your PDR's merkle_root field matches a NEAR transaction
The NEAR tx is verifiable on nearblocks.io
The Merkle proof (your PDR is a leaf) can be reconstructed from the batch

You don't need to wait for anchoring to trust the PDR — the Ed25519 signature is immediate. The anchor adds a second layer: independent on-chain timestamp via NEAR consensus.

The PDR format (open standard)

239 bytes, 10 fields, fully specified:

Offset	Field	Size	Content
0	version	1	0x03
1	sig_scheme	1	0x01 (Ed25519)
2	payment_anchor_type	1	0x05 (X402_BASE)
3	timestamp_utc	8	Unix seconds
11	issuer_id	36	notary-node.near (NUL-padded)
47	subject_hash	32	SHA-256 of agent account
79	payload_hash	32	SHA-256 of work artifact
111	merkle_root	32	Merkle batch anchor
143	payment_hash	32	EVM tx hash (Base)
175	signature	64	Ed25519 (NEP-413)

The payment_anchor_type is inside the signed payload. This means the PDR self-proves how it was paid for — no external metadata needed. A PDR with 0x05 cryptographically guarantees it was an x402 Base USDC payment.

Spec: pdr-spec.md
Parser: pdr_parser.py (standalone, MIT)

Real PDRs on mainnet

This is not a demo. 9 PDRs have been issued on Base Mainnet, all anchored to NEAR:

3 anchor transactions on NEAR mainnet
All verifiable at verify.aotrust.link
Notary public key: 490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462

When to use this

Scenario	Why PDR helps
AI agent produces a financial report	Prove the report existed at time T, unmodified
Code review by autonomous agent	Cryptographic receipt of review output
Agent-generated medical summary	Timestamp + integrity proof for audit trail
Multi-agent pipeline (A→B→C)	Each stage notarized → full chain of custody
Agent dispute resolution	"Did the agent say X at time T?" → PDR answers
Compliance / regulatory	Signed timestamp from independent notary

What this is not

Not a storage service — the notary never sees your artifact, only its hash
Not an oracle — no external data feeds, no smart contract queries
Not a blockchain — PDRs are off-chain binary records with on-chain anchors
Not zero-knowledge — the hash is public in the PDR (but the preimage is not)

MCP integration (for agent frameworks)

If your agent speaks MCP (Model Context Protocol), AOTrust exposes 4 tools:

{
  "tools": [
    {"name": "notary_quote", "description": "Get quote — amount, payment details"},
    {"name": "notary_notarize_paid", "description": "Notarize with x402 payment on Base"},
    {"name": "notary_verify", "description": "Verify any PDR — signature + on-chain anchor"},
    {"name": "notary_notarize", "description": "Notarize without payment (testnet only)"}
  ]
}

MCP endpoint: https://api.aotrust.link/mcp (Streamable HTTP, OAuth 2.1)

Agent flow:

Agent calls notary_quote → gets amount ($0.01) and payment details
Agent signs EIP-3009 transfer on Base
Agent calls notary_notarize_paid with payment + work_hash
Agent receives PDR (239 bytes, base64)
Agent (or any third party) calls notary_verify to confirm

Comparison

Approach	Cost	Self-verifying	On-chain anchor	Setup
Chainlink oracle	$0.25–$1.00+	No	Yes	Smart contract
Manual timestamp tx	gas cost	No	Yes	Manual
IPFS pin	free	No	No	IPFS node
Git commit	free	No	No	Git repo
AOTrust PDR	$0.01	Yes (Ed25519)	Yes (NEAR)	curl

Try it right now

# Health check (no auth)
curl -s https://api.aotrust.link/health

# Get a quote (no auth, no signup)
curl -s https://api.aotrust.link/v1/notarize/quote \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"0000000000000000000000000000000000000000000000000000000000000000"}'

# MCP discovery
curl -s https://api.aotrust.link/.well-known/mcp.json

# x402 discovery
curl -s https://api.aotrust.link/.well-known/x402

Cryptographic proof-of-existence for AI agent outputs — $0.01 per record via x402

GitSerge-crypto — Sun, 21 Jun 2026 15:27:56 +0000

Cryptographic proof-of-existence for AI agent outputs — $0.01 per record

The problem

AI agents generate code, reports, analyses, and decisions. When a dispute arises — "did the agent produce this output at this time, or was it retroactively edited?" — there is no answer. Logs can be tampered with. Timestamps can be changed. Hallucinations go undetected because there is no cryptographic binding between what was generated and when it was generated.

Existing oracle solutions cost $0.25–$1.00+ per call and require complex smart contract integrations. That is too expensive for per-output notarization of autonomous agents running thousands of tasks.

What I built

AOTrust — a notarization service that issues a PDR (Provenance Data Record) for exactly $0.01 USDC on Base L2, using the HTTP 402 protocol.

A PDR is a 239-byte binary record containing:

Field	Size	Content
version	1B	0x03
sig_scheme	1B	Ed25519
payment_anchor_type	1B	0x05 (X402_BASE)
timestamp	8B	Unix seconds
issuer_id	36B	notary-node.near (NUL-padded)
subject_hash	32B	SHA-256 of agent account
payload_hash	32B	SHA-256 of work artifact
merkle_root	32B	Merkle root (batch anchor)
payment_hash	32B	EVM tx hash (Base)
signature	64B	Ed25519 (NEP-413)

The entire payload (175 bytes) is signed with the notary's Ed25519 key. The signature covers the payment anchor type — so the PDR is self-verifying without external metadata.

How it works (architecture)

Agent                     AOTrust API              NEAR Mainnet
  |                          |                        |
  |--- 1. POST /quote ------>|                        |
  |<--- 2. 402 + x402 -------|                        |
  |--- 3. EIP-3009 sign ---->|                        |
  |--- 4. POST + payment --->|                        |
  |                          |--- 5. verify payment -->|  (Base L2)
  |                          |--- 6. build PDR ------->|
  |                          |--- 7. Ed25519 sign ---->|
  |<--- 8. PDR (239B) -------|                        |
  |                          |                        |
  |                          |--- 9. Merkle anchor ---->|  (NEAR tx)
  |                          |                        |
  |--- 10. GET /verify ------>|                        |
  |<--- 11. valid + anchor ---|                        |

Steps 1–8 happen synchronously (~2-5 seconds). Step 9 (Merkle anchoring) happens in batches every ~16 minutes — multiple PDRs are combined into a Merkle tree, and the root is anchored on NEAR mainnet via the merkle_anchor contract on notary-node.near.

Working example (curl)

1. Get a quote

curl -s https://api.aotrust.link/v1/notarize/quote \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"a1b2c3d4...your_sha256_hash..."}'

Response (HTTP 402 — payment required):

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "10000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA5fE48",
    "resource": "https://api.aotrust.link/v1/notarize"
  }]
}

maxAmountRequired: 10000 = 10,000 micro-USDC = $0.01.

2. Pay via x402 (EIP-3009 transferWithAuthorization)

Sign an EIP-3009 message with your Base wallet, then:

curl -s https://api.aotrust.link/v1/notarize \
  -H "Content-Type: application/json" \
  -H "X-Payment: <base64-encoded EIP-3009 payload>" \
  -d '{
    "work_hash": "<sha256 of your work artifact>",
    "agent_account": "your-agent.near",
    "tx_hash": "<evm tx hash of the USDC transfer>"
  }'

3. Receive PDR

Response (HTTP 200):

{
  "job_id": "a1b2c3d4-e5f6-...",
  "status": "notarized",
  "network": "base",
  "pdr_b64": "AwE...base64-encoded 239-byte PDR..."
}

4. Verify any PDR (public, no auth)

curl -s https://api.aotrust.link/v1/pdr/verify/<pdr_b64>

Response:

{
  "valid": true,
  "version": 3,
  "sig_scheme": 1,
  "payment_anchor_type": 5,
  "timestamp_utc": 1718900000,
  "issuer_id": "notary-node.near",
  "subject_hash": "a1b2...",
  "payload_hash": "b3c4...",
  "merkle_root": "d5e6...",
  "payment_hash": "f7a8...",
  "notary_pubkey": "490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462",
  "anchor": {
    "near_tx": "H4MaR5...",
    "confirmed": true
  }
}

You can verify the PDR offline — the Ed25519 signature is self-contained. The on-chain anchor is a bonus: it proves the Merkle root was published on NEAR at a specific block height.

Live PDR

A real PDR issued on Base Mainnet, already anchored to NEAR:

Verify page: https://verify.aotrust.link/?pdr=AwFCA... (paste any PDR from the API)
Notary public key: 490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462
NEAR anchor TXs: H4MaR5..., G9yzNh..., DEAhnxo... (3 batches, 9 PDRs total)

MCP integration (for AI agents)

AOTrust also exposes an MCP (Model Context Protocol) endpoint at https://api.aotrust.link/mcp. Agents can discover and call 4 tools:

Tool	Description
`notary_quote`	Get quote (amount, payment details)
`notary_notarize_paid`	Notarize with x402 payment on Base
`notary_verify`	Verify any PDR (signature + on-chain anchor)
`notary_notarize`	Notarize without payment (testnet only)

MCP transport: Streamable HTTP (SSE). Auth: OAuth 2.1 + x402 payment.

The flow for an autonomous agent:

Agent calls notary_quote → gets amount ($0.01) and payment details
Agent signs EIP-3009 transfer on Base (via wallet integration)
Agent calls notary_notarize_paid with payment + work_hash
Agent receives PDR (239 bytes, base64)
Agent (or any third party) calls notary_verify to confirm

What makes this different

Approach	Cost	On-chain proof	Self-verifying
Chainlink oracle	$0.25–$1.00+	Yes	No (requires oracle network)
Manual timestamp tx	gas cost	Yes	No (just a timestamp)
IPFS pin	free	No	No (mutable)
AOTrust PDR	$0.01	Yes (NEAR anchor)	Yes (Ed25519 in PDR)

The key insight: the payment anchor type (0x05 = X402_BASE) is inside the signed binary payload. This means the PDR itself proves how it was paid for, not just that it was paid. No external metadata channel required.

Open standard

The PDR v2.3 binary format is published as an 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 dependencies, CLI)
Skill: https://github.com/GitSerge-crypto/aotrust-skills/blob/main/aotrust-notarize/SKILL.md (agent-ready)
License: MIT

Anyone can build a PDR-compatible notary. The format supports multiple payment rails: NEAR direct, x402 on Base, x402 on Polygon, Agent Market escrow (provisional → settled), and reserved slots for future chains.

Current status

Mainnet live since June 9, 2026
9 PDRs issued, all X402_BASE, all anchored to NEAR (3 anchor transactions)
4 services running: API (8741), MCP (8746), testnet API (8743), testnet MCP (8745)
MCP listed on Glama.ai: https://glama.ai/mcp/servers/GitSerge-crypto/aotrust-skills
Price: flat $0.01 USDC per PDR, no API key required for x402 flow
0 customers, 0 revenue — this is a new product looking for early adopters

Try it

# Health check
curl -s https://api.aotrust.link/health

# Get a quote (no auth needed)
curl -s https://api.aotrust.link/v1/notarize/quote \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"0000000000000000000000000000000000000000000000000000000000000000"}'

# MCP discovery
curl -s https://api.aotrust.link/.well-known/mcp.json

If you are building autonomous AI agents and need cryptographic proof of output integrity, I would love to hear your use case. The service is live, the API is stable, and the first 9 PDRs are on mainnet.

Follow the project: GitHub | Verify | Docs | Glama

AI agents hallucinate. Here is how to cryptographically notarize their output for $0.01

GitSerge-crypto — Tue, 16 Jun 2026 17:40:34 +0000

We have a growing problem in the autonomous AI agent space: Garbage in, garbage out, and no proof of when it happened.

When your AI agent generates source code, analyzes market data, or creates a financial report, how do you mathematically prove that this specific artifact was generated at a specific time? How do you prove to your clients that the output wasn't retroactively edited before a dispute?

I wanted a "notary stamp" for AI agents. But existing oracle solutions are too expensive (often $0.25 - $1.00+ per call) and require complex smart contract integrations.

So, as a solo developer, I built AOTrust.

It does exactly one thing: it issues a PDR (Provenance Data Record) for exactly $0.01 USDC on Base L2, using the HTTP 402 protocol.

What is a PDR?

A PDR is a highly optimized 239-byte cryptographic receipt. It proves that a specific digital artifact existed at a specific point in time.

It contains:

The SHA-256 hash of your agent's work output.
A precise UNIX timestamp.
An on-chain payment anchor (your $0.01 USDC transfer on Base).
An Ed25519 signature from the notary node.
A Merkle root anchored daily to the NEAR blockchain.

Privacy first: You never upload your actual artifact or AI prompt. You only send the SHA-256 hash.

How it works (No heavy SDKs required)

I designed this to be integrated into any agentic workflow (Python, TS, Rust) using standard HTTP requests. It uses the x402 payment protocol.

Here is the entire integration in 3 steps:

Step 1: Hash your artifact

First, your agent hashes its output locally.

import hashlib
work_hash = hashlib.sha256(b"your agent's JSON output").hexdigest()

Step 2: Request Notarization (Get a Quote)

Send the hash to the API. Because AOTrust is a payment-bound proof layer, the
server will intentionally reject it with an HTTP 402 Payment Required status,
returning the payment instructions.

curl -X POST https://api.aotrust.link/notarize \
-H "Content-Type: application/json" \
-d '{"work_hash":"YOUR_SHA256_HEX"}'

Response (HTTP 402):

{
"payTo": "0x97E9af6B...Ab8Cc800",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base
"maxAmountRequired": "10000", // $0.01 (6 decimals)
"network": "eip155:8453",
"maxTimeoutSeconds": 300
}

Step 3: Pay and Get Your Proof

Your agent signs an EIP-3009 transferWithAuthorization with its Ethereum wallet
to authorize the $0.01 payment. Encode the signature and send it in the
x-payment header.

curl -X POST https://api.aotrust.link/notarize \
-H "Content-Type: application/json" \
-H "x-payment: YOUR_BASE64URL_ENCODED_SIGNATURE" \
-d '{"work_hash":"YOUR_SHA256_HEX"}'

Response (HTTP 200):

{
"job_id": "550e8400-e29b-41d4-a716-446655440000",
"pdr_b64": "AwEFA1kuagAAAABub3...",
"payment_anchor_type": "X402_BASE"
}

Boom. You just received your 239-byte cryptographic proof (pdr_b64).

Verifying the Proof

You can pass this job_id or the raw base64 string to your clients or users.
Anyone can verify the cryptographic seal instantly without an account, API keys,
or paying any fees:

verify.aotrust.link

Why build this?

If you are building autonomous agents, integrating them into marketplaces, or
generating automated financial/audit reports, trust is your biggest bottleneck.
By appending an AOTrust PDR to your agent's deliverable, you give your clients
an un-fakable, third-party verified timestamp of the work.

I’m currently running the mainnet infrastructure. If you are building agentic
workflows and need an immutable audit trail, I’d love to hear your thoughts on
this API flow!

Docs: docs.aotrust.link GitHub (Specs & Parser):
github.com/GitSerge-crypto/aotrust-skills

DEV Community: GitSerge-crypto

Two signatures are better than one — bilateral provenance for AI agents

Two signatures are better than one — bilateral provenance for AI agents

The binding hash

What actually changed

The agent signs first

Notarize with the agent signature

Two independent verification paths

Path 1: Notary signature (the PDR itself)

Path 2: Agent signature (stored in ledger)

When to use bilateral

Backward compatibility

Spec and parser

Try it

How to prove an AI agent output existed — x402 + NEAR anchoring in practice

How to prove an AI agent output existed — x402 + NEAR anchoring in practice

Why this matters

What you need

Step 1 — Hash your agent output

Step 2 — Request a quote (HTTP 402)

Step 3 — Pay and notarize in one call

Step 4 — Verify the PDR (offline, no API needed)

Quick check via API (public, no auth)

Full offline verification

Step 5 — On-chain anchor (NEAR Mainnet)

The PDR format (open standard)

Real PDRs on mainnet

When to use this

What this is not

MCP integration (for agent frameworks)

Comparison

Try it right now

Links

Cryptographic proof-of-existence for AI agent outputs — $0.01 per record via x402

Cryptographic proof-of-existence for AI agent outputs — $0.01 per record

The problem

What I built

How it works (architecture)

Working example (curl)

1. Get a quote

2. Pay via x402 (EIP-3009 transferWithAuthorization)

3. Receive PDR

4. Verify any PDR (public, no auth)

Live PDR

MCP integration (for AI agents)

What makes this different

Open standard

Current status

Try it

AI agents hallucinate. Here is how to cryptographically notarize their output for $0.01

What is a PDR?

How it works (No heavy SDKs required)

Step 1: Hash your artifact