How VerifiedWallet is kept secure
We never hold anyone's crypto, wallet keys or identity documents, so a breach of our systems could not move a customer's funds. What we protect is trust (nobody must be able to forge or alter a certificate), data (the certificate register and the personal details we hold) and control (the accounts the service runs on). This page says what is in place, what each measure guards against, and what is still to do.
Nothing to steal from a wallet
Customers sign one message, which moves nothing. We never see a private key, a seed phrase or a balance we could spend.
Checkable without trusting us
Every certificate is signed with a published key. Anyone can check a certificate in their own browser; a changed one fails the check.
Documents stay with the checker
Identity documents, selfies and face scans are collected by our identity provider in its own secure flow. We receive the result, not the documents.
What we hold, and what we don't
We hold: the certificate register (every certificate, partner, verification and developer account); names, email addresses and phone numbers from the contact form and developer accounts; identity-check results (verified, rejected, pending — never the documents); and company details for Business certificates.
We don't hold: customers' crypto or wallet keys; identity documents, selfies or face scans (our identity provider keeps those for 30 days under its own controls); dates of birth (we keep only derived facts such as "over 18", and only when a company asked for them).
Certificate integrity
| Measure | What it guards against |
|---|---|
| Every certificate is signed (ES256) and our public key is published | A certificate that has been altered, or made by someone else, fails the signature check in any browser. |
| The wallet's own signature is checked using its network's signing standard and kept on the certificate | Bitcoin, Ethereum and every EVM network, smart accounts and Safes, Solana, Tron, XRP, TON, Cardano, Cosmos, Sui and Aptos each sign differently; we check the one that applies, with extra on-chain checks where control can change (Tron permissions, XRP master keys, multisig). |
| The signing key lives only in encrypted secrets on our hosting platform | It never appears in code, emails or on screen. |
| A key-swap procedure and a "re-sign everything" job | If the key were ever exposed we can switch to a new one and re-sign every genuine certificate, so anything forged with the old key stops checking out. |
| Payment and wallet checks happen on the server before a certificate is issued | A certificate can't be obtained by tampering with the page. |
| Signed messages for a company's verification request name that company and request | A signature collected for one request can't be reused to complete another. |
| Example and test certificates are marked and kept out of the public register | They can never be mistaken for, or counted as, real proof. |
Accounts and access
| Measure | What it guards against |
|---|---|
| Two-step sign-in on every service account (hosting, domain, payments, identity checks, email, code), with a passkey on the hosting account | A stolen password alone can't take over the service. |
| Domain transfer lock and DNSSEC | The domain can't be moved away without our approval, and nobody can forge its DNS answers to send visitors to a fake site. |
| The admin panel sits behind a second gate at the network edge, before its own sign-in | Everyone else is stopped before reaching the admin panel at all, so it can't be probed. |
| Admin sign-in: password, a second factor every time, lockout, bot check, strict session cookies, audit log | The admin panel can revoke certificates and see personal data, so it has the strongest sign-in we offer. |
| Access and API tokens reviewed regularly; unknown ones removed; notifications on account changes and deployments | Fewer ways in, and we find out quickly if something changes that we didn't do. |
Data and privacy
| Measure | What it guards against |
|---|---|
| Passwords stored only as strong one-way hashes; API keys, session and link tokens stored only as fingerprints | Even someone reading our database couldn't use them. |
| Selective disclosure: companies can ask for single facts (over 18, country, not sanctioned) instead of documents | Less personal data travels, so there is less to lose. |
| Website statistics without cookies and without IP addresses | We understand our traffic without tracking individuals. |
| Retention limits: contact messages one year, statistics 13 months, identity data at our provider 30 days | We keep data only as long as it is useful. |
| A company appears in the business directory only after the certificate's owner confirms by email | Nobody can list, or unlist, someone else's company. |
Website and API
| Measure | What it guards against |
|---|---|
| Security headers on every page: HTTPS-only, no content-type guessing, no framing by other sites, limited browser permissions | Downgrade attacks, disguised files and clickjacking. |
| Content Security Policy: enforced on the admin panel; on the main site in report-only mode while we confirm no wallet breaks | Injected or unexpected scripts. |
| Invisible bot check on sign-in, contact, support and checkout; rate limits on everything that can be flooded | Automated sign-ups, card testing, form spam, guessing and abuse that costs us or our partners money. |
| Every change must come from our own site; everything shown is escaped; every database query is parameterised | Cross-site requests, script injection and database injection. |
| Partner API: hashed keys, separate test and live keys, signed webhooks with timestamps, webhooks only to public HTTPS addresses | Forged webhooks, replayed webhooks, and the webhook feature being pointed at internal systems. |
| Partner spending limits checked at the start and the end of a verification; identity and company checks billed only once decided | Nobody can run up a partner's bill with signatures alone. |
| "Verify with VerifiedWallet": exact redirect addresses, PKCE, one code per sign-in, usable only by the browser that started it | Intercepted or replayed codes, and one person's verification being passed off as another's. |
| The address check warns about lookalike addresses, even ones with their own certificate | Address-poisoning scams, including scammers who buy a certificate for a lookalike. |
| Email anti-spoofing: DMARC (quarantine), SPF and DKIM | Email pretending to come from our domain goes to spam, which protects customers from phishing in our name. |
Backups, monitoring and incidents
| Measure | What it guards against |
|---|---|
| Nightly encrypted backup of the whole register (RSA-4096 + AES-256), 14 days kept, with a weekly copy held outside our hosting platform | Mistakes, bugs, tampering, and the loss of the hosting account itself. |
| The backup key is held offline, never on the server; a restore has been tested | Someone who broke into our hosting still couldn't read the backups, and a backup is only useful if it can be restored. |
| Health checks every five minutes on the website, register, identity checks, payments, email and blockchain data, on a public status page, with alerts when a part fails or recovers | We see problems as they happen, and so can customers and partners. |
| Paid always means issued: payments are confirmed to us by our payment provider as well as by the customer's browser, and anything unissued is flagged for a person | A customer paying and getting nothing. |
| An emergency switch that pauses all new certificates at once | If something looks wrong we can stop issuing while we investigate; existing certificates keep working. |
| A written incident plan | Covers supplier outages, a suspected key leak, account takeover, data restore and personal-data breaches, including reporting to the ICO within 72 hours where required. |
Review and testing
- Code security review, 14 October 2026 — an automated, AI-assisted review of the whole codebase, not an external audit. It found no way to forge a certificate, obtain one without paying, or get past the admin sign-in. Every finding it raised was fixed the same day.
- Automated tests — more than 330 checks run before every release, covering signatures for every supported network, payments, partner billing, sign-in, roles, backups and the fixes from the review.
- Dependency review — advisories in third-party libraries are assessed against how we actually use them; updates are tested with real wallets before release.
Still to do
- Enforce the main site's Content Security Policy once a period of reports shows nothing legitimate would be blocked.
- Update the flagged wallet libraries after testing each wallet type with a real wallet.
- An external penetration test or audit before taking on large partners, to complement the automated review.
We review these measures every quarter, and after any incident or significant change. This page describes what was in place on 15 October 2026 and is updated as it changes.
Report a vulnerability
If you find a security problem, please tell us before anyone else: use the contact form with "security" in the subject, and we'll reply within two working days. Please don't test against other people's certificates or accounts, and don't publish the issue until we've had a reasonable chance to fix it. We don't run a paid bug bounty, but we credit reporters who want it. A machine-readable version of this is at /.well-known/security.txt.