← Back to all articles
Challenges

ZadQ Is Live: When an Agent Pays a Server, Someone Should Answer for the Server

By Marc Molas·September 21, 2026·6 min read

An agent calls an API. The server answers 402 Payment Required. The agent pays — one header, no card, no invoice, no human in the loop — and gets its data. That is x402, and it is the first payment rail designed for machines rather than for people holding a phone.

It has one hole that nobody in the specification was asked to close: the buyer has no way to know who is accountable for the server it just paid. If the endpoint never delivers, there is no one to name. If it delivers something illegal, there is no one to name either. Payments are irreversible; accountability is absent by construction.

ZadQ closes that hole, and it is live at zadq.app since 20 August 2026. It is the first product built on MintID and the group's own product line. I'll give you the mechanism, the constraints we chose, and — as with everything I write — the exact perimeter of what we claim.

What ZadQ verifies, in one sentence

ZadQ verifies who is accountable for an x402 seller: an audited operator, with a deposited financial guarantee behind the endpoint, checkable by anyone, for free, with no personal data involved.

The flow is deliberately boring:

  1. An audited issuer vets a seller operator once, off the payment path. Identity is verified in line with eIDAS, through OpenID4VCI/OpenID4VP flows. The operator's records stay encrypted and separated, access logged, released only in the escalation procedure or on lawful request.
  2. The issuer signs an attestation binding the selling endpoint to that operator and to its guarantee bond, held in escrow by regulated financial institutions.
  3. The seller's server attaches the attestation to its 402 responses. One header.
  4. The buyer checks the signature locally — free, in under ten seconds. x402 stays exactly as fast as it was. Nothing calls home.

The status the buyer sees is one of three words: verified, not verified, unknown. That vocabulary is the product.

Three constraints we chose and will not soften

I've built enough trust infrastructure to know that the constraints matter more than the features. These three are the ones I'd defend in front of a payments regulator.

  • The verification is local and free. The buyer never pays ZadQ to check a seller, and the check does not depend on us being reachable. If our service is unavailable, the badge degrades to unknown and nothing stops. A verification layer that becomes a dependency on the payment path has recreated the problem it was meant to solve.
  • Status fails closed. A lapse — an expired attestation, a bond that no longer covers the activity, an issuer that withdrew — drops the status by itself, on a published schedule. No grace period by discretion.
  • Zero identity documents cross the buyer's path. The buyer learns that an audited operator with a deposit stands behind the endpoint, and the assurance grade named in the verdict. Not who the humans are. Accountability without exposure.

There is also a floor, stated everywhere on the site: ZadQ is for endpoints doing roughly US$300 or more of annual activity per agent, or for a regulated business with accountability obligations. Not micro-transactions, not hobby agents. A guarantee bond that costs more than the activity it guarantees is theatre.

Who this is for, in order

The three segments we're onboarding first, in order of fit:

  1. API and data providers selling over x402 who want to be routable by agents that filter on accountability — and who would rather post a bond than answer a chargeback that cannot exist.
  2. Agent marketplaces, directories and explorers that need a defensible listing signal: an objective way to rank sellers, and a status that drops on its own when the guarantee lapses, so the platform is never the one blamed for routing money to a server that vanished.
  3. Payments and financial infrastructure, and regulated entities — the strongest compliance-by-design fit. In the EU the direction is set: the Travel Rule applies to crypto-asset transfers with no minimum amount, and the AMLR that takes effect on 10 July 2027 extends due-diligence obligations across obliged entities. Machine payments will not be exempt because a machine initiated them.

The honest inventory of proof

The site says this and I'll repeat it here: the service is in early operations, and it claims no traction it does not have. No customer logos, no testimonials, no uptime badge, no certification mark. Not because they're forbidden — because we don't have them yet, and a launch post that invents them is the exact behaviour ZadQ exists to make expensive.

What we do have is the thing that can be checked: a live service, an attestation format, a verification path you can run yourself, a developer portal, published terms and a privacy policy that name the legal entity behind the service — Conectia OÜ — and the regulations we operate under. The claimed-versus-verified table on the site is the closest thing to a promise we make.

I'd also concede the obvious: ZadQ runs today on a private installation of the MintID software, not on the MintID network. I've written about what «in production» means for MintID, and the short version is that ZadQ proves the software carries a real product — it does not shorten the network's path to mainnet, and nothing measured here counts toward it.

Why build accountability instead of identity

The instinct in this market is to verify the agent. I argued in July that this is backwards — you verify the human once, and every agent inherits the trust. ZadQ is the seller-side corollary: you don't need to know who the agent is to pay a server safely; you need to know who answers for the server. Bind the endpoint to an audited operator and a deposit, publish the binding, let anyone check it for free, and the market can price accountability without a single identity document changing hands.

That is a smaller claim than «trust layer for the agent economy». It is also one we can verify today, which is the only kind of claim I'm willing to put a launch date on.

If you sell over x402, or route agents that buy

  1. Sellers: read the developer docs at zadq.app, attach one header, and let buyers filter on you.
  2. Marketplaces and explorers: the local check is free; add the three-word status to your listings before your users ask why a paid endpoint disappeared.
  3. Payment and regulated infrastructure: the attestation is the audit trail you'll be asked for in 2027. Start with a pilot endpoint.

Three months ago I ended a series on agent identity by saying I'd rather build than sketch. MintID was the first answer. ZadQ is the first thing anyone can use. If your endpoints or your agents fall inside that floor, tell me what you're routing.

Work with the authors

The CTOs who write this also build

Fractional CTO engagements, AI engineering squads and an AI development platform we install on your codebase in 24 hours. If this piece matched how you think, the conversation is short.

Teams we have embedded engineers in
MintIDCNN InternationalSony Music