Your keys never leave this browser. No exceptions. No backdoors. Client-side generation, zero storage, verifiable in DevTools and on the live audit page.
TL;DR
- Keys generate in your browser — never on our servers
- We cannot see your keys — we neither receive nor store them
- Works offline — disconnect after load to prove it
- Open source — auditable code
- Live auditable — run 8 checks in-browser
01 — Architecture
Where your keys are generated
Vanitas serves static files only. Cryptography runs in isolated Web Workers on your CPU — in your memory, never on a remote machine.
Your browser
Main thread
UI · React
Web Workers
W1 · W2 · … · Wn — Ed25519 / secp256k1
Keys generated here — your CPU, your memory
Link to server
Static HTML / JS / CSS only · no key payloads · no key endpoints
Our server
Delivers files · cannot compute keys · no memory access · no key access
In your browser
- All JavaScript execution
- All cryptography
- RNG and keypair creation
- Pattern matching & downloads
Server cannot
- See private keys
- Access browser memory
- Intercept generated keys
- Track your patterns
02 — Storage
What we store (nothing)
Vanitas stores absolutely no data. There is no database, no analytics, no tracking. The forge runs entirely in your browser.
No private keys
No public keys / addresses
No patterns searched
No IP addresses
No timestamps
No user identifiers
No cookies
No analytics
03 — Crypto
Cryptographic security
Solana forges use Ed25519; EVM forges use secp256k1 + keccak-256. Randomness comes from the browser CSPRNG.
Algorithm
Ed25519 · secp256k1
RFC 8032 · SEC standards
Key gen
Web Crypto API · @noble
W3C · audited libraries
RNG
crypto.getRandomValues()
Hardware-backed CSPRNG
Entropy
256 bits
Industry standard private-key size
Encoding
Base58 · hex 0x
Solana · EVM compatible
Key security check
After a find, Vanitas can run live checks on entropy and randomness quality:
- Entropy verification — confirms full key entropy
- CSPRNG check — verifies secure RNG path
- Chi-square test — statistical randomness probe
- Distribution — uniform byte spread check
04 — Headers
HTTP security headers
Responses ship with strict headers that limit exfiltration and framing attacks.
CSP
Content-Security-Policy
Restricts scripts, workers, and connections to self
HSTS
Strict-Transport-Security
max-age=31536000 — forces HTTPS
Frame
X-Frame-Options: DENY
Blocks clickjacking via iframes
MIME
X-Content-Type-Options: nosniff
Prevents MIME sniffing
Referrer
Referrer-Policy: strict-origin-when-cross-origin
Limits referrer leakage
05 — Verify
How to verify yourself
Don't trust claims — confirm locally. Three short methods:
01 — Network
Network monitor
- Open DevTools (F12)
- Open the Network tab and clear entries
- Generate an address
- Confirm: zero requests during generation
02 — Offline
Offline test
- Load Vanitas
- Go offline (airplane mode)
- Generate an address — it still works
03 — Source
Code & audit
- Review workers in the repo (
vanity.worker.source.ts,eth.worker.source.ts) - Run the live audit
- Compare published worker hashes
06 — FAQ
Common questions
Can you steal my keys?
No. Keys never leave your browser, and there is no code path that transmits them. Audit the source or watch Network traffic to confirm.
What if your servers get hacked?
Attackers would still only get static files. The server never receives or processes keys — they exist only in your browser memory.
Are vanity addresses less secure?
No. The private key uses the same secure generation. Only the public address is filtered for your pattern.
Do you collect any data?
No. No database, analytics, or tracking. Everything runs in the browser.
Should I use this for large amounts?
For significant funds: generate offline, test with a small transfer first, and prefer a hardware wallet for long-term storage.
Still questions?
Talk to us carefully
Security comes first. For vulnerabilities, use responsible disclosure — not public issues. See SECURITY.md / GitHub Advisories.
