Question 1

What do "confidence tiers" mean in the results?

Accepted Answer

Each leaked record is graded on a deterministic 5-tier confidence ladder: confirmed_stolen → sanctioned → academic_dataset → community_curated → dict_derived. Higher tiers mean stronger evidence that the address was actually compromised, not just theoretically derivable.

- confirmed_stolen: Address appears in a verified dump from a security researcher or law enforcement (e.g., a confirmed breach dump).
- sanctioned: Address tied to OFAC- or UN-listed wallets—not necessarily stolen, but high-risk.
- academic_dataset: Published in peer-reviewed blockchain analysis papers (e.g., Deanonymization datasets).
- community_curated: Curated by trusted OSINT contributors from darknet forums or phishing archives.
- dict_derived: Generated by applying dictionary attacks (e.g., brain-wallet BIP-39 passphrases) to known address-hash ranges — strictly a theoretical match, not evidence of actual compromise.

confirmed_stolen implies the private key or mnemonic was found verbatim in a breach. dict_derived means the address could be generated from a weak passphrase, but there is no record of that key being exfiltrated. Treat a dict_derived hit as a signal to rotate funds immediately — the key structure is weak enough that automated enumeration found it.

Question 2

Where does your leak data come from?

Accepted Answer

All 6.94M leaked records in KeyAudit originate from 25 public data sources, each credited on /en/source. These include OFAC sanction lists, ScamSniffer dumps, the Vasek FC16 academic dataset, GitHub-hosted blacklists, and password-breach corpora used to derive brain-wallet candidates via dict_derived patterns.

Each source carries one of five confidence tiers: confirmed_stolen, sanctioned, academic_dataset, community_curated, or dict_derived. The dict_derived tier explicitly marks theoretical matches from password leakage patterns—not stolen key material. You can inspect per-source methodology, collection date, and confidence justification at /en/source/.

Question 3

Why does a dict_derived hit not always mean my wallet was stolen?

Accepted Answer

A dict_derived confidence hit means KeyAudit's dictionary-derived generator produced the same address-hash as yours by iterating over weak brain-wallet seeds. This does not imply stolen credentials — only that your address is theoretically derivable from a low-entropy passphrase, not that anyone actually accessed your keys.

If your wallet uses a strong BIP-39 mnemonic (not a brain-wallet) or a high-entropy passphrase, a dict_derived hit is a false positive. The address collision stems from the same ECDSA derivation path matching a common password — a structural coincidence, not a security breach.

Treat dict_derived as a cryptographic test, not an incident alert. To confirm actual exposure, check for a higher-confidence tier like confirmed_stolen or sanctioned. For BIP-39 wallets, ignore dict_derived unless you intentionally used a brain-wallet with a weak password.

Question 4

Is my input stored on your server?

Accepted Answer

Plaintext of any query — address, mnemonic, or private key — is never stored on KeyAudit servers. All input is hashed client-side using WebCrypto SHA-256 via SubtleCrypto.digest() before the HTTP request is sent; only the resulting hash is transmitted.

For rate-limiting and deduplication, the hash is retained briefly in server memory. No plaintext fields appear in production logs, error reports, or persistent storage. The seeder input is discarded immediately after hashing — there is no plaintext logging at any layer.

Question 5

How can I protect my wallet from leak databases?

Accepted Answer

Use BIP-39 mnemonics generated on a hardware wallet or offline tool. Never type seed phrases into web pages, paste them into chat apps, or store them in plaintext files. KeyAudit does not require seed entry — only the address-hash or signature is submitted, and client-side SHA-256 via SubtleCrypto.digest() ensures the seed never reaches our server.

Avoid brain-wallet generation from reused or weak passwords — dict_derived entries in KeyAudit show that common phrases are routinely reverse-engineered from on-chain signatures. If you must use a brain wallet, feed a high-entropy passphrase through a proper KDF (e.g., 100000+ PBKDF2 iterations).

Before large sends, check the recipient address against KeyAudit’s 6.94M leaked records. Even a confirmed_stolen or sanctioned match warrants manual review. Use separate hot wallets for daily spending and cold wallets for storage — one leak in a single wallet does not cascade.

Finally, rotate any seed that appears in a public dataset. KeyAudit credits 25 sources (see /en/source) so you can verify if your wallet appears from an academic_dataset or community_curated leak. No web-based tool can guarantee full safety, but hashing seeds offline eliminates server-side exposure entirely.

Question 6

What is KeyAudit?

Accepted Answer

KeyAudit is a free, privacy-preserving intelligence platform that queries 6.94M+ leaked wallet records across 28 blockchains. It accepts an address, BIP-39 mnemonic, or private key and returns a trust-ranked verdict using a five-tier confidence model: confirmed_stolen, sanctioned, academic_dataset, community_curated, or dict_derived.

Unlike centralized checker services, KeyAudit hashes all seed and key inputs client-side via WebCrypto SubtleCrypto.digest() (SHA-256) before transmission. No plaintext secrets are logged or stored. The tool also includes a BIP-39 validator, brain-wallet derivation engine, and bulk dictionary importer for adversarial testing.

All source data is publicly credited on /en/source and drawn from 25+ curated leaks, darknet dumps, and academic research datasets. The dict_derived tier is explicitly labeled as a theoretical match — it indicates an address-hash collision from a password dictionary, not a proven compromise.

Question 7

How does the leak check work?

Accepted Answer

The leak check matches a wallet-derived hash against KeyAudit's 6.94M-record index. You paste an address or SHA-256 hash of a seed/private key — the client-side hash is computed using SubtleCrypto.digest('SHA-256', data) before the query is sent. No plaintext seed or key leaves your browser.

The hash goes to our public API, which first checks a Bloom filter for existence, then queries MySQL for confirmed matches. Because the hash is the searchable artifact (not the raw key), your secrets never transit the network. For dict_derived entries, the match is theoretical — a dictionary seed that could produce the address, not evidence of theft.

Question 8

Does KeyAudit charge for queries?

Accepted Answer

No. All queries via the web app and API are free, with no signup or account required.

Requests are processed entirely client-side: seed hashes are computed via WebCrypto SubtleCrypto.digest() (SHA-256) before leaving the browser, so no plaintext mnemonics are logged or stored. This design eliminates the overhead of user management and keeps operating costs low.

A future paid API tier for high-volume B2B use is under consideration, but the free tier will remain fully functional for individual security researchers and wallet owners.

Question 9

What is a brain wallet?

Accepted Answer

A brain wallet generates its ECDSA private key deterministically from a single user-chosen passphrase, typically by hashing the passphrase with SHA-256. Unlike hardware wallets or BIP-39 mnemonics, the passphrase is the seed — no randomness beyond the user's imagination.

This design is catastrophically insecure for any real-world passphrase. Attackers run dictionary-based sweeps against all funded addresses. The dict_derived confidence tier in KeyAudit specifically flags these: a theoretical match between a candidate passphrase and a leaked address-hash, not evidence of theft. In practice, 93% of keys in our 6.94M leak index trace to brain-wallet brute force.

Brain wallets rely on human entropy, which averages 2-5 bits per word. A GPU cluster enumerates all passphrases from Wikipedia lists in minutes. We recommend migrating to BIP-39 seed phrases (128+ bits of cryptographic entropy) for any wallet holding real funds.

Question 10

What is a seed phrase / mnemonic?

Accepted Answer

A seed phrase (mnemonic) is a human-readable encoding of a master private key, typically 12–24 words drawn from the BIP-39 wordlist. Each word represents 11 bits of entropy, with the final word containing a checksum derived via SHA-256. This structure provides guaranteed cryptographic strength—2048 bits of entropy for 24-word phrases—and eliminates the guessable patterns common in brain wallets.

Brain wallets rely on user-chosen passphrases, which often have low entropy (<30 bits) and can be brute-forced via dictionary attacks. In contrast, BIP-39 mnemonics enforce a fixed wordlist and built-in checksum, making them resistant to casual collision and guaranteeing uniform entropy distribution. Key generation from a seed phrase follows a deterministic path (BIP-32 or BIP-44) to derive hierarchical keypairs (ECDSA for BTC/ETH, Ed25519 for SOL).