> Request 10-second zero-knowledge presentations bound to your challenge and policy, keep only a minimal decision record — never the proof or the person. For verifiers # Check the proof, keep none of the person In plain terms: 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 answer, not an identity. Presentations are valid for ten seconds, bound to your exact request, and never written to the chain. the answer the data · sealedzk proof10 s · gone ## How verification works in your favour The protocol is designed so that the safest record to keep is almost no record at all. You prove a person met your policy without ever storing who they are. 10s ### 10-second perishable proofs A presentation is valid for only 10 seconds. Within that window a single bound session can satisfy multiple predicates against one credential or across several, then it expires and cannot be replayed — not even across a verifier restart. ⊞ ### Full cryptographic binding Every presentation is bound to a unique challenge and nonce you issue, the exact audience and origin, the requested policy, the current issuer status root and a finalized chain height. Nothing about it transfers to another context. ◉ ### Online verification Before accepting, you check the latest finalized issuer and verifier state on-chain — reads verified cryptographically against the chain’s own headers, so you never have to trust an RPC endpoint. Verification is online; offline acceptance is out of scope for the MVP, so you never act on stale trust. ≥ ### Predicates & selective disclosure You request only the facts you need: grade ≥ A3, an age threshold, credential active, issuer accepted, credential unexpired. The holder proves the predicate without revealing the underlying data. ▤ ### Minimal decision record Presentations never enter the chain. You keep only a minimal decision record of the outcome — not the full proof and not the person — so there is nothing sensitive to leak or subpoena. ✓ ### KYC-approved verifier registry To request proofs you must be registered and KYC-approved on-chain, hold a current authorization status, and prove control of every domain, origin and signing key you use. Lifecycle ## A single verification, end to end 01 ### Request a challenge You issue a unique challenge and nonce over OpenID4VP, naming the exact audience and origin and the predicates you require — for example grade ≥ A3 and credential active. 02 ### Holder builds a bound presentation The holder constructs a presentation bound to your challenge, origin, policy, the current issuer status root and a finalized chain height. It is valid for just ten seconds. 03 ### Verify against finalized roots Your proof verifier checks the presentation, validates the requested domain, and confirms the issuer and verifier state against the latest finalized roots on-chain — reads it verifies with cryptographic proofs instead of trusting any RPC node. One session can clear multiple predicates. 04 ### Record a minimal decision 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. Zero-cost entry ## Verify at zero integration cost Verifying is free by construction — stateless, off-chain, no per-check fee. The entry packages make it free in effort too, on the permissionless verifier tier: ### Drop-in web widget A snippet that requests and verifies a presentation in the page, over OpenID4VP. No backend changes to start. ▭ ### Guest-verifier mobile flow Verify a presentation from a phone with nothing installed on your side — for occasional, in-person checks. ⊞ ### Printed-QR mode A static presentation-request poster: the holder scans, the result lands on the verifier’s phone. A bar, a rental, a home-services visit can verify with a piece of paper. Bonded verifiers add standing and reach on top — and for registered verifiers the deeper path is the SDK: the verification core embedded in your own stack. The permissionless tier is how you start today at zero cost. For registered verifiers ## Your stack, our guarantees The verification core is designed to be embedded: an SDK for your backend, or the same code run as a standalone service. You bring infrastructure — your registration, your exact origins, your keys, a durable nonce store, a clock you trust. The protocol brings the parts you cannot get wrong: the nine acceptance checks always run in full, presentations expire in ten seconds flat, every chain read is verified with cryptographic proofs instead of trusting a node, and the only thing your systems retain is a minimal decision record. None of it is configurable — a weaker verifier cannot be built from these parts. And you integrate from the language you already run: embed the core directly in Python, or use the thin TypeScript and PHP clients against a verification service you host yourself. The clients carry no cryptography and no policy — every decision, in every language, runs through the same single audited pipeline, and every SDK must pass one shared conformance suite before it ships. The SDK ships as a versioned package with the proof engine pinned inside, the service API contract is frozen, and the TypeScript client is done — integration starts as a design-partner conversation today, with the [technical integration docs](/en/sdk) open. The family now has a third member that is not another language but a protocol — an MCP server that makes verification a tool call for agent frameworks, with the same decisions and the same reason codes. Next and last in the committed client order: PHP. For agent runtimes ## Verification where agents live: MCP The natural integration point for agent identity is the agent runtime, not the browser — so the MCP server is built. It exposes the three operations of the frozen verifier-service contract as Model Context Protocol tools over stdio, so an MCP-capable framework drives challenge, presentation and decision without custom glue. Transport-only, like every other client: no cryptography, no policy, no external runtime dependencies, and it runs inside your own perimeter pointed at your own service instance. A rejected presentation comes back as a successful tool result carrying a reason code from the closed vocabulary — so an agent can reason about a refusal instead of retrying blindly. Registration is one stanza in your agent runtime’s configuration — the [MCP server docs](/en/sdk/mcp-server) have it verbatim, with the tool table and the trust boundary. ## Verify without becoming a data liability Registration and KYC approval put you on the verifier registry and let your users locally approve your domains as trusted — exact origins, no wildcards, and one verifier per origin, so a lookalike domain can never impersonate you. Once registered, you integrate on your terms: embed the verification core in your own backend, or run it as a service — the same pipeline and the same privacy guarantees either way. Talk to us about onboarding, or read how presentations, nonces and finalized roots fit together in the protocol. [Get registered](/en/contact)[Integrate verification →](/en/sdk)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/verifiers · For verifiers — verify credentials without storing PII — MintID