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

AntSeed is building a verification layer for AI APIs that cryptographically proves which model served a response, addressing the problem of 'shadow' APIs that swap expensive models for cheaper ones. The company's open-source node package signs response payloads to create non-repudiable receipts, and a planned fingerprint swarm will enable statistical model auditing without centralized control.

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 https://antseed.com/ we're building the verification layer that string was always missing. This isn't some paranoid hypothetical I dreamed up. There's a paper called Real Money, Fake Models https://arxiv.org/abs/2603.01919 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 https://antseed.com/blog/ai-infrastructure-bittorrent-not-spotify has none of that. Our sellers https://antseed.com/providers 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. 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 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. 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: So the spec tracks a bunch of verifier families, each catching a different lie: 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. 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. | Torrent concept | AntSeed fingerprint swarm | |---|---| .torrent / magnet metadata | fingerprint pack announcement | | info hash | packId | | tracker / DHT | AntSeed discovery topics | | seeders | peers mirroring verified packs | | downloaded files | signed fingerprint packs | | piece hashes | optional chunk hashes | | uploader identity | publisher peer id + signature | 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 https://antseed.com/providers , 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. The long-term flow ends up looking like this: 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,