An identity you own — not an account we keep.

No. You create a VERV ID with a passkey — the same face or fingerprint unlock you already use to sign in elsewhere. There is no wallet to install, no seed phrase to memorise, and no token to buy. A blockchain is used behind the scenes as a public notary, but you never touch it.

Yes — free today, with no payment details required. The core of VERV ID — your identifier, your credentials, signing in to apps, and recovery — is intended to stay free. Some AI-agent capabilities may become paid later, and we will say so plainly before anything changes.

No. VERV ID stands on its own. You can create one, hold credentials, and sign in to any app that supports it without any involvement in VERV governance. If you are a VERV member, the same identity also carries your membership — but that is an option, not a requirement.

No. Creating a VERV ID requires no personal information at all — not even an email address. Verification is a separate, optional step for the cases where an app needs to know something specific about you. Even then we keep only the result — that you are verified — and never the documents you showed.

It means the system is live and real, and that we are still hardening it. Everything described on this page works today unless the roadmap below says otherwise.

It also means there is no independent security audit yet, some steps still happen manually behind the scenes, and details can change. Treat it as a serious tool that is still proving itself.

Your recovery key is split into three shares, and any two of them rebuild it. Share A is in the recovery kit you saved when you registered. Share B is held by VERV. Share C is the one you gave to a trusted contact. Combining your kit with either our share or your contact's restores your identity on a new device — and no single share, ours included, can rebuild anything on its own.

Your trusted contact's share plus ours will still restore you. But if you lose your passkey and cannot assemble any two of the three shares, the identity is gone for good: we hold no master key and there is no reset. That is the honest trade for an identity nobody can seize or hand over — and it is why the kit is worth keeping somewhere safe.

Because “we did not quietly change your record” should be something you can check, not something you have to take on faith. We periodically publish a cryptographic fingerprint of the identity register to a public chain that we do not control. Anyone can confirm that the records we serve today match what was published then. It turns our honesty into something testable — by you, about us.

Four reasons, in the order that actually decided it.

• One ecosystem, one basis for trust. VERV's economy already lives on TON. Anchoring identity to a different chain would mean two chains, two sets of assumptions and two ways to fail — in a system whose entire purpose is a single coherent basis for trust.
• Reach. TON is the chain built into Telegram, which is the only realistic way to reach people at the scale VERV is built for — most of them not crypto users, and none of them required to become one.
• Anchoring is a permanent running cost. We publish fingerprints continuously, indefinitely — this is not a one-off deployment. TON ↗ fees are a fraction of a cent, which keeps frequent anchoring viable and free to you. On most alternatives it would be either prohibitively expensive or dependent on an operator we would have to trust, which defeats the point of anchoring at all.
• Speed. Finality in seconds rather than minutes, so how often we publish stays our decision instead of something the chain dictates.

Only fingerprints. Each entry is a 256-bit hash, a timestamp, and the address that published it. No names, no documents, no keys, no credential contents — nothing that can be reversed into personal data, today or in fifty years. Your identity document and your credentials live off-chain, where only you decide what they contain.

No. Records are batched and published by us, and the cost is ours. You never sign a transaction, hold a balance, or see a fee.

The chain is a notary, not the system of record. Your identifier, your keys and your credentials do not depend on it — they are built on open standards that work anywhere. Moving would mean publishing future fingerprints somewhere else; everything already published stays published, and nothing you hold stops working. That is deliberate: a chain choice should never become a trap.

We can issue credentials to you — that is the issuer's role, and every credential states plainly who issued it, so a verifier can always tell it came from us rather than from someone else. What we cannot do is act as you. Presenting a credential, approving a sign-in and authorising an agent all require your controller key, which is generated on your device and which we never receive.

We can suspend access to our hosted service and revoke credentials that we ourselves issued — both are visible and checkable, never silent. We cannot take your keys, your identifier, your vault contents, or credentials issued to you by anyone else. That is the practical difference between an identity you own and an account you rent.

Your keys, your vault and your credentials stay yours, and their signatures keep verifying under any standards-compliant software. Fingerprints already published to the blockchain remain there permanently, so the historical record outlives us. What you would lose is the hosted convenience — our resolution and revocation-status endpoints. We will not pretend that is fully solved; it is the hard problem in this field, and making ourselves less indispensable is exactly what the anchoring work is for.

No — and we do not plan to open it. You cannot read our implementation. That is a real cost to you, and we would rather name it than argue it away.

What we would ask you to weigh is how much reading it would actually settle. Published source lets you read code; it does not prove that the code published is the code running. No hosted service can prove that with a repository alone. So the trust here is deliberately not built on being readable — it is built on making the things that matter checkable from outside the server: your keys never reach us, and everything we assert is signed and verifiable using software that is not ours.

Those properties hold whether or not our source is public. Unlike source, you can test them yourself — see “What can I check for myself” below.

Not yet. An independent third-party audit is targeted for 2027, and we will publish the result — including what it finds, not a summary of the parts we like. An audit nobody outside the company ever reads is marketing, not assurance.

Until then, take the beta label literally: this is live, and it has not yet been examined by anyone outside the team. If you find a flaw before the auditors do, write to pen@vervdao.org — we would far rather hear it from you.

More than you might expect, roughly in order of how much it matters.

• That your private key never reaches us. It is generated in your browser when you register. Open your browser's network inspector and watch: only a public key is ever transmitted. Every other claim on this page rests on that one, and it is the easiest to catch us on if it were false.
• That your identifier stands on its own. Your identity document is public and resolvable. Fetch it directly and read the keys we publish against your name.
• That our signatures survive someone else's software. Credentials are standard SD-JWT-VCs, sign-in is standard OpenID Connect, and our public keys sit at the standard location. Verify one with any conforming library — you never have to use ours, or ask us anything.
• That we have not rewritten history. Once anchoring is switched on (see the roadmap), the fingerprints published on-chain let you confirm that the records we serve today match what we committed to earlier. That check runs entirely outside our reach, which is the whole reason for it.

In the European Union. Both the application servers and the database run in Frankfurt, Germany.

Yes — yourself, from your security settings, immediately and irreversibly. It removes your identity document, your vault, your username, your sessions and any AI agents you created. Credentials issued to you stop verifying, because the record they point to no longer exists. There is no soft delete and no retained copy.

Yes, and it is a first-class case rather than an afterthought. An agent gets its own identifier and its own keys, separate from yours, so its actions are attributable to it instead of blurred into yours. You create it from your agents console; its private key is generated in your browser, shown to you once, and never sent to us.

Exactly what you grant it, and nothing more. You issue it a signed authority naming specific limits — what it may spend, how often it may act, for how long, and what kinds of action are in scope. That grant is signed by your key, not ours; we never sign on your behalf and never hold a key that could. Anyone receiving the agent's request can check the grant independently and see precisely how far its authority reaches.

Revoke it. You can end a single grant or the agent's whole identity from the console, and it takes effect immediately. There is also a recovery path that rotates a compromised agent's keys and cancels every authority it was holding, so a stolen agent key cannot keep acting.

No. An agent identity is explicitly not a person and never carries personhood, membership or voting weight. It acts under a named human's authority, within stated limits, and every action traces back to whoever granted it. Making delegation explicit and revocable is the point — manufacturing extra voters is precisely what this design prevents.

Yes. VERV ID is an OAuth 2.1 provider and supports the Model Context Protocol, so an assistant can be authorised against your identity with a scoped, revocable grant, the same way any other application would be.

Verification is optional and layered. At the base, a VERV ID is simply a key you control and proves nothing about you. On top of that, an authority can verify specific facts — that you are a real and unique person, or that a legal identity stands behind the account — and each becomes its own credential that you choose whether to present.

When you verify, we derive a one-way identifier from that verification and keep it in place of your details. Each independent operator receives a different one, so unrelated apps cannot cross-reference you, and none of them can work backwards to your identity — yet within any one of them you can only ever be one person.

The honest limit: during the beta, verification is still reviewed manually, so this uniqueness guarantee is only as strong as that review. Automating it is on the roadmap below.

No. Documents are used to reach a decision and then discarded; we retain the outcome, not the evidence. There is no document store to breach and no copy of your papers to hand to anyone who asks for it.

Yes. It is standard OpenID Connect — Authorization Code with PKCE — so most existing OIDC libraries work unmodified. Self-service registration is not open during the beta, so write to pen@vervdao.org and we will register your app and walk you through it.

Only what that user consents to, scope by scope, at sign-in. The available facts include verification level, whether a legal identity backs the account, verified skills and certifications, reputation, and a scoped unique-person identifier. Independent operators receive different pseudonymous user ids, so two unrelated apps cannot tell they are looking at the same person unless the user deliberately reveals it.