Workshop

QueryZero: Zero-Knowledge Credentials for the Agent Economy

Published on: 2026-03-12

By: Ian McCutcheon and AI Assistant

QueryZero: Zero-Knowledge Credentials for the Agent Economy

An autonomous agent receives a wallet address. It has a fraction of a second to decide: do I pay this? Is this entity real? Is this address sanctioned? Is there a human somewhere behind this key who passed KYC, or is this a freshly minted throwaway about to rug me?

Today, most agents trust blindly. The ones that don't, block everything. Neither approach scales.

QueryZero is an experiment in building the thing that should exist between those two extremes: a credential system where both sides of a transaction can prove exactly what the other demands — and nothing more.

The Shape of the Problem

The agent economy is arriving faster than its trust infrastructure. We have agents booking services, making payments, negotiating on behalf of humans. Every one of those transactions is a trust decision happening at machine speed with no machine-readable trust signals.

Think about what a human does when they land on a website and decide whether to enter a credit card number. They look for the padlock. They check the domain name. They read reviews. They have years of pattern recognition telling them whether something feels legitimate. None of that translates to an autonomous agent making a payment decision in 200 milliseconds.

What's needed is something like X.509 for the agent economy — but with a property X.509 never had: the ability to prove specific facts about yourself without revealing everything else. You should be able to prove your wallet isn't blacklisted without revealing your wallet address. Prove you passed KYC without revealing your KYC provider. Prove your domain is verified without revealing your payment endpoint.

That property has a name. It's called selective disclosure. And the cryptographic primitive that makes it real is called BBS+.

BBS+ and the Shape of a Proof

BBS+ signatures over BLS12-381 pairing curves are not new. The construction has been studied in academic cryptography for years and is currently advancing through IETF standardization as draft-irtf-cfrg-bbs-signatures. The W3C Verifiable Credentials working group is building on it. It's the real thing — or at least, it's on the path to becoming the real thing.

Here's what makes BBS+ different from a standard digital signature:

A normal signature signs a message. You verify it, you see the whole message. BBS+ signs a vector of messages — in QueryZero's case, 16 of them. The holder of that signed credential can then derive a proof that reveals any subset of those 16 messages while keeping the rest mathematically hidden. The verifier can confirm that the revealed messages were signed by the issuer, without learning anything about the ones that weren't revealed.

And the proofs are unlinkable. The same credential holder presenting proofs to two different verifiers cannot be correlated across those interactions — not even by the issuer who signed the credential.

No trusted setup. No circuit-specific construction. No all-or-nothing. Just proof.

That's the state where there are no leaks, no seams. You prove what you need to prove, and nothing else crosses the boundary. Real zero-knowledge isn't a marketing term — it's a topology. The proof surface is exactly the shape of what was asked for, and the rest is void.

What's in a Credential

A QueryZero credential is a BBS+ signed bundle of 16 independently disclosable claims. Each claim is verified against an independent source at issuance time — QueryZero doesn't create trust, it checks and certifies.

For an agent credential, those 16 claims include:

For a service credential, the schema is different but the structure is the same — 16 claims covering domain ownership (DNS challenge-response), category, payment capability, compliance status, and social identity.

We call the symmetry "Flip the Script." Both agents and services get BBS+ credentials with the same proof capabilities. An agent can demand proof from a service before paying. A service can demand proof from an agent before serving. Neither side has a privileged position. The trust negotiation is mutual.

How It Actually Works

Agent Credential Issuance

The agent provides its name, wallet address, and operator domain. QueryZero returns a nonce. The agent signs the nonce with its wallet private key — this is the only secret involved, and it never leaves the agent's machine.

On receipt of a valid signature, QueryZero runs every attestation check in parallel: KYC status from EAS on Base, blacklist status from the USDC contract, wallet age from Basescan, Farcaster identity from Neynar, staked amount from the lockbox contract. All results are assembled into the 16-message array, signed with the operator's BLS12-381 private key, and returned.

The agent now holds a credential. It can derive proofs from it forever — or until the credential expires. Each proof reveals only the indexes the verifier asked for.

Service Credential Issuance

A service proves domain ownership through a DNS challenge. You request a credential, QueryZero gives you a nonce, you add a TXT record at _qz.yourdomain.com containing that nonce. QueryZero looks it up, confirms you control the domain, and issues a BBS+ credential with 16 claims about your service.

The DNS challenge is elegant for the same reason it's been used in certificate validation for decades: DNS ownership is the closest thing the internet has to a ground truth about who controls a domain. No OAuth flow, no API key exchange. Just a TXT record and a lookup.

Selective Disclosure

Say a service wants to know two things before accepting a payment: is this agent's wallet blacklisted, and have they passed KYC? The agent derives a proof revealing only indexes [9] and [11] — kycVerified and usdcBlacklisted. The service verifies the proof against QueryZero's public key. It learns the answers to its two questions and literally nothing else. Not the wallet address, not the wallet age, not the social identity, not the staked amount. Nothing.

The math is BLS12-381 pairing operations. The proof is a few hundred bytes. The verification is milliseconds.

The Accumulator: Freshness Beyond Issuance

A credential says "this wallet wasn't blacklisted when the credential was issued." But compliance states change. An address that was clean yesterday can be sanctioned today.

QueryZero maintains three cryptographic accumulators — hash-chain structures that enable non-membership witnesses:

A non-membership witness is a proof that a specific identifier is not in a flagged set, without revealing the set contents or size. Each accumulator operates independently. The architecture supports additional accumulators as new compliance signals emerge.

The current implementation uses SHA-256 hash chains. It's straightforward, it's verifiable, and it works. More sophisticated accumulator constructions exist in the literature, and the architecture is designed to support migration as the ecosystem matures.

The Honest Part

BBS+ is not a ratified standard. The IETF draft is advancing, the W3C work is active, but "advancing" is not "done." The specification may change. The ciphersuite parameters may change. The API surface of the libraries we depend on may change.

QueryZero is built on @digitalbazaar/bbs-signatures, a JavaScript/TypeScript implementation that tracks the draft specification. It's the most complete open-source BBS+ library available in the Node/Bun ecosystem. It works. It's tested. But it's pinned to @noble/curves v1 and @noble/hashes v1 because the v2 releases of those libraries reorganized their BLS12-381 namespace in ways that break the BBS+ implementation. That's not a crisis — the v1 releases are stable, audited, and maintained. But it's a dependency to watch.

We chose TypeScript because that's where we are and that's what Bun runs. The BBS+ ecosystem needs implementations in more languages — Rust, Go, Python — before this can be called infrastructure. If you're building a BBS+ library in another language, you're doing important work. The spec needs implementations to validate it, and the agent economy needs options beyond a single language runtime.

The Digital Bazaar team deserves recognition for building and maintaining @digitalbazaar/bbs-signatures. They've been pushing verifiable credentials and linked data proofs forward for years. The MATTR team has done significant work on BBS+ in Rust and contributed to the IETF draft process. The @noble libraries by Paul Miller provide the elliptic curve foundations that make all of this possible in JavaScript. These are small teams and independent developers doing foundational cryptographic work. The agent economy will run on what they're building.

Why This, Why Now

The timing argument for QueryZero is simple: agents are making economic decisions today, and they're making them blind. Every agent framework, every MCP server, every autonomous workflow that touches money or sensitive data is operating without a standard way to verify the other party.

The counter-argument is also simple: the standard isn't done yet. We're building on a draft specification with a dependency chain that extends through libraries maintained by small teams. That's risk.

We think it's the right risk. The alternative — waiting for the standard to finalize before building anything — means the agent economy gets built on API keys and OAuth tokens and all the same identity plumbing that was designed for humans clicking through browser flows. By the time a standard arrives, the patterns will be set. The window for getting this right is now, while the architecture is still fluid.

QueryZero is an experiment. It runs as a single operator. It doesn't scale to millions of agents. The DNS layer is managed, not federated. These are engineering problems, and they're solvable. The harder question — can BBS+ selective disclosure become the trust layer for machine-to-machine transactions? — is the one worth testing now.

Trust Is a Different Story

Zero-knowledge proofs solve the privacy problem. They don't solve the trust problem.

A proof tells you that a credential was signed by an issuer and that certain claims are true. It doesn't tell you whether the issuer is trustworthy. It doesn't tell you whether the attestation sources are reliable. It doesn't tell you whether the whole system is worth believing in.

Trust is composed, not computed. It's built from multiple independent signals — domain ownership, on-chain attestations, social graph verification, economic commitment, time — each adding a thread to the fabric. No single signal is sufficient. But the more sources you can weave together, the more options you have for building a trust model that fits your risk profile.

That's why QueryZero credentials have 16 claims, not one. That's why both agents and services get the same proof capabilities. That's why the accumulators track multiple independent compliance signals. The goal isn't to declare something trusted — it's to give each party enough independently verified facts to make their own trust decision, at machine speed, with zero excess disclosure.

More participants in this ecosystem means more trust signals, more attestation sources, more independent verification. The fabric gets denser. The proofs get more useful. The trust model gets harder to game.

The Toolkit

QueryZero credentials are available today on both the production network and testnet. The qz-toolkit repository provides CLI tools for both service and agent credential management:

git clone https://github.com/mcyork/qz-toolkit.git
cd qz-toolkit
bun install

Register a service, verify your domain, derive a proof revealing only the claims you choose:

qz-service register api.example.com --category data-api
qz-service verify api.example.com
qz-service proof api.example.com --indexes 1,7,11

The repo includes an llms.txt file — a machine-readable integration guide that teaches agents not just how to use the CLI, but how to incorporate BBS+ proof generation into their own code. If your agent can read a TypeScript import, it can learn to generate its own proofs.

The testnet is open. Echo (echo.queryzero.net) mirrors credentials back for inspection. Everything is an experiment.

Where the Light Shines

I've been building network infrastructure for a long time. From the wire to the sky. And the thing I keep coming back to is that the best architectures are the ones where security isn't a layer — it's the structure itself.

A network without a default route is more secure not because a firewall blocks bad traffic, but because the routing table offers no path for it. The security is in the topology.

A zero-knowledge proof is the same idea applied to identity. The privacy isn't enforced by a policy or an access control list — it's in the mathematics. There's no data to leak because the data was never transmitted. The proof surface is exactly the shape of what was asked for, and nothing else exists.

That's the path where the light shines brightest. Not adding more controls on top of a permissive architecture, but building an architecture where the controls are unnecessary because the structure itself only permits what should be permitted.

BBS+ selective disclosure is that structure for credential exchange. Whether QueryZero is the system that brings it to production, or whether it's a stepping stone that informs what comes next — the primitive is right. The math is sound. The spec is advancing.

We're just here early, building on the draft, testing the ideas, and trying to make sure the agent economy doesn't repeat the mistakes of the one that came before it.

Everything is an experiment. Build with us.

QueryZero is built on Bun, Hono, BBS+ (BLS12-381-SHA-256), and Base (EIP-155:8453). The toolkit is open source at github.com/mcyork/qz-toolkit. Contact: ghia-x402 on Moltbook.

« Domain Validation in the 47-Day Era