For services
Verify your users without holding their documents
Every identity document you store is liability: breach risk, compliance burden, and user distrust. Verification through the wallet gives you the assurance without the archive.
Start here
What verifiers receive
| You receive | You never receive |
|---|---|
| The user's verification level (Unverified, Basic, Standard or Trusted) | Identity document scans or images |
| A pass/fail verification result for your stated requirement | Photos, facial templates, or any biometric data |
| Zero-knowledge proofs for attribute checks (for example, over 18) | Date of birth, address or document numbers — unless the user explicitly consents to share a specific verified claim |
| Consented verified claims, where a user explicitly approves each one | Anything from scopes the user did not consent to |
Why this is good for you, not just users
Holding no documents means there are no documents to breach, no honeypot to defend, and a dramatically smaller privacy compliance surface. You get cryptographic assurance with none of the archive risk.
Integration, step by step
-
Decide what you actually need to know
Most services need less than they collect today. An age check needs “over 18 — yes/no”. A trust gate needs a verification level. Start from the minimum: you cannot leak what you never receive.
-
Register as a verifier on the network
Your service gets an on-chain identity that users' wallets display when you make requests — users always see exactly who is asking.
-
Request verification with a stated purpose
Each request names the scope and the purpose (for example, verification level Standard, to open an account). The user's wallet presents this to them in plain language.
-
Receive the result — never the documents
You receive the verification level and the answer you asked for: a pass/fail result or a zero-knowledge proof you can verify cryptographically. Raw documents and biometrics are not available to verifiers at any price.
-
Respect the consent lifecycle
Consents can be time-limited and revoked. When consent expires or is revoked, fresh requests fail until the user re-approves — build your flows to handle that gracefully.
The operational detail for each step is in become a verifier. Engineering documentation — APIs, the consent framework specification and the x/veid module — is at docs.virtengine.com.
Choosing a required level
Ask for the lowest level that manages your actual risk — over-asking erodes user trust and adds nothing:
| Level | Backed by | Appropriate when |
|---|---|---|
| Unverified | None — this is where every wallet starts. | Browsing services that accept the wallet |
| Basic | Basic identity details you enter yourself; A verification session that passes the network's early checks | Low-risk services and small transactions |
| Standard | A government-issued identity document, scanned front and back; A selfie with active liveness checks (blink, head turn, smile); Automated document reading (OCR) that matches the document to your details | Most participating services |
| Trusted | Everything required for Standard; Fingerprint or iris capture through your phone's secure hardware; Device integrity attestation (Google Play Integrity or Apple App Attest); A history of successful verification over time | Sensitive, high-trust roles — for example validator onboarding on the VirtEngine network |
The rules you agree to
- State your purpose honestly. Requests carry a purpose string shown to the user; misleading purposes are grounds for removal as a verifier.
- Ask for the minimum. Data minimisation is a design principle of the protocol, and requests are structured to enforce it.
- Respect revocation. When a user revokes consent, you keep historical results you lawfully received but lose all future access.
- No side-channel collection. Attempting to reconstruct or retain more than the user consented to violates the terms that govern verifiers.
Status
The wallet and verification pipeline are open-source reference infrastructure of the VirtEngine network. Talk to us before building production dependencies: [email protected].