Docs

Try it in 60 seconds

Six steps, no clone, no editor. Steps 1 and 2 need no key and spend nothing; the first thing that costs money is step 5, and it costs one cent of testnet USDC.

1. Get a quote. No key, no environment, no install.
   npx @0x402/cli underwrite 0xDB08Ce217Ce842b06baf76a0Bbb2C10f47fF9eB8 Copy

   It reads the token's bytecode over RPC, asks the reference auditor for its 402 quote, runs it past the budget gate, and stops — a dry run is the default, and without a key it is the only thing that can happen. The last line names the next command.

2. Get a key.
   npx @0x402/cli init Copy

   Generates a burner key into ~/.acu/config.json (0600, inside a 0700 directory) and prints the address. It is a burner: fund it with testnet USDC and nothing else.

3. Fund it, then ask whether you are ready.
   npx @0x402/cli status Copy

   Take the address init printed to the Circle faucet at faucet.circle.com and ask for Base Sepolia USDC. status reports key, balance, auditor, budget and ledger, and ends with one arrow line: it flips from Fund … to Ready: acu underwrite 0xDB08…. If you jump the gun, INSUFFICIENT_USDC repeats the address and the faucet URL.

4. Buy one real seal.
   npx @0x402/cli underwrite 0xDB08Ce217Ce842b06baf76a0Bbb2C10f47fF9eB8 --live --no-settle --publish Copy

   Your agent pays the auditor over x402, verifies the seal B that comes back against all eight checks, refuses to compose anything if one of them fails, signs seal A around it, and publishes the body to 0G Storage. Every step prints as it happens; the verdict line is ✓ EXECUTED or ✗ CODE with the reason indented under it.

   --no-settle is not a shortcut past anything. The demo registry's StubVerifier trusts exactly one signer, so only the reference Agent A can list on it; a seal you sign yourself is a fully valid seal and verifies green, it just does not go onto this registry. Ask to settle with no registry configured and the command refuses NO_REGISTRY before it spends anything, and --registry <address> points it at your own deployment.

5. Open the share link it printed.

   The last line is Share it: …/#seal=…. That link carries the whole seal in its fragment, which a browser never sends to a server — so the page that verifies it never learns what it verified. Seals on chain is the same verification run over what this registry has actually listed — every visitor's browser re-checks each seal before the card is coloured.

6. Make it your agent's job instead of yours.
   claude mcp add acu -- npx -y @0x402/mcp Copy

   Zero environment variables: the server reads the same ~/.acu/config.json the CLI wrote. Then say it in words — "underwrite 0xDB08…9eB8 at 70% LTV" — and your agent hires the auditor, checks the seal and signs its own. That is the whole thesis; the five steps above exist to get you here.

Two sides

import { underwrite } from "@0x402/underwriter";

const result = await underwrite(
  {
    token,
    ltvBps: 7000,
    source: null,
    settle: true,
    publish: true,
  },
  {
    account,      // A's key. Nothing else can sign.
    agentId: "1",
    auditor: { url, agentId: "2" },
    resolver,     // AgentIdResolver: the directory
    budget,       // gate, before any signature
    network: "eip155:84532",
    dryRun: false,
    registry,
    rpcUrl,
    onStep: (e) => console.log(e),
  },
);

// ok:  { ok: true,  sealA, sealHash, hire, listing }
// no:  { ok: false, stage, code, detail }

import express from "express";
import { sealedAuditRoute } from "@0x402/auditor";

const app = express();
app.use(express.json({ limit: "1mb" }));

sealedAuditRoute(app, {
  sealAccount,  // your key, in your process
  agentId: "2",
  priceUsd: "$0.01",
  payToAddress,
  network: "eip155:84532",
  facilitatorUrl,
  sealTtlSeconds: 86_400,
  og: {
    network: "testnet",
    apiKey,
    model: undefined,
    skipAttestation: false,
  },
});

app.listen(4021);

Verify anywhere

Verification never crosses the network. There is no endpoint of ours that will tell you whether a seal is good, because such an endpoint would be a thing to trust. The same @0x402/seal runs in the CLI, in the MCP, in an Agent A, and in the page on this site.

import { verifySealA, SealVerificationError } from "@0x402/seal";

try {
  await verifySealA(seal, { expectedSubject: token, resolver, now });
  // Every check below passed, including the seal B embedded inside.
} catch (err) {
  if (err instanceof SealVerificationError) console.log(err.failure, err.message);
}

A seal A runs the first four and expiry over itself, and runs all eight over the seal B embedded in it. Verification stops at the first failure and names it, which is why the verifier marks the rows after it not reached rather than green: "we did not look" is not the same claim as "it is fine".

What a seal does not prove

It proves traceability, not correctness. A perfectly signed wrong answer still verifies — and that is the point of recording the reasoning: on InjectionUSD the model returned DENY ten times out of ten and every time for the wrong reason, and the only way anyone found out was that the seal wrote the reasoning down. A TEE is not trustlessness, the seal does not cover the invoice, and holder concentration is left null rather than invented.