Verifiers are the businesses that need an answer (“over 18?”, “accredited?”, “a real human behind this agent?”) without holding anyone’s data. You ask a holder to prove a fact and get back a cryptographic yes or no, with no identity attached. Presentations are valid for ten seconds, bound to your exact request, and never written to the chain.
the answer
A verifier is your own service. You embed the verifying core in your backend, or run it as a service next to it, and ask a holder, a person’s or an agent’s, to prove a fact. What comes back is a ten-second zero-knowledge presentation bound to your request and to proven chain state; what you keep is a minimal decision record, never the proof, never the person.
pip install mintid-verifier-sdkPython 3.12 or later, in your own backend or as a service next to it; the TypeScript client and the MCP server are transport-only and point at that service. MINTID_NETWORK=testnet reaches the public testnet, where a decision carries no weight.
Proves
Does not prove
Every claim of status on this page points at something public you can open or reproduce.
A cryptographic yes or no to the fact you asked, and nothing underneath it. The protocol is designed so that the safest record to keep is almost no record at all: you can show that a person met your policy without ever storing who they are.
A presentation is valid for ten seconds and answers exactly one challenge. One answer can cover several predicates at once; after that it expires, and a durable replay guard makes sure it is never accepted twice.
Every presentation is bound to your verifier, your exact origin, the request key you signed with, the single-use challenge, the policy you asked for and the chain state you checked. Nothing about it transfers to another context.
Before accepting, you re-check issuer and verifier state against finalised chain state, read through cryptographic proofs instead of a trusted node. Verification is online by design, so the trust you act on is never older than the maximum root age.
You request only the facts you need: grade ≥ A3, over 18, credential active, a particular issuer. The holder proves each predicate without revealing the data underneath.
Presentations never enter the chain. You keep only a minimal record of the outcome; the proof and the person stay out of it, so there is nothing sensitive to leak or subpoena.
To request proofs you complete know-your-customer (KYC) verification with an accepted issuer, register a request-signing key and your exact origins, prove control of those domains, and are admitted on chain by governance proposal (by the compliance council once it is seated). Origins are revalidated periodically; wildcards are not allowed.
You issue a signed, single-use challenge over OpenID for Verifiable Presentations (OpenID4VP) that names your verifier and exact origin, states the predicates you need — for example grade ≥ A3 and credential active — and expires in ten seconds.
The holder software checks you against its own trust list, then answers with one zero-knowledge proof bound to your challenge, origin and policy and to the chain state you recorded.
You re-check the issuer and your own registration against finalised chain state — read through cryptographic proofs rather than a trusted node — confirm every requested predicate is proven, and consume the challenge so it can never be replayed.
You store a minimal decision record — that the policy was satisfied at a point in time — and discard the proof. Nothing enters the chain, and no personal data is retained.
Nothing: the protocol charges no usage tax and no fee per check, because verification runs off-chain against public state. That is a protocol rule, written into the design, and it does not expire.
The protocol’s fees sit on agent credentials (the mint fee and lease fee) and on the consented commercial disclosure rail, never on the act of verifying.
The decision record is minimal by construction, so verifying never turns you into a holder of personal data.
Mirrors, archives and managed verification services may charge their own fees. Those fees never touch consensus rewards.
Registered verifiers are accountable too: KYC-approved, bound to exact origins, revalidated periodically, and suspended if they abuse the registry.
The verification logic exists in exactly one implementation. You embed it in your backend, or run the same core as a service next to it; client SDKs are transport-only and carry requests to that service. You bring the infrastructure — your registration, your origins, your keys, durable replay protection and a clock you trust. The core brings the parts you cannot get wrong: the acceptance checks always run in full, presentations expire in ten seconds, every chain read is proven rather than trusted, and only a minimal decision record is kept. None of it is configurable, and no client offers a “lite” mode.
Available today: a versioned service contract, a Python SDK, a transport-only TypeScript client and a Model Context Protocol (MCP) server for agent tooling; further languages follow demand. The proof core behind them is in production. Admission is not self-service yet, so integration starts as a conversation; the technical integration docs are open.
Agents run inside runtimes, so that is where agent identity should be checked. The MCP server exposes the operations of the verifier service as Model Context Protocol tools, so an MCP-capable agent framework can ask for a challenge, pass on a presentation and read the decision. Like every client it is transport-only, runs inside your own perimeter and points at your own service. A rejection comes back as an ordinary result with a reason code, so an agent can reason about a refusal instead of retrying blindly.
The MCP server docs list the tools and the trust boundary.
Yes, one product. ZadQ, the first product built on MintID, is a seller-verification service for x402 (the pay-per-request protocol built on HTTP’s 402 status code), operated by the CONECTIA group, a disclosed related party. An accepted issuer signs a conventional attestation that an accountable, KYC-verified party stands behind a seller’s payment address, without naming that party, and explorers and buying agents read the signal for free. This runs on the classical seller rail; the zero-knowledge seller rail follows. ZadQ is an ordinary issuer-and-verifier pairing, and it runs as a pilot on the single-node production chain.
Registration and KYC approval put you on the verifier registry and let your users approve your exact origins as trusted in their own holder software — no wildcards, so a lookalike domain cannot impersonate you. Once registered, you integrate on your terms: embed the verification core in your backend or run it as a service, with the same checks and the same privacy guarantees either way. Talk to us about onboarding, or read how the protocol fits together.