Most AI APIs hand you a label and ask you to believe it.

Most AI APIs hand you a label and ask you to believe it.

gpt-5.5. claude-opus-4.8. minimax-m3. "Premium model."

Cool. But what happens when the endpoint quietly swaps you onto something cheaper? Or mixes your traffic across three providers? Or wraps some other API and slaps a nice name on it? Or serves you a quantized stand-in that's 80% as good and 40% of the cost?

What evidence do you actually have that you got what you paid for?

Honestly, for most APIs the answer is: none. You have a string in a JSON field. That's it.

At AntSeed we're building the verification layer that string was always missing.

A label is not evidence

This isn't some paranoid hypothetical I dreamed up. There's a paper called Real Money, Fake Models that audited "shadow" APIs claiming to serve official frontier models. They found real divergence in utility, safety, and identity. The incentive writes itself. Charge for the expensive model, ship something cheaper, keep the spread. Rinse, repeat.

A centralized provider can wave you toward their brand, their contract, their support desk when you complain. Fine. But a peer to peer market has none of that. Our sellers are independent peers. There's no head office to email. So the evidence has to live somewhere else... it has to travel with the response itself.

And here's the distinction that took us a while to say cleanly:

Signed responses do not prove model identity. They prove who served which bytes.

That's the foundation. Get attribution first. Once a seller's output is provably theirs, you can layer statistical model auditing on top. Cryptographic provenance, then behavioral verification. Order matters, and I'll come back to why.

What's shipping right now: ResponseAuth

The first piece already lives in @antseed/node.

For supported buyer to seller connections, the seller signs a ResponseAuthPayload right after serving a response. That payload locks in:

• the request hash and the response hash


• buyer peer id and seller peer id


• the advertised service and provider name


• status code and timing


• an optional payment channel id

The buyer checks the signature against the seller's peer identity, then stores the result locally. And a random sample of verified exchanges gets written to disk as full evidence:

<dataDir>/verification_samples/

  <sellerPeerId>/

    <sampleId>/

      manifest.json

      request.bin

      response.bin

Now, this does NOT tell you the response came from the model on the label. Read that twice, because people get it twisted. What it tells you is that the seller can never later deny serving those exact bytes.

That's the whole game right there. It's the line between a complaint and a receipt.

What comes next: fingerprint verifiers

The next layer isn't one clever test. It's a suite. Truth be told, anyone selling you a single "is this the real model?" oracle is selling you something that doesn't exist.

Different cheats leave different fingerprints:

• A cheap substitute tends to fall apart on knowledge boundary probes.


• A wrapper around a real model can leak instruction hierarchy artifacts.


• A relay sometimes gives itself away through runtime behavior.


• A whole model family carries rare token or perturbation signatures you can measure.

So the spec tracks a bunch of verifier families, each catching a different lie:

• 
  KBF (knowledge boundary fingerprinting): numeric probes right at the edge of what the claimed model should know. See the paper and the reference implementation.


• 
  LLMmap-style behavioral probes: prompts picked specifically because model families answer them differently. LLMmap.


• 
  TRAP-style adversarial triggers: private prompts that pull out distinctive target-model behavior. TRAP.


• 
  ZeroPrint-style perturbation fingerprints: watch how answers shift under meaning-preserving input tweaks. ZeroPrint.


• 
  UTF / rare-token fingerprints: poke at under-trained or weird tokens and see what falls out. UTF.


• 
  LLMPrint-style prompt-injection fingerprints: exercise instruction hierarchy and injection behavior. LLMPrint.


• 
  Julius-style service fingerprints: figure out the serving stack itself, Ollama, vLLM, LiteLLM, whatever's underneath. Julius and its repo.


• 
  READER-style passive provenance: analyze ordinary signed responses after the fact. READER.

None of these is gospel on its own. That's the point. You build a suite where independent signals stack up. A SAME result is not a certificate of authenticity. But a strong DIFF, backed by signed response evidence and reproducible references? That's something a buyer can actually act on.

Why public fingerprints should behave like torrents

Here's a tension I keep chewing on.

Private probes are what you need for real enforcement. Because if every seller can see your exact test set, a dishonest one just routes those specific prompts to the real model and serves garbage for everything else. Classic teach-to-the-test.

But public fingerprints still matter a ton. Reproducibility. Smoke tests. Shared baselines. Research. Network-wide learning. The question was never whether to publish them. It was how to publish them without turning AntSeed into yet another centralized API or some hosted database that becomes a single point of failure (and control).

Our answer in the spec: a fingerprint swarm.

Think torrent, not registry.

A fingerprint pack is a signed, content-addressed bundle. A peer announces a little metadata. Other peers grab the pack from any mirror or seeder, verify the content hash, verify the publisher signature, and then decide for themselves whether to trust it.

The trust model is honestly kind of beautiful in how boring it is:

Discovery tells me a pack exists.

Storage gives me bytes.

Hash proves the bytes are correct.

Signature proves who published the pack.

Local trust policy decides whether I use it.

No central server has to be the oracle. GitHub can be a review surface and a bootstrap mirror. IPFS, Arweave, plain HTTPS mirrors, AntSeed peers, all of them can serve the same pack bytes. Doesn't matter where it came from. If the hash and signature check out, the pack is valid. Full stop.

What this actually enables

The long-term flow ends up looking like this:

1. A seller advertises a model or service.


2. The buyer sends normal requests through AntSeed.


3. The seller signs response provenance with ResponseAuth.


4. The buyer stores that verified evidence locally.


5. The buyer imports trusted public fingerprint packs from the swarm.


6. The buyer keeps private references around for the tougher audits.


7. The buyer runs the fingerprint verifiers locally.


8. Routing quietly steers away from sellers with bad evidence.


9. Disputes and slashing come later, and only after off-chain verification.

That ordering is the whole philosophy, so let me be blunt about it. We do NOT open with slashing. Punishment-first designs are how you get a network full of angry false positives and no sellers. Instead: make responses attributable,