Privacy Policy

Last updated: October 14, 2026

VouchMesh is a product of Quavolve. This page explains the current service's data handling. For privacy requests, contact [email protected].

Verification and account information

We receive your email address to send a verification code. Current verification challenge records contain a keyed email hash, a hashed code, timestamps and classification information without retaining the full address or organization domain. Email-delivery providers process the recipient address to send the message.

Historical challenge records or backups from older deployments may still contain a private organization domain. This is not disclosed by a new identity proof unless explicitly permitted for that verified child source.

If you register an account, we store your email address encrypted so the service can recover it for account functions. We also process login tokens, sessions, API-key hashes, webhook settings and usage records. Messages you send to support contain the contact details and information you provide.

AI-agent verification clients

An agent registration stores the encrypted pending email and name, a hashed verification code and registration secret, expiry and rate-limit metadata. After confirmation, the service stores private agent and API-key identifiers, mode, key hashes, creation and revocation state, and verification usage. The API-key secret is returned once and is not stored in recoverable form. The agent must control the authorized mailbox; no browser profile, owner identity, affiliation, personhood, registry endorsement or delegated authority is inferred. Test keys are isolated and not metered. Account deletion purges the owned agent registrations, API keys, pending challenges and associated usage records, subject to legally required retention.

Credentials are held in your browser. Server records also contain holder identifiers, credential identifiers, affiliation claims, issue and expiry times, and revocation information. Proof links have associated disclosed claims and access records. We do not ask for a government identity document in the current email verification flow.

The identity center stores private master and child identities, encrypted source claims, disclosure policies and hashed session tokens. Full email and organization domain are absent by default. You can explicitly choose encrypted retention of the verified address during verification. Retention alone does not authorize disclosure: sharing either field requires permission for that specific child, the master policy and the generated proof.

Google login requests only account authentication and email information (openid and email). Google processes the sign-in under its own privacy policy. We validate Google's signed account identifier and verified email, then retain a keyed hash of that stable identifier, your encrypted contact email, any signed Google Workspace domain, and authentication timestamps. We do not retain Google access, refresh or ID tokens, and do not request access to Gmail, Drive, contacts or calendars.

A Google login can restore your account's private master identity. A matching email address does not automatically join accounts or sources. Combining a different current identity requires your explicit merge choice. Signing out removes account and master-identity access from that browser; it does not delete your identity or sign out other devices.

The Google child source starts with anonymous disclosure and is valid for 30 days after authentication. Account contact information is separate from proof disclosure. Full email or a signed Workspace domain can enter a proof only after you explicitly allow that field for the concrete Google child, your master policy and the generated proof. A Gmail address does not prove control of its email domain. Turning off disclosure removes those retained child claims and invalidates older proofs through policy versions. Google account authentication does not establish employment or that the account belongs to a unique human.

A proof presentation discloses the claims selected for that presentation, together with technical information needed to verify it. Unselected claims are concealed from the recipient. This is selective disclosure, not a guarantee that a recipient cannot infer something about you from the claims or context. Anyone who receives a shareable proof link may open or forward it while it remains usable.

For proof-link analytics, the application derives a daily salted viewer hash from the request's IP address and browser information. It stores that hash, a timestamp, coarse region, device category and referrer domain. These are pseudonymous records. The analytics table does not store raw IP addresses or full browser headers. Network providers and other service components also process request information; this statement about the analytics table does not describe every network log.

New identity proofs store only the token hash, selected sources, policy versions, expiry and a usage counter. Opening a /v/ page does not reveal claims or consume a use; submitting verification does. The default is one successful use. Spent or invalid proofs disclose no identity information. Recipients can retain results already disclosed. These new proofs do not use the legacy proof-link analytics table.

Optional camera and biometric processing

When you choose a camera check, the service processes face video or frames to assess liveness and requested actions. This is automated processing with possible errors, not legal identity verification or a guarantee against impersonation. The browser flow asks for consent before capture. You can use email verification without choosing the camera check.

An optional, separately selected appearance estimate is subjective and intended for entertainment. It is not an objective assessment of a person.

Camera processing uses temporary server files. Cleanup is attempted after processing, with a periodic cleanup mechanism for older captures; failures or interruptions can delay removal. We do not promise immediate deletion in every case. The service also records limited consent receipts and liveness-related credential information. Do not submit recordings of someone else.

Retention and account deletion

Credential expiry and verification-code expiry control whether those items can be used; expiry does not necessarily delete the database record. Account, verification, credential, usage and analytics records can remain until removed.

The deletion control in your profile removes your account and linked records handled by that flow, including owned agent registrations, pending challenges, API keys and associated usage records. Some security, audit or legally required records may remain. Contact us to request review of remaining data or to ask for access or correction. Applicable privacy rights depend on your location and circumstances.

Account deletion removes linked Google provider records, pending Google login transactions, the account-to-master link and Google child sources. Associated identity proofs become invalid. Independently verified non-Google sources follow the existing identity and deletion rules.

Providers and browser storage

Hosting, network and email-delivery systems process data needed to deliver the service, including request information and email recipients. Startup and Growth use Stripe-hosted Checkout and the customer portal in test mode for evaluation. VouchMesh does not receive or store full card numbers. Stripe processes the payment and billing information under its own privacy policy; test-mode checkout does not create real charges.

The service uses separate session cookies for sign-in and private master identity management, and browser storage for your wallet. Knowing a master ID alone grants no access; merging requires authorization from both sessions and revokes the source session. Proof-link analytics use the pseudonymous records described above. Clearing browser storage can remove your local wallet; account sign-in is not a guarantee of wallet recovery.

Contact and updates

Send privacy questions and requests to [email protected]. Avoid including a recording, verification code or API secret in your message. We may need information to establish that a request concerns your account. We will update this page when our practices change.