DEV Community

Cover image for AI Agents Won't Buy a Black Box: Introducing Trust402
aggre
aggre

Posted on

AI Agents Won't Buy a Black Box: Introducing Trust402

#ai #cryptography #typescript

TL;DR
x402 lets AI agents pay autonomously, but it cannot tell them whether what they are buying is real. Trust402 uses ZK proofs to enable verification before purchase without revealing the content, creating a marketplace where agents can verify, pay, and retrieve autonomously.

Here's a black box. Amazing data inside, trust me. A dollar?

Nobody's buying that. But it's happening a billion times a day.

Let me back up. AI agents are showing up everywhere, and standards are popping up at every layer: agent-to-agent communication, tool integration, payments, authentication. Payments are handled by the x402 protocol, which Coinbase announced in May 2025. The idea is simple: take the HTTP 402 status code ("Payment Required," the one that always had a name but almost nobody ever used) and standardize the whole flow, from presenting payment terms and checking the buyer can pay, to settling the payment and returning the response. Basically, the entire payment process now runs mechanically over plain API calls.

In July 2026, the x402 Foundation launched under the Linux Foundation, with Coinbase, Cloudflare, and Stripe on board. A June 2026 Chainalysis report puts x402 past 100 million transactions on Base in its first nine months, and it's not just dust: transactions above $1 grew to 95% of the value moved, up from 49% a year earlier.

But 100 million is only a sliver of the actual intent to pay.

"Industry observers estimate that as many as one billion 402 responses may be served daily on Cloudflare's network"1. A 402 response is a server's way of saying, "This is paid content, so please pay for it." So servers ask for money a billion times a day, and only a sliver of that ever makes it to settlement.

Most of it ends as a probe. An agent checks the price and just... walks away. No deal.

Why? Because a black box tells you nothing.

Agents can pay, but they can't tell whether what they're buying is real. Is that JSON labeled "dataset" actually from where it claims? Has the document been tampered with? Is there a backdoor in the code? All the things a human would obviously check before buying, and the payment layer guarantees none of it. The spec is clean, but in practice something's missing. A 402 response tells you how much to pay. It says nothing about whether the thing is real.

So there's a structural gap here: you've got a way to pay, but no way to check why you should. That's the gap we built Trust402 to fill.

Trust402: "Still a black box, but here's a certificate of what's inside."

Trust402 is a verifiable content marketplace built on top of x402.

Creators and researchers can list their work (documents, datasets, code, models) with a ZK proof (zero-knowledge proof) attached. A buyer (human or agent, either works) verifies the proof, runs the x402 payment, and gets the content. Trust402 wraps that whole flow into a single platform.

A ZK proof is a bit of cryptography that lets you prove a claim, say, "this data holds at least 1,000 values and hasn't been tampered with," without ever showing the file itself. A buyer's agent can verify the proof before paying, and decide whether the thing is real and worth the money. Payment is left to x402; authenticity is handled by the ZK proof.

Right now our focus is the seller side. Generating the ZK proof, registering the document, publishing to the storefront: you can do all of it from the SDK and the dashboard. We built the first version at ETHGlobal, and it's now running in production on Cloudflare Workers + Base. The dashboard is live at lemma.frame00.com/trust402/sell.

Try it

The dashboard is the quickest way in. Open lemma.frame00.com/trust402/sell and click "dashboard", connect your wallet, drag a file onto the listing form, fill in a category and a price (USDC), and hit "Publish." Under the hood, publish() from @trust402/sdk runs the whole thing, from generating the proof to uploading to the storefront.

trust402.lemma.workers.dev

Anything you can do in the dashboard, you can do from the SDK too. The dashboard uses a hash-based proof that works for any file type and proves it hasn't been altered, but with the SDK you can also build proofs that reach into the actual contents of a given format. As an example, let's use the blogArticle circuit, which can fold the author, word count, and language into the proof. Here's the minimal code to list a blog post:

import { create, publish, blogArticle } from "@trust402/sdk";

// 1. Create the client
const client = create({
  apiKey: "your-lemma-api-key",
  getSigner: async () => ({
    provider: window.ethereum,
    address: account.address,
  }),
  onPayment: (info) =>
    console.log(`paid ${info.amount} micro-USDC`),
});

// 2. Build the witness and commitment from the article
const { witness, commitment } = blogArticle({
  author: "aggre",
  published: Date.now(),
  body: "# My Article\n\nHello, Trust402.",
  words: 7,
  lang: "en",
});

// 3. Generate the proof, register the document, and publish the listing
const listing = await publish(client, {
  circuitId: "blog-article-v1.2",
  witness,
  commitment,
  price: { amount: 5000, currency: "USDC" },
  did: `did:pkh:eip155:84532:${account.address}`,
  environment: "sandbox",
  file: new File(
    ["# My Article\n\nHello, Trust402."],
    "article.md",
    { type: "text/markdown" }
  ),
  category: "document",
  payoutAddress: account.address,
});

// listing.listingRoot → unique ID for the listing
// listing.cardId      → its ID in the storefront
// listing.perSchemaProof → the ZK proof (verifiable with snarkjs)
Enter fullscreen mode Exit fullscreen mode

Here's what publish() is doing under the hood:

  1. Generating the ZK proof: takes the circuit for circuitId (Groth16, a flavor of ZK-SNARK) and builds a proof from the witness (the input values the proof is built from)
  2. Registering the document: registers the document with the Lemma API and submits the proof (this is where the x402 payment fires automatically)
  3. Computing the listingRoot: deterministically generates an ID that uniquely identifies the listing
  4. Publishing to the storefront: if you passed a file, uploads it straight to the storefront

Three calls (create → blogArticle → publish), and you've gone from ZK proof to x402 payment to a live storefront listing in one shot.

Custom circuits

Up to here we've been using the circuits that ship with the dashboard and SDK, like blog-article-v1.2. But the really fun part of Trust402 is that you can point it at any circuit you've registered with Lemma.

This is getting long, so I'll save it for its own post. In the next one I'll walk through a custom circuit like research_dataset in code, showing how an agent can check before it buys. Think a claim like "this dataset really does hold 1,000+ records and matches a specific schema," made verifiable with a ZK proof, then dropped into the Trust402 listing flow.

Trust402 is in preview at lemma.frame00.com/trust402/sell. Just like x402 standardized the payment layer, Trust402 wants to be the standard pattern for verifiable content transactions.

  1. CoinDesk, "AI Agents Are Breaking Web Economics, but Cloudflare Says x402 Can Help" (May 5, 2026). Cloudflare CSO Stephanie Cohen, Consensus Miami 2026. ↩

Top comments (0)