A verifier is a service that relies on wallet verification instead of collecting identity documents: you ask a structured question, the user consents, and you receive a cryptographic answer. This page is the operational path. For the technical request/response concepts, see the integration overview.
-
Understand tiers — and pick your minimum
Before any integration work, decide the lowest verification level that manages your actual risk. Most services need Standard; many need only Basic or a single proof such as over-18. Over-asking erodes user trust, adds liability and gains you nothing.
- Read the verification levels reference — what evidence backs each tier.
- If your question is yes/no (age, residency, score threshold), plan to request a proof rather than a tier.
-
Register your service on the network
Your organisation registers an on-chain identity that users' wallets display whenever you make a request. Users always see exactly who is asking — anonymous verifiers do not exist in this system.
- Registration establishes your service's keys and display identity.
- Verifier-side infrastructure versions are approved through on-chain governance (the x/veidregistry module), so users are never verified by unvetted code.
-
Integrate the verification request flow
Your service constructs requests naming the scope, the required tier or proof, and a plain-language purpose. The user's wallet presents this to them for approval — build your UX around the fact that the user can decline.
- Requests are structured; free-form data collection has no API.
- Test against the open-source reference stack before going live.
-
Handle the tier and score response
You receive a cryptographically verifiable result: the user's tier, a pass/fail against your threshold, or a zero-knowledge proof. Verify the signature or proof — never build logic that asks for underlying documents, because no such response exists.
- Treat a declined or expired consent as a normal flow, not an error.
- Store the result, not a re-request loop: repeated verification of the same fact is a design smell.
-
Meet your consent and receipt obligations
Every result you receive is tied to a consent record. You must honour revocation (no future requests after revocation until re-granted), respect expiry, and retain consent receipts so your processing is auditable.
- Revocation stops future access; results you lawfully received while consent stood remain valid history.
- Your service sees only its own grants — never a user's wider consent ledger.
-
Go live on the VirtEngine network
With integration tested and obligations in place, your service operates as a verifier: users present proofs, you get assurance, and neither side accumulates an archive.
- Talk to us before building production dependencies — the stack is reference infrastructure rolling out with the network.
What you never handle
Verifiers receive tiers, results and proofs — never document images, never biometric data, never unconsented claims. This is enforced by the protocol rather than promised by policy, which means it also protects you: there is no identity archive on your side to breach, secure or regret. The full table is on the for-services overview.
The rules, restated as commitments
- State your purpose honestly. Every request carries a purpose string shown to the user. Misleading purposes are grounds for removal as a verifier.
- Ask for the minimum. Request the lowest tier or narrowest proof that manages your risk — the proportionality principle is a protocol design rule, not advice.
- Respect the consent lifecycle. Expired and revoked consents fail closed. Build for it.
- No side-channel collection. Reconstructing or retaining more than the user consented to violates the terms that govern verifiers.
Ready to start?
Engineering documentation — the VEID module, consent framework specification and APIs — is at docs.virtengine.com. For onboarding conversations, email [email protected].