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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
A snippet that requests and verifies a presentation in the page, over OpenID4VP. No backend changes to start.
Verify a presentation from a phone with nothing installed on your side — for occasional, in-person checks.
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.
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 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.
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 have it verbatim, with the tool table and the trust boundary.
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.