DEV Community: GitSerge-crypto

Как защитить макет, ТЗ или код от кражи за 10 центов: личный опыт борьбы с неоплатой на фрилансе

GitSerge-crypto — Sun, 26 Jul 2026 10:25:27 +0000

Как защитить макет, ТЗ или код от кражи за 10 центов: личный опыт борьбы с неоплатой на фрилансе

Каждый фрилансер сталкивался с этой ситуацией: вы отправляете заказчику макет, дизайн-концепт, код или детальное ТЗ, а в ответ получаете молчание или вежливое «к сожалению, мы выбрали другого кандидата». А спустя месяц случайно видите свою работу в готовом проекте заказчика. Без вашего согласия и без оплаты.

Меня зовут Сергей, я разработчик, и хочу рассказать, как решить эту проблему с помощью криптографии и технологии, которую мы изначально создавали для ИИ-агентов.

Почему классические методы больше не работают

Когда на фриланс-форумах кто-то жалуется на кражу работы, обычно советуют:

«Отправляй только картинки с водяными знаками» — сегодня нейросети стирают любые ватермарки с картинок за 3 секунды.
«Отправляй макеты в низком разрешении» — оценить детали интерфейса по размытому файлу невозможно, это выглядит непрофессионально.
«Составляй договор на каждый чих» — ради тестового задания или небольшого концепта за $50–$100 никто не будет привлекать юристов и недели согласовывать документы.

В итоге фрилансер отправляет файлы на свой страх и риск.

Юридическая суть: как доказать авторство

По Бернской конвенции авторское право возникает в момент создания произведения. Вам не нужно регистрировать патент. В любом споре (с заказчиком или арбитражем биржи) вам нужно доказать один факт:

«Этот конкретный файл в неизмененном виде существовал у меня в руках в конкретный день и час — ДО того, как его получил заказчик».

Любой цифровой файл имеет свой уникальный математический отпечаток — хэш SHA-256. Если изменить в файле хотя бы один пиксель или символ, хэш изменится полностью.

От протокола для ИИ-агентов к защите фрилансеров

Изначально мы разрабатывали протокол AOTrust для автономных ИИ-агентов. Когда ИИ генерирует финансовый отчет или программный код, системе нужен независимый артефакт — PDR (Provenance Data Record), подтверждающий факт создания и подпись агента.

В какой-то момент мы поняли, что эта же технология идеально решает проблему фрилансеров — и создали веб-сервис shield.aotrust.link.

Как это работает технически (за 3 шага):

Снятие отпечатка файла (Zero-Knowledge):
Вы перетягиваете файл (макет, архив с кодом, инвойс) на сайт.
Важно: сам файл никуда не загружается на сервер. Сервис считает хэш SHA-256 прямо в вашем браузере с помощью WebCrypto API. Ваша коммерческая тайна остается только на вашем компьютере.
Формирование PDR-сертификата:
Вы оплачиваете $0.10 USDC в сети Base (L2 от Coinbase). Сервер-нотариус подписывает хэш файла своей криптографической подписью Ed25519 и формирует компактный 239-байтовый артефакт PDR.

Не хотите ставить MetaMask? Есть альтернатива: отправьте $0.10 USDC на адрес сервиса с любого кошелька или биржи (Coinbase, Binance, Bybit) и вставьте хэш транзакции. Сервис проверит платёж в блокчейне Base и выдаст сертификат. Никаких расширений, никаких подписей в браузере.

Блокчейн-якорение (NEAR Protocol): Сервис не записывает сам файл или его хэш в блокчейн напрямую. Вместо этого все выпущенные PDR объединяются в дерево Меркла, и только его корень (Merkle Root) периодически записывается в смарт-контракт NEAR Mainnet (notary-node.near). Это дает математическую гарантию: историю записей невозможно подделать задним числом.

Что вы получаете на руки

Вы скачиваете 3-страничный PDF-сертификат:

Страница 1: Имя автора, название файла, его SHA-256 хэш, точное время фиксации (UTC), уникальный Shield ID (8 символов, например f43e2300) и QR-код со ссылкой вида verify.aotrust.link/s/f43e2300 для моментальной проверки.
Страницы 2–3 (Техническая): Полный Base64 PDR-артефакт, подпись автора, публичные ключи сторон, имя нотариуса (notary-node.near) и алгоритм верификации на Python для независимой проверки.

Оффлайн-проверка — это гарантия вечности доказательства. Даже если наш сервис прекратит работу через 10 лет или будет закрыт доступ к нашему сайту, любой независимый специалист или юрист сможет взять этот PDF, подставить ваш оригинальный файл, запустить скрипт локально без интернета и математически убедиться, что отметка времени и подписи подлинны.

Как применять это на практике

При отправке работы клиенту: Вы прикрепляете PDF-сертификат к сообщению с макетом:

«Отправляю готовый концепт. Файл зафиксирован в протоколе AOTrust (сертификат прикреплен). Верифицировать подлинность можно по QR-коду или на странице verify.aotrust.link».

Это показывает ваш профессиональный подход и сразу дает понять заказчику, что зафиксирован факт владения файлом.

При возникновении споров: Если клиент забирает работу и отказывается платить, вы отправляете PDF-сертификат в поддержку биржи (Upwork, Fiverr) или хостинг-провайдеру сайта заказчика вместе с DMCA-жалобой. Независимое математическое доказательство существования файла — главный аргумент в вашу пользу.

Кто это обеспечивает

Технология построена на платёжном протоколе x402 — открытом стандарте интернет-платежей для ИИ-агентов и приложений, который с июля 2026 года развивается под управлением Linux Foundation. Это не стартап-продукт, а vendor-neutral протокол с открытой спецификацией. Якорение записей происходит в NEAR Protocol — L1 блокчейне с энергоэффективным консенсусом (Proof-of-Stake).

Защищайте результаты своего труда до отправки. Попробовать можно прямо сейчас на shield.aotrust.link — первый файл вы защитите за 30 секунд. Буду рад ответить на вопросы по технической части протокола в комментариях.

How to Protect Your Freelance Work from Theft for 10 Cents: A Developers Guide

GitSerge-crypto — Wed, 22 Jul 2026 09:35:21 +0000

How to Protect Your Freelance Work from Theft for 10 Cents: A Developer's Guide

Every freelancer has been there: you send a client a mockup, a design concept, source code, or a detailed project brief. You get silence or a polite "we went with another candidate." A month later, you spot your work in their finished product — without your permission and without payment.

I'm Sergey, a developer, and I want to share how to solve this problem using cryptography and a technology we originally built for AI agents.

Why Classic Protection Methods No Longer Work

When someone complains about stolen work on freelance forums, the usual advice is:

"Just send images with watermarks" — today, AI tools erase any watermark from an image in 3 seconds.
"Send low-resolution previews" — you can't evaluate UI details from a blurry file, and it looks unprofessional.
"Sign a contract for everything" — for a $50–$100 test assignment or quick concept, nobody is hiring lawyers and spending weeks on paperwork.

So freelancers send their files at their own risk.

The Legal Core: How to Prove Authorship

Under the Berne Convention, copyright exists the moment a work is created. You don't need to register a patent. In any dispute (with a client or a platform's arbitration), you need to prove one fact:

"This specific file, in its exact form, was in my hands on a specific date and time — BEFORE the client received it."

Every digital file has a unique mathematical fingerprint — its SHA-256 hash. Change a single pixel or character, and the hash changes completely.

From an AI Agent Protocol to Freelancer Protection

We originally built the AOTrust protocol for autonomous AI agents. When an AI generates a financial report or source code, the system needs an independent artifact — a PDR (Provenance Data Record) — that proves the fact of creation and carries the agent's signature.

At some point, we realized this same technology perfectly solves the freelancer's problem — and we built shield.aotrust.link.

How It Works (3 Steps):

File Fingerprinting (Zero-Knowledge):
You drag a file (mockup, code archive, invoice) onto the site.
Important: the file itself is never uploaded to any server. The service computes the SHA-256 hash directly in your browser using the WebCrypto API. Your commercial work stays on your computer.
PDR Certificate Creation:
You pay $0.10 USDC on the Base network (Coinbase's L2). The notary server signs your file hash with its Ed25519 cryptographic key and creates a compact 239-byte artifact — a PDR.

Don't want to install MetaMask? There's an alternative: send $0.10 USDC to the service's address from any wallet or exchange (Coinbase, Binance, Bybit) and paste the transaction hash. The service verifies the payment on the Base blockchain and issues the certificate. No browser extensions, no in-browser signatures.

Blockchain Anchoring (NEAR Protocol): The service does not write your file or its hash to the blockchain directly. Instead, all issued PDRs are combined into a Merkle tree, and only its root (the Merkle Root) is periodically anchored to a smart contract on NEAR Mainnet (notary-node.near). This provides a mathematical guarantee: the record history cannot be forged retroactively.

What You Get

You download a 3-page PDF certificate:

Page 1: Author name, file name, SHA-256 hash, exact timestamp (UTC), a unique Shield ID (8 characters, e.g. f43e2300), and a QR code linking to verify.aotrust.link/s/f43e2300 for instant verification.
Pages 2–3 (Technical): The full Base64 PDR artifact, author signature, public keys of both parties, the notary's identity (notary-node.near), and a Python verification script for independent offline checking.

Offline verification is the guarantee of eternal proof. Even if our service shuts down in 10 years or access to our site is blocked, any independent specialist or lawyer can take this PDF, provide the original file, run the script locally without internet, and mathematically verify that the timestamp and signatures are authentic.

How to Use This in Practice

When sending work to a client: Attach the PDF certificate to your message with the deliverable:

"Sending the finished concept. The file is timestamped via the AOTrust protocol (certificate attached). You can verify authenticity via the QR code or at verify.aotrust.link"

This demonstrates your professional approach and immediately signals to the client that file ownership has been documented.

When a dispute arises: If a client takes the work and refuses to pay, you send the PDF certificate to the platform's support (Upwork, Fiverr) or the client's hosting provider along with a DMCA takedown notice. An independent mathematical proof that the file existed in your hands before the client received it is your strongest argument.

Who's Behind It

The technology is built on the x402 payment protocol — an open internet-native payment standard for AI agents and applications, now developed under the Linux Foundation as of July 2026. This isn't a startup product; it's a vendor-neutral protocol with an open specification. Record anchoring happens on NEAR Protocol — an L1 blockchain with energy-efficient Proof-of-Stake consensus.

Protect your work before you send it. Try it right now at shield.aotrust.link — your first file is protected in 30 seconds. Happy to answer any technical questions about the protocol in the comments.

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

Как защитить макет, ТЗ или код от кражи за 10 центов: личный опыт борьбы с неоплатой на фрилансе

Как защитить макет, ТЗ или код от кражи за 10 центов: личный опыт борьбы с неоплатой на фрилансе

Почему классические методы больше не работают

Юридическая суть: как доказать авторство

От протокола для ИИ-агентов к защите фрилансеров

Как это работает технически (за 3 шага):

Что вы получаете на руки

Как применять это на практике

Кто это обеспечивает

How to Protect Your Freelance Work from Theft for 10 Cents: A Developers Guide

How to Protect Your Freelance Work from Theft for 10 Cents: A Developer's Guide

Why Classic Protection Methods No Longer Work

The Legal Core: How to Prove Authorship

From an AI Agent Protocol to Freelancer Protection

How It Works (3 Steps):

What You Get

How to Use This in Practice

Who's Behind It

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