# Clearsigned is live: calibrated claim verification for agents, one cent over x402

*2026-08-15 · verify.clearsigned.com · listed in the x402 Bazaar*

Agents can generate anything. What they structurally cannot do is adversarially
verify their own outputs — and every platform selling you both generation and
verification has a stake in its own answers looking right. Clearsigned is the
other thing: **a verification service with no stake in the outcome**, callable
by machines, paid per call, that hands back a receipt you can check without
trusting us at all.

## What a cent buys

```
POST https://verify.clearsigned.com/verify/t1        $0.01 USDC · Base mainnet
{"claim": "The Eiffel Tower is located in Paris, France.", "evidence": []}
```

Behind the paywall: live evidence gathering for **and against** the claim,
per-source stance judgments, an adversarial refuter pass whose only job is to
kill the claim, and a fixed pricing formula no model opinion can touch. Out
comes one of `SUPPORTED` / `REFUTED` / `UNVERIFIABLE` with an Ed25519-signed
receipt: every check that ran, every source with its stance, every hash.

Set your client's response timeout to **60 seconds or more** — verdicts take
10–40s because the evidence is gathered live, not recalled.

## The number we care about most: 0.961, three times

We calibrated the engine on 204 labeled claims (FEVER-class + hand-built
business claims) across **three completely different retrieval stacks**. Each
stack measured **exactly 0.961 commit precision** on decidable claims:

| Retrieval stack | Commit precision | Top-bucket realized | Abstention |
|---|---|---|---|
| Home research substrate | 0.961 | 0.909 (n=121) | 29% |
| Keyless DDG only | 0.961 | 0.848 (n=79) | 55% |
| DDG + Tavily (production) | **0.961** | **0.882 (n=127)** | **24%** |

Retrieval quality changes how *often* the engine commits — never how *right*
it is when it commits. The protection comes from the architecture: when
evidence is thin, the engine abstains instead of guessing. `UNVERIFIABLE` is
a first-class verdict, and a confident wrong answer is treated as the worst
possible output, by construction.

The production confidence you see on a receipt (0.882) **is** the measured
realized rate from that table — never a model's self-reported feeling. The
full curve, with provenance and known limits, ships in the repo and is
referenced by version on every receipt.

## Verify us — don't trust us

- **Pin the key**: `GET /pubkey` publishes the Ed25519 key and the exact
  offline verification recipe. Never trust the key embedded in a receipt.
- **Audit the chain**: every paid receipt and its on-chain settlement are
  separate hash-chained events, joined on (payer, nonce), publicly walkable
  at `GET /ledger/verify`. Deleting or editing history breaks the chain.
- **Check the isolation**: the production instance passes a recorded
  isolation acceptance — probes prove it holds nothing beyond its service
  corpus. The acceptance records are in the repo.

## The state of agent readiness (why this matters now)

We scanned 25 well-known sites with an audit-by-execution scanner (the agent
actually attempts the journey; every check returns evidence). Results: **one
perfect score** (Cloudflare), 17 of 25 at D or F, and the commerce giants
agents most want to transact with all failing. The web isn't ready for
agents, agents can't verify what they read, and both problems are why
verification-as-a-service exists. Full data at [/sweep](/sweep) — and you can
scan any site free at [/scan](/scan).

## Try it in two minutes

Free, no wallet: `curl https://verify.clearsigned.com/health` · unpaid POST
returns the x402 challenge · [/scan](/scan) for the free scanner.

Paid, with any x402 client (Python shown, ~20 lines):
[buy_a_verdict.py](https://clearsigned.com/demo) — fund a key with a few
cents of USDC on Base, run it, verify the signature yourself against
`/pubkey`.

## Honest limits, stated up front

- The engine **abstains on ~24% of decidable claims** — you may pay a cent
  and get `UNVERIFIABLE` with the evidence trail explaining why. Refunds are
  for failure to deliver, never for the verdict's direction. That asymmetry
  is the product.
- Some sources block automated readers (Britannica-class 403s); the receipt
  shows exactly what was reachable. Reader coverage is a named, measured
  work-in-progress.
- Every settled payment in our public ledger to date is **our own labeled
  test traffic**. You'd be the first real customer, and the chain will show
  exactly that.
- Calibration n=204 with stated dataset caveats — read the curve file's
  provenance before staking anything important on a verdict.

## The stack, for the curious

Built in four days by a human owner and an agent working in a supervised
loop, with the honesty discipline enforced by construction: every guarantee
break-verified, every deploy gated by a corpus scan and an isolation recall
test, every failure recorded as a failure in an append-only board. The
receipts are the marketing. This post contains no claim the chain can't back.

*— Clearsigned · [llms.txt](/llms.txt) for machines · signedverdict.com
redirects here*