Which AI Output Did the Human Actually Approve? Co-Signing AI Results on Base, $0.01 per Check

Signup Write New Story Which AI Output Did the Human Actually Approve? Co-Signing AI Results on Base, $0.01 per Check by Artur Baranouski by Artur Baranouski | @ arturbaranouski Director of a construction and real-estate development company in Grodno, Belarus. Building open-source tools for verifiable documents and AI output

Director of a construction and real-estate development company in Grodno, Belarus. Building open-source tools for verifiable documents and AI output

TL;DR. BuildProof is an open-source registry on Base mainnet where several parties co-sign the SHA-256 of a file. One of the file types is an AI-output manifest: the hashes of the prompt, the input documents and the model's answer, bundled into one canonical JSON. The AI operator signs it, a human reviewer signs or rejects it, and anyone can later check a file against the chain for free, or let an agent pay $0.01 in USDC per lookup over x402. Code, contract and endpoints are live. It has no real users yet; everything on mainnet is demo data.

I direct a construction and real-estate development company. Every month the same paperwork moves between the client, the general contractor, subcontractors and technical supervision: acceptance acts, invoices, supplementary agreements that change a quantity or a unit rate. It travels as PDFs over e-mail and messengers. Two arguments come up again and again: which version was signed, and does this act actually match the contract and its amendments.

Now add AI to that flow. A model summarizes an NDA, flags risks in a contract, checks the arithmetic in an act. A lawyer or an engineer reads the result and approves it. A few weeks later someone disputes it, and the questions are the old ones with a new twist:

None of this needs a sophisticated attacker. One changed number and two people with different files are enough.

The idea is deliberately boring. Hash the files locally. Put only the hash on-chain, together with the list of wallets that must sign. The record becomes ATTESTED only when every listed wallet has signed. A required signer can instead reject, and the rejection carries the SHA-256 of the reason (for example a review report), so the reason text stays off-chain but is pinned too. When an amendment to an attested document is attested, the original is marked SUPERSEDED.

For AI output, the "file" is a manifest. The CLI builds it from four things:

node cli/buildproof.mjs manifest --model gpt-4o \ --prompt examples/legal/ai_review_prompt.txt \ --input examples/legal/nda_mutual.pdf \ --output examples/legal/ai_review_output.md \ --created 2026-10-09 > examples/legal/ai_review_manifest.json and the result in the repository is a single canonical JSON line (keys in fixed alphabetical order, no trailing newline, so the file hashes the same on every machine):

{"created":"2026-10-09","input_documents_sha256":["0xd4caea07…8b3a"],"model":"gpt-4o", "output_sha256":"0x92edd666…2d36","prompt_sha256":"0x0216b2a6…1c3f", "reviewed_by":"human reviewer (wallet signs below)","schema":"buildproof.ai-output/v1"} (Hashes shortened here; the full file is examples/legal/ai_review_manifest.json.) The manifest is then registered with two signers, the AI operator and the human reviewer. This exact example is live on Base mainnet: attestation 0x87580bfb…26ad12e, registered in 0x38c7eef6…, signed by the AI operator's key offline (EIP-712) and relayed in 0x8662ee13…, then signed by the human reviewer in 0xf779a3e5…. Status: ATTESTED. Change one byte of the prompt, of any input, or of the answer, and the manifest hash changes, so the lookup returns NOT_FOUND.

Be precise about what this proves. It proves which exact bytes each wallet approved, and when. It does not prove that the named model produced the output: model is a string the operator writes. Proving model execution is a different problem (TEEs, zkML) and out of scope here.

An honest footnote on decentralization: the registry is permissionless and readable for free through any RPC; the Worker is a convenience I run on Cloudflare. If I shut it down tomorrow, every record stays readable on Base.

Signers who have no gas can still sign. They produce an EIP-712 signature over the attestation id and the document hash, and anyone relays it:

function signBySig(bytes32 id, address signer, bytes calldata signature) external { Attestation storage a = _att[id]; if (a.status == Status.None) revert UnknownAttestation(id); bytes32 digest = signDigest(id); if (_recover(digest, signature)!= signer) revert BadSignature(); _sign(id, signer, true); } The domain separator includes block.chainid and the contract address, _recover rejects high- s (malleable) signatures and address(0), and the id embeds the document hash, so a signature cannot be replayed onto another document, contract or chain.

The second fragment came from a review. Two amendments to the same attested contract could both be pending; whichever completed last would silently overwrite the first. The fix is one line in _sign:

if (a.signedCount == a.signerCount) { a.status = Status.Attested; a.closedAt = uint64(block.timestamp); emit Attested(id, a.docHash); bytes32 old = a.supersedes; if (old!= bytes32(0)) { if (supersededBy[old]!= bytes32(0)) revert BadSupersedes(old); supersededBy[old] = id; emit Superseded(old, id); } } Anyone can register any hash with any signer list, so a stranger can front-run a registration with fake signers. That does not block the real record: the id is keccak256(docHash, docType, projectRef, supersedes, signers, msg.sender), so the fake one gets a different id. Verifiers pass the expected parties (?signers=0xA,0xB ), and the verdict only counts records whose signer set matches exactly.

The Foundry suite has 21 tests, two of them fuzz tests, covering replay, malleability, griefing registrations, double signing and the supersession race.

The interesting user of a verify endpoint is not a person with a browser. It is an agent in the middle of a task: "before I pay this invoice, was this act co-signed by both parties?" or "before I forward this AI review to the client, did a human sign it?" Agents do not fill in sign-up forms, so the API has no accounts and no keys. Payment is the authentication. The route config is small:

paymentMiddleware({ [ROUTE]: { accepts: { scheme: "exact", price: cfg.PRICE, network: cfg.X402_NETWORK, payTo: cfg.PAY_TO, maxTimeoutSeconds: 120 }, serviceName: "BuildProof", }, }, resourceServer) An unpaid request gets 402 Payment Required with a PAYMENT-REQUIRED header. Decoded, the live one quotes scheme exact, network eip155:8453 (Base), amount 10000 (USDC has 6 decimals, so $0.01), asset 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. The buyer signs an EIP-3009 USDC authorization, a facilitator (PayAI, no API key) settles it, and the buyer retries with the payment header.

The Worker never holds a private key and never sends a transaction. A malformed hash returns 400 before any price is quoted, and a failed chain read returns 502, which the middleware does not settle, so the buyer is not charged for my outage.

On the NEAR AI Agent Market the marketplace itself is the A2A server and takes the payment ($0.01 USDC on NEAR). My Worker receives assignments by webhook, checks an HMAC-SHA256 over "<timestamp>.<raw body>" with a 5-minute window, and a cron trigger polls every minute for missed ones. A brief without a hash is declined as rejected, so the caller is not charged. On OpenServ the listing is a paid workflow in the public x402-services catalogue; the platform calls the Worker as an external agent endpoint, with no LLM in the loop.

Everything below runs without an account.

git clone https://github.com/ttimesai-star/buildproof && cd buildproof && npm install # A demo acceptance act registered on Base mainnet, two signers, one of them via a relayed EIP-712 signature BP_RPC=https://mainnet.base.org node cli/buildproof.mjs verify examples/pdf/act_01.pdf # status ATTESTED, registered 2026-10-09T13:18:07Z, closed 2026-10-09T13:18:19Z, 2 signers signed # The AI-output review manifest, co-signed by the AI operator and the human reviewer BP_RPC=https://mainnet.base.org node cli/buildproof.mjs verify examples/legal/ai_review_manifest.json # status ATTESTED, type ai-output, registered 2026-10-10T00:45:03Z, closed 2026-10-10T00:45:13Z, 2 signers signed # The x402 quote (expect HTTP 402 and a PAYMENT-REQUIRED header) curl -i https://buildproof-x402.zbignevich.workers.dev/v1/attestation/$(node cli/buildproof.mjs hash examples/pdf/act_01.pdf) # Free service info and OpenAPI spec curl https://buildproof-x402.zbignevich.workers.dev/ curl https://buildproof-x402.zbignevich.workers.dev/openapi.json Links:

The whole demo story (contract, amendment, a clean act, an act with planted errors that the client rejects with the hash of the check report) runs on a local anvil chain with bash scripts/demo.sh. CI runs it, plus the Foundry, Python and Node suites, on every push; the latest commit is green.

Deploying the registry and running the mainnet demo cost 0.0000096 ETH in gas, about $0.024. Registering and co-signing the AI-output manifest (three transactions) cost 0.0000022 ETH, about half a cent. That is the economic argument for an L2: co-signing a document costs less than printing it.

An Ethereum Attestation Service adapter, salted hashes for templates, and an agent-side helper that builds the manifest the moment the model answers, so pinning the output is a side effect of generating it. And the part that matters most: a first real counterparty who signs a real acceptance act this way. That decides whether this is a tool or a demo.

The code, the tests and the draft of this article were produced by AI agents (mainly Claude by Anthropic, with a second-opinion review by Google's Jules agent), working on goals and constraints I set. The problem and the rules for checking acceptance acts come from my own work in construction. The agents proposed the architecture and wrote the code; every claim in this text was then verified against the repository and the live endpoints: the contract address and its Sourcify match, the mainnet attestation status via the CLI, the live 402 price quote, the test count, and the CI status.

Where something has not been done, such as a paid mainnet call or real users, the article says so. The optional field extraction in the cross-checker can call an NVIDIA-hosted Nemotron model; in that path the model only extracts numbers, and deterministic Python decides every finding.

Building Verifiable AI Agent Audit Logs With Signed, Hash-Chained Record