编程

AOTrust — PDR Notarization

试用

Issue a cryptographic proof (PDR) that a digital artifact existed at a specific time. Pay $0.01 USDC on Base via x402. Anchored daily to NEAR blockchain. Publicly verifiable. ONLY invoke when the user explicitly requests notarization or proof-of-existence for a specific artifact. This skill performs

它能做什么

Issue a cryptographic proof (PDR) that a digital artifact existed at a specific time. Pay $0.01 USDC on Base via x402. Anchored daily to NEAR blockchain. Publicly verifiable. ONLY invoke when the user explicitly requests notarization or proof-of-existence for a specific artifact. This skill performs a paid external API call ($0.01 USDC, irreversible). Do NOT invoke proactively or as part of unrelated workflows.

技能文档

AOTrust — Cryptographic Proof of Existence

This skill interacts with an external paid API. Read this before invoking.

What leaves your machineWhere it goesReversible?
work_hash (SHA-256 of your artifact)api.aotrust.linkNo — hash is public in the PDR
agent_sig + agent_pubkey (optional, bilateral)api.aotrust.linkNo — stored in notary ledger
EIP-3009 payment signatureBase Mainnet (on-chain)No — $0.01 USDC, irreversible

Rules:

  • Confirm with the user before notarizing. Show the artifact hash and ask: "Notarize this for $0.01 USDC?"
  • Never use an unattended wallet. Payment requires manual approval for every transaction.
  • Do not let the agent manage private keys. The user signs EIP-3009 manually or via a wallet that requires confirmation.
  • The artifact itself is never uploaded — only its hash. But the hash is public in the PDR and on NEAR blockchain.

A PDR (Provenance Data Record) is a 239-byte cryptographic receipt proving that a digital artifact existed at a specific point in time.

Works with any digital artifact: emails, documents, contracts, source code, AI outputs, research notes, datasets, photos, logs, sensor readings.

The artifact itself is never uploaded — only its SHA-256 hash.

Anchored daily to NEAR blockchain. $0.01 per proof. No account needed.

Two Ways to Connect

InterfaceBest forHow
MCP (recommended for AI agents)AI agents with MCP supportOAuth 2.1 → tools/list → notary_quote → HTTP /notarize (pay) → notary_verify
HTTP API (for developers)Direct integration, scripts, CI/CDPOST /notarize → 402 → pay → 200

Both interfaces produce the same PDR. Pick one.


Interface 1: MCP (for AI Agents)

Endpoint

https://api.aotrust.link/mcp

Authentication

OAuth 2.1 with PKCE (S256). Discovery:

  • Resource: https://api.aotrust.link/.well-known/oauth-protected-resource/mcp
  • Authorization server: https://api.aotrust.link/.well-known/oauth-authorization-server
  • Register client: POST https://api.aotrust.link/oauth/register
  • Authorize: GET https://api.aotrust.link/oauth/authorize
  • Token: POST https://api.aotrust.link/oauth/token

Available Tools (5)

ToolPurposePayment?
notary_freeCreate instant free cryptographic proof (UNPAID PDR), rate limited (5/IP/day)Free
notary_quoteGet price + payment details for a work_hashFree
notary_notarizeNEAR_DIRECT payment (not available on mainnet)
notary_notarize_paidx402 USDC — discovery only, cannot be called via MCP (see flow below)$0.01 USDC
notary_verifyVerify a notarization by job_idFree

MCP Flow — Free Tier (no wallet, 1 step)

For instant free proof without payment:

  1. MCP: Call notary_free with work_hash (64 hex) → get shield_id, pdr_b64, verify_url
  2. Done. No wallet, no payment. Rate limited: 5/IP/day, 1000/day global.

For on-chain settlement proof (payment-bound PDR with tx_hash on Base), use the paid flow below.

MCP Flow (x402 USDC — paid, on-chain settlement)

x402 payment requires HTTP calls — MCP tool calls alone cannot complete the flow:

  1. MCP: Call notary_quote with work_hash (see "Step 1: Compute the Work Hash" below) → get price ($0.01 USDC) and quote details
  2. HTTP: POST to https://api.aotrust.link/notarize with {"work_hash": "..."} → get 402 payment requirements (see Step 2 below for format)
  3. HTTP: Sign EIP-3009 transferWithAuthorization with your Ethereum key, then POST to https://api.aotrust.link/notarize again with x-payment header → get 200 + PDR (see Step 3 below for format)
  4. MCP: Call notary_verify with the job_id from step 3 → confirm anchored

Note: notary_notarize_paid appears in tools/list for discovery but cannot be called via MCP — x402 payment headers are not supported in MCP tool calls. Use HTTP POST /notarize for the actual payment step.


Interface 2: HTTP API (for Developers)

Step 1: Compute the Work Hash

Hash your artifact with SHA-256. This is what gets notarized — not the artifact itself.

Key principle: The hash must be reproducible by a third party who has the same artifact. Hash the artifact content directly — not metadata about it, not the HTTP response, not the chat history.

What to hash (by artifact type)

Artifact typeWhat to hashPython example
AI text outputThe raw response text, UTF-8 encodedhashlib.sha256(response_text.encode('utf-8')).hexdigest()
Source code fileThe file content as byteshashlib.sha256(open('main.py','rb').read()).hexdigest()
JSON dataCanonical JSON (sorted keys, no whitespace)hashlib.sha256(json.dumps(data, sort_keys=True, separators=(',',':')).encode()).hexdigest()
Binary file (image, PDF, etc.)The file bytes directlyhashlib.sha256(open('screenshot.png','rb').read()).hexdigest()
Agent decisionThe specific decision string, not the full loghashlib.sha256(decision_text.encode('utf-8')).hexdigest()
Structured outputThe serialized output string (deterministic format)hashlib.sha256(str(output).encode('utf-8')).hexdigest()

Common mistakes

  • ❌ Hashing the HTTP response (includes headers, status code) — hash only the body
  • ❌ Hashing the chat history (includes user messages) — hash only the AI output
  • ❌ Hashing with different encoding each time — always use UTF-8 for text
  • ❌ Hashing the file path string — hash the file content bytes
  • ✅ Hash exactly the bytes that constitute the artifact, nothing more, nothing less

Step 2: Request Notarization (expect HTTP 402)

curl -X POST https://api.aotrust.link/notarize \
  -H "Content-Type: application/json" \
  -d '{"work_hash":"YOUR_SHA256_HEX","agent_sig":"","agent_pubkey":""}'
  # agent_sig/agent_pubkey optional — include for Bilateral Signature (v0x04)

Response (HTTP 402):

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "10000",
    "maxTimeoutSeconds": 300,
    "payTo": "0x97E9af6B4d8a49f509DA99afaB954429Ab8Cc800",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "resource": "/notarize",
    "description": "Notarize agent payload. Returns signed PDR.",
    "extra": {"name": "USD Coin", "version": "2"}
  }],
  "error": "Payment required"
}

Payment details are in accepts[0]:

  • scheme: "exact" — pay exactly the specified amount
  • network: "base" — Base Mainnet (chain ID 8453)
  • maxAmountRequired: "10000" — 10000 micro-USDC = $0.01 USDC
  • payTo: where to send payment
  • asset: USDC contract on Base (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)
  • maxTimeoutSeconds: 300 — payment must be made within 5 minutes

Step 3: Pay and Get Your PDR

Sign an EIP-3009 transferWithAuthorization with your Ethereum key:

  • from: your wallet address
  • to: the payTo address from accepts[0] in Step 2
  • value: maxAmountRequired from Step 2 (10000 = $0.01)
  • validAfter: current Unix timestamp
  • validBefore: current time + maxTimeoutSeconds
  • nonce: random 32-byte hex string

Encode the signature as base64url JSON. Send it with 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","agent_sig":"","agent_pubkey":""}'

Response (HTTP 200):

{
  "status": "notarized",
  "job_id": "550e8400-e29b-41d4-a716-446655440000",
  "pdr_b64": "AwEFXRE3agAAAABub3...",
  "tx_hash": "0x3c7133009a74...",
  "payment_anchor_type": "X402_BASE",
  "network": "base"
}

pdr_b64 is your 239-byte cryptographic proof (base64-encoded).

Bilateral Signature (optional, v0x04)

If you want the PDR to cryptographically bind the agent's signature into the record:

  1. Sign your work_hash with your Ed25519 private key using NEP-413 (same as Full Chain)
  2. Include agent_sig (base64) and agent_pubkey (hex) in the POST /notarize body
  3. The notary will produce a v0x04 PDR with a Binding Hash: payload_hash = sha256(work_hash + sig_A + agent_pubkey)
  4. The PDR is still 239 bytes, same price ($0.01), same verification flow

Without agent_sig → ordinary v0x03 PDR (payload_hash = work_hash).

Verify response now includes binding_hash (boolean) and payload_hash (replaces work_hash):

  • v0x03: binding_hash=false, payload_hash=work_hash
  • v0x04: binding_hash=true, payload_hash=binding_hash

Step 4: Verify Your PDR

Go to https://verify.aotrust.link and enter the job_id.

Or verify programmatically:

# By job_id
curl https://api.aotrust.link/v1/notarize/YOUR_JOB_ID/status

Response:

{
  "status": "anchored",
  "result": {
    "pdr_b64": "AwEFA1kuagAAAABub3...",
    "payment_hash": "679e323c",
    "merkle_proof": [],
    "near_anchor_tx": "H4MaR5ctqKcPGV3A7DDjANskum8F7h4jjJtSvgM9ZAGp"
  }
}

Or verify the PDR directly (no job_id needed):

curl https://api.aotrust.link/v1/pdr/verify/YOUR_PDR_B64

Response:

{
  "valid": true,
  "version": 3,
  "payment_anchor_type": "X402_BASE",
  "subject_hash": "0000000000000000000000000000000000000000000000000000000000000000",
  "work_hash": "d8cb8ce666bdc8053b79029116d937ba2c99640f037877fbafa6320092beef6a",
  "timestamp_utc": 1781993821,
  "issuer_id": "notary-node.near",
  "merkle_root": "e4e495d4216391f3f78332870d2c025c70a1dd0b63d24d059ce3ece9aabd5b14",
  "payment_hash": "cd87ee2300000000000000000000000000000000000000000000000000000000",
  "signature_valid": true,
  "tx_verified_on_chain": false,
  "error": null
}

Anyone can verify — no account, no key, no authentication required.


What a PDR Proves

  • ✅ Your artifact (identified by its SHA-256 hash) existed at a specific time
  • ✅ Payment was settled on Base Mainnet (tx_hash verifiable on-chain)
  • ✅ The notary (notary-node.near) signed the record
  • ✅ The record is anchored to NEAR blockchain via daily Merkle root

A PDR does NOT reveal your artifact content — only its hash.

PDR Binary Format (v2.3)

FormatSizePayloadSignature
Internal (server storage)193 bytes129 bytes64 bytes Ed25519
External (client receipt)239 bytes175 bytes64 bytes Ed25519

Version byte: 0x03. Signature: NEP-413 Ed25519 over raw payload.

Full binary spec: https://github.com/GitSerge-crypto/aotrust-skills/blob/main/pdr-spec.md

Example Uses

Personal Records: Email correspondence, family letters, personal notes, photographs. Proves that a specific version of a file existed at a specific time.

AI Outputs: Agent reports, LLM responses, generated code, research summaries. Creates independent evidence of when an AI-generated artifact was produced.

Business Documents: Contracts, proposals, specifications, financial reports. Provides a timestamped provenance record for important documents.

Technical Artifacts: Source code, configuration files, datasets, log files. Creates a verifiable audit trail for technical work.

Compliance and Audit: Regulatory evidence, internal approvals, process documentation. Provides a cryptographically verifiable historical record.

Privacy

AOTrust does not store or publish your artifact content. Only the SHA-256 hash of the artifact is included in the PDR. Anyone can verify the PDR, but the original artifact remains private unless you choose to share it.

Proof of Authorship (Bilateral Signature, v0x04)

By default, AOTrust proves that a hash existed at a specific time. For stronger provenance, clients can sign the artifact hash with their own Ed25519 key before notarization — this produces a bilateral PDR (v0x04) with a binding hash.

This creates a non-repudiable provenance chain: Client Key → Artifact Hash → Binding Hash → AOTrust PDR → Blockchain Anchor

See the Bilateral Signature section under Step 3 above for implementation details.

Useful for: agent reputation, creator attribution, audit trails, dispute resolution, multi-agent pipelines.

The standard PDR workflow (v0x03) remains available and does not require client signatures.


Error Reference

ResponseMeaningAction
HTTP 402Expected — payment requiredProceed to Step 3
HTTP 400Invalid work_hash formatMust be 64-char lowercase hex
HTTP 409Duplicate work_hashAlready notarized — use verify
HTTP 429Rate limitedWait 60 seconds, retry once

Notes


Changelog

  • v3.8.0 — Added notary_free tool for instant free-tier notarization via MCP without wallet. Updated tools table (4→5), added Free Tier MCP Flow section.
  • v3.7.0 — ClawHub security audit fixes: explicit trigger boundaries in description, Security & Consent section (external transmission warnings, user confirmation rules, wallet safety), updated Proof of Authorship from "Planned" to implemented (Bilateral Signature v0x04).
  • v3.6.2 — Bilateral Signature (v0x04): agent_sig + agent_pubkey → binding hash PDR. Verify response: payload_hash + binding_hash fields.
  • v3.6.1 — Added "What to Hash" examples (Step 1), common mistakes section

相关技能

Check the trust rating of any x402 service before paying it, and of any skill before installing it. Free JSON, daily, sybil-resistant.

1 星标

Prove a document existed and was never altered, without uploading it anywhere. Use when your agent produces or receives contracts, invoices, claim documents,...

Verify whether an AI agent or x402 service is real and settlement-backed before paying, hiring, or trusting it. Use whenever about to settle an x402 payment,...

2 星标

在 zooid.fund 上浏览并以 Base 链 USDC 向人道主义众筹活动捐款,支持运营者审核或按计划自主执行。

22 次安装

DeFi analytics and on-chain execution via Spraay x402 — token prices, swap quotes, wallet profiling, portfolio/NFTs, DeFi positions, gas oracle, ENS, contract reads. Plus swap execution and contract writes. USDC micropayments on Base/Solana. Write ops are irreversible.

5 次安装1 星标