Somewhere in 2026, “encryption” stopped being a technical property and became a decoration. It shows up in landing pages for wallets, allowlist tools, NFT drops, and “private” identity products, usually typeset in a terminal font next to a green glow. Most of the time, nothing behind the word is encrypted at all.

This article is built around a concrete review. In September 2026 we examined a Zcash-themed generative-art project that marketed itself with exactly this vocabulary: encrypted identities, faces assembled from noise, collectors who could be “known without being seen.” It looked polished. It was also, cryptographically speaking, empty. The site is not the point, and we are not naming it; the pattern recurs across dozens of projects. What follows is what we found, and the three checks that found it.

Finding 1: the locked vault was a timer

The project revealed its collectibles on a schedule: one new “encrypted identity” unlocked every 90 minutes, with locked ones displaying “identity withheld until this plate is decrypted.”

Viewing the page source answered the question in ten seconds. The entire collection, all thirteen names, handles, citation lines, and image paths, sat in a plaintext JavaScript array. The “decryption” was a function comparing the visitor’s clock against a reveal schedule and choosing which images to render. Nothing was encrypted. The data was published, just politely not drawn.

This is the single most common pattern in fake-privacy products: hiding from the interface is not hiding from the user. A timed reveal is a marketing mechanic, closer to an advent calendar than a cipher. The test costs nothing: before trusting a locked anything, open the source and search for the supposedly secret content. If it is readable, the lock is set design.

Finding 2: identity was a string in someone else’s database

The project’s whitelist, the thing membership actually depended on, was a registry of social media handles. You applied with your handle; the registry recorded the string; a status page let anyone type any handle and see whether it was on the list. No password, no signature, no proof of control at any step.

The problem is structural. A handle is an asset held at the pleasure of the platform. Accounts get phished and hijacked; handles get recycled after deactivation; verified badges are purchasable. A whitelist keyed to handles binds membership to a string, not to a person. When the string changes hands, the “identity” transfers with it, which is the exact opposite of what an identity system is supposed to guarantee.

Cryptographic identity anchors to a key pair instead. You demonstrate membership by signing with a key only you hold, not by typing a name into a lookup box. The project’s own home chain made this irony sharp: Zcash is a working system for exactly this kind of provable, selective disclosure. None of it was used.

Finding 3: no cryptographic act, anywhere

Step through the entire user journey and count the cryptographic acts: moments where the user proves something with math, a signature, a proof, a challenge-response. On this site the count was zero. That is the deepest tell. A system that never asks you to prove anything has no mechanism to verify anything. Its claims about who is verified, who is a member, and what is encrypted are all assertions in a database, stamped with a badge graphic.

The 3-step reality check

The review collapses into a checklist you can run on any “private,” “encrypted,” or “zero-knowledge” product in a few minutes.

Step 1: Read the source, and find where the data lives. Open the page source and search for the supposedly hidden content: locked items, whitelist entries, identity data. Plaintext in the client means the privacy claim is false at the first layer. Note the difference between “not rendered” and “not present”: the first is an interface choice, the second is the minimum for a real claim.

Step 2: Ask what the identity is anchored to. Platform assets (handles, phone numbers, email addresses) are custodial: the platform can take them away and hand them to someone else. Key pairs are yours. A whitelist, membership, or “identity” bound to a platform asset is a marketing list wearing a costume. Genuine systems let you hold the credential.

Step 3: Look for the cryptographic act. Somewhere in the flow, you should have to do something verifiable: sign a message with a wallet, present a zk-SNARK or ZKP proof, disclose a viewing key. If the entire product works without you ever proving anything, then nothing in it is proven. This step also catches the middle ground: some products do use real cryptography but only server-side, in which case you are trusting an operator’s promise rather than a protocol’s guarantee, a materially different risk.

What real looks like

For contrast, genuine optional disclosure has a recognizable shape:

  • Viewing keys (Zcash): grant a third party read-only sight of your own shielded-address transactions while spending control stays with you. The disclosure is cryptographic, precise, and revocable.
  • Membership proofs: a Merkle-tree commitment list where members prove inclusion without revealing which leaf they are. Real mixers like Tornado Cash work this way, which is also why their withdrawals are provable to anyone.
  • Signed messages: proving control of an address with a signature. The oldest trick in crypto, still the backbone of every legitimate verification flow, from exchange address ownership proofs to on-chain attestations.

The common thread: the holder performs a cryptographic act, anyone can verify it, and no platform sits in the middle.

Why this matters more than it seems

Fake-privacy products are not just harmless theater. Allowlists that run on handles get gamed by whoever controls the strings, so the “curated community” you paid for membership in can be silently repopulated. Products that claim encryption they do not have train users to lower their guard, exactly the population that later clicks a phishing drainer because the fake site “looked secure.” And in the worst cases, the privacy branding attracts people with real protection needs, who end up trusting a system whose protections are a costume.

The vocabulary is cheap because verification is cheap. Use the three steps, and price the claim accordingly.

Frequently Asked Questions

How can I tell if a website's 'encrypted' claim is real?

Run three checks. First, view the page source and search for the supposedly hidden content: if locked items are readable in plaintext, the lock is a user-interface effect, not encryption. Second, ask what the identity is anchored to: a social media handle belongs to the platform, while a key pair belongs to you. Third, look for a cryptographic action you perform, such as signing a message or presenting a proof. A site that never asks you to prove anything has no mechanism to verify anything.

Is a timed reveal a form of encryption?

No. A timed reveal compares the visitor's clock against a schedule and decides whether to render data that is already in the page. It hides content from the interface, not from the user. Anyone can read it in the source, and a changed local clock collapses the entire mechanism. Encryption would mean the data is mathematically unreadable without a key, regardless of timing.

Why is a social-media-handle whitelist not cryptographic identity?

Because control of the handle sits with the platform, not with you. Accounts get compromised, handles get reassigned after deactivation, and verified badges can be purchased. A whitelist keyed to handles verifies a string, not a person. Cryptographic identity, by contrast, is bound to a key pair only the holder controls, and it is demonstrated by signing, not by typing a name into a lookup box.

What does genuine optional disclosure look like?

Real systems let you prove something without exposing everything. Zcash viewing keys let an address holder grant read-only visibility of their own transactions to an auditor without giving up spending control. Membership proofs based on Merkle trees let someone show they belong to a set without revealing which entry they are. Signed messages prove control of an address. The common thread: a cryptographic act performed by the holder, verifiable by anyone, revocable by design.