DEV Community: aggre

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

aggre — Thu, 16 Jul 2026 13:50:00 +0000

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"¹. 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.

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)

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

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)
Registering the document: registers the document with the Lemma API and submits the proof (this is where the x402 payment fires automatically)
Computing the listingRoot: deterministically generates an ID that uniquely identifies the listing
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.

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

“Dev” - Tokens for your OSS sustainability

aggre — Sun, 05 Aug 2018 03:45:46 +0000

We have released “Dev” tokens in order to support the sustainability of Open
Source Software (OSS).

https://devtoken.rocks/

What is “Dev”?

“Dev” works to achieve fair monetization of your OSS.

Neither commission fees nor usage fees are required.

Utilizing the token economy allows developers to concentrate on development, and
investors to effectively support any OSS.

For the most part, OSS are provided free of charge. OSS developers maintain
their OSS projects by securing a revenue source separate from their OSS.

Typical sources of revenue are as follows.

Working at a company
Freelancing
Donations
OSS provided as SaaS
Enterprise support

Since [1] and [2] are not revenue produced by the OSS itself, the OSS is only
allocated a limited amount of their disposable time.

The revenue of [3] tends to be an amount that deviates from the value of their
OSS due to the arbitrary model of high evaluations. OSS developers are required
to focus their efforts on fields other than just technology so that they can
continue to raise their evaluations.

[4] and [5] essentially achieve monetization directly from the OSS, but this can
be done only with a few limited large-scale projects.

“Dev” works to realizes revenue proportional to the real value of the OSS. In
addition, it does not require changes to the OSS itself. With this
loosely-coupled system, we evaluate the OSS with simple and powerful evaluation
logic and actualize monetization according to that evaluation.

How “Dev” works

To begin, it can be depicted in a simple diagram.

“Dev” is created based on the ecosystem of Ethereum. It is easy to understand if
one has an understanding of block chains, but it doesn’t matter even if they
don’t.

“Dev” can be traded on the market like Ethereum or Bitcoin. Since “Dev” conforms
to the Ethereum standard (ERC20), the price of 1 DEV is determined by the rate
between 1 DEV and 1 ETH.

The outline is as follows.

The price is determined by investors trading “Dev” (updated in real time)
devtoken.rocks mints “Dev” every month
The increase by devtoken.rocks is allocated to the OSS

OSS developers can liquidate their “Dev” by exchanging their “Dev” for Ethereum.

As “Dev” is a token that continues to mint, there is a mechanism to suppress the
dilution of the value of “Dev” itself. This involves evaluation logic.

Evaluation logic for “Dev”

The following variables are used in calculations to determine allocation to the
OSS:

pdl = Number of downloads of the package (OSS) from the 20th day of the last month to the 19th day of the current month
adl = Number of downloads of all packages (OSS) from the 20th day of the last month to the 19th day of the current month
t = Number of tokens retained by the distribution address
d = Number of days elapsed since the OSS registration
p = t / d
ta = Total of p for all addresses
m = Annual number of mints

The calculation formula is as follows.

x = (p + pdl) / (ta + adl) × m / 12

The per-diem rate of “Dev” tokens retained by that OSS is added to the number of
OSS downloads. The same equation is calculated for each OSS individually and all
OSS total, and the ratio is determined for each OSS.

The number of allocations is determined by multiplying the monthly number of
mints by that percentage.

The number of tokens retained by the OSS are added to suppress dilution of the
value of “Dev.”

The more tokens possessed by an OSS, the more tokens will be allocated each
month. In other words, you can increase the number of shares by purchasing or
saving tokens. This will prevent tokens from being sold all at once and suddenly
diluting the value. Investors don’t want the value of the token to be diluted.

As an application of this mechanism, if you send “Dev” tokens to the OSS you
want to support, you can increase the number of token allocations to that OSS.

The calculation logic is available for viewing on GitHub
(frame00/dev-distribution).

Future plans to distribute to contributors

“Dev” is currently in alpha. Tokens are distributed to the owner of the OSS.

We want to implement the ability to distribute tokens to OSS contributors.
Contributors would be able to receive compensation relative to their
contribution.

With active use of “Dev,” we would be able to proceed to advance functional
development as soon as possible.

How to connect with “Dev”

There are a number of ways to get involved in the OSS community for “Dev”.

I want to monetize my OSS

If you are self-publishing your OSS, you can begin to achieve monetization by
registering your OSS on devtoken.rocks.

Registration is quick and easy, and there is no need to make any changes to your
OSS.

As it is currently in alpha, only OSS that are published in npm can be
registered.

I want to support OSS

You can contribute to an OSS by using “Dev” tokens.

“Dev” can be contribute efficiently in order to realize a world where OSS are
more actively developed.

Order Book can be opened from devtoken.rocks to buy
and sell “Dev.” EtherDelta is used for main exchanges.

There is an OSS that I want to directly support

If the OSS that you want to support is registered in “Dev,” you can send “Dev”
directly to the wallet address of the OSS.

If the number of tokens retained by the OSS increases, it increases the amount
of monthly distributions made to that OSS. In this way, you can provide
continuous support even without making a new contribution every month.

Refer to GitHub
(frame00/dev-distribution) to
check the wallet address of the OSS. OSS information is stored in
config/packages.ts.

Growth of “Dev” is accelerated through active use by OSS developers and
investors.

For questions please contact us on
Twitter. Inquiries can be made in either
Japanese or English.

This article was originally posted on Medium.

Read the original article here.

PRPL パターンから非 SPA のパフォーマンスを考えたときのメモ

aggre — Mon, 27 Nov 2017 09:27:38 +0000

SPA ではない構成のウェブアプリでパフォーマンスを出すための施策を、PRPL パターンを発想の起点にして考えてみた。

動機

JavaScript によるコンポーネントベースの開発はフロントエンドの実装を効率的にした。

しかし toC のサービスにおいて、Bot フレンドリーであるための施策が重荷になっている。<meta> タグだけサーバー側で作っておく対策もあるが、Pocket や未知のサービスも含めると本文が必要なケースは依然として多い。個人的には、SPA をいくつかリリースしていく中で、ドキュメントとしての HTML なのにスクリプトを実行しないとドキュメントにならないことへの違和感も感じていた。

そこでドキュメントとして成立するための最小限の要素だけをサーバー側で生成することで、Bot 施策の回避を考えた。

SPA を保ったままで ドキュメントとして成立した HTML を扱うためには密結合な構成か SSR の要件が出てくるという判断に至り、SPA を廃止することにした。

SPA ではなくても、ドキュメント向けの要素以外は Web Components として引き続き開発できる。

その上でパフォーマンスを向上させるための施策を検討した。

施策

PRPL パターンを起点に考えた施策は次のとおり。

Push

HTTP/2 の Push はブラウザのキャッシュを考慮することが現状難しいため対応を保留する。

Endpoint

例として /page/1 へのリクエストで、次のような HTML を返却する。

<!DOCTYPE html>
<html lang="en-US" dir="ltr">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1,user-scalable=yes">
    <title>Page 1</title>

    <!-- Preload CSS -->
    <link rel="preload" as="style" href="/style.css" onload="this.rel='stylesheet'">

    <!-- Preload critical Custom Element -->
    <link rel="preload" as="script" href="/x-header.js" onload="var s = document.createElement('script');
    s.src = this.href;
    document.body.appendChild(s);">

    <!-- Preload service worker -->
    <link rel="preload" as="script" href="/service-worker.js">

    <!-- Preload lazy load script -->
    <link rel="preload" as="script" href="/lazy-load.js" onload="var s = document.createElement('script');
    s.src = this.href;
    document.body.appendChild(s);">

    <!-- Prefetch next page -->
    <link rel="prefetch" href="/page/2">

    <!-- Prefetch home page -->
    <link rel="prefetch" href="/">

    <link rel="manifest" href="/manifest.json">
</head>
<body>
    <!-- Custom Element for header -->
    <x-header></x-header>

    <main>
        <article>
            <section>
                <h1>Title</h1>
                <p>The content</p>
                <p>

                    <!-- Custom Element for article -->
                    <x-content-gallery lazy-load="/x-content-gallery.js"></x-content-gallery>

                </p>
                <p><a href="/page/2">Next</a></p>
            </section>
        <article>
    </main>

    <!-- Custom Element for footer -->
    <x-footer lazy-load="/x-footer.js"></x-footer>

    <script async defer src="/polyfill-of-preload.js"></script>
    <script>
        // Add a service worker
        'serviceWorker'in navigator&&window.addEventListener('load',function(){navigator.serviceWorker.register('/service-worker.js')});
    </script>
</body>
</html>

クリティカルなリソースの preload と、遷移する可能性のあるページの prefetch を行なう。

lazy-load 属性が追加されている要素は、その要素がビューポート内に出現した時点で依存解決をする。この属性名は仮なのと、ビューポートに出現した時点では UX を損なうリスクもあるため工夫は必要。

Render

HTML をレンダリングする。

SPA ではないので異なるルートのための処理は必要ない。

Pre-cache

SPA ではないことから、Service Worker による事前キャッシュ( Pre-cache )は行わない。

Service Worker は通信発生時のキャッシュや通知などの用途に限定される。

Lazy-load

SPA ではないことから、PRPL パターンにおける Lazy-load とは少し趣が違う。

PRPL パターンでは異なるルートのためのリソースを遅延読込することと、画像などのリソースがビューポートに現れるときに遅延読込するというアプローチがとられると理解している。

今回は SPA ではないため、異なるルートのための遅延読込は考慮しない。

アーキテクチャ

データソースは REST API で取得できるようにしておく。

その上でローカルとサーバーをなるべく近い構成にすることを考えると、HTML の配信は Node.js などで立てたサーバーをそのままクラウドでも走らせたい。

この場合、REST API はサーバーレスに構築できるが、HTML はサーバーレスでは構築しづらくなる。

しかしデータソースが REST API なら HTML はステートレスに返却可能なので、CDN によるキャッシュが有効に機能するはず。

早い段階でこの構成を実戦投入してみたい。