In three weeks, the Zcash ecosystem ran two very different experiments in what a whitelist can be.
The first experiment charged money. The second one is free, asks for almost nothing, and is the more interesting of the two — because when nothing is being sold, it is easier to miss what is being collected.
This article walks through both, with sources you can check yourself: the Zcash community forum thread where the first project’s grant proposal, rejection, and payment complaints are all public record, and the second project’s own pages. Then it extracts a hygiene checklist that applies to any crypto allowlist, on any chain.
The paid one: ZecBit
ZecBit presented itself as a marketplace for Zcash Shielded Assets — NFTs issued inside Zcash’s shielded pools. The technical ambition was real on paper: the team’s grant proposal to the Zcash Community Grants committee, submitted August 31, 2026, describes issuing ten testnet ZSAs in a single transaction and a metadata standard (ZMD-1) to help wallets display shielded assets safely.
The problem is what was being sold in the meantime. ZSAs — the asset standard defined in ZIP 226 and ZIP 227 — were not, and are not, live on Zcash mainnet. Community reviewer Shawn put it plainly in the forum thread: “ZSAs are not available on Zcash mainnet and there is no ETA on when or if they will ever be deployed on mainnet.” Whatever collectors were buying, it could not be the mainnet asset the branding implied. Reviewer strahncryptography went further: charging for a mint of something that only exists on testnet is, in their words, “a plain scam to fleece both his potential users and ZCG.”
The forum record shows what happened next, in order:
- September 3 — a would-be collector notes the mint is not free: “Not a free mint it’s $8 mint.”
- September 4 — the ZCG committee account declines the $48,000 proposal after review, citing details to follow in meeting minutes.
- September 5–6 — user CrashDiniz posts a payment complaint: they paid 0.1 ZEC for “zecbit-genesis #61,” the seller delisted the item while the shielded payment was in flight, and the order API now returns “cancelled” with no refund path. The full txid and block height are in the public thread.
Separately, reviewers flagged the growth pattern itself: a sudden wave of newly created forum accounts supporting the proposal, coordinated promotion on X. Whether or not those accounts were automated, the visible effect was a manufactured consensus — and manufactured consensus is exactly what a whitelist monetizes.
We wrote about the privacy-claims side of this wave separately: a Zcash-themed collectibles site whose “encryption” turned out to be plaintext data hidden by a timer. ZecBit and that case share a playbook — privacy vocabulary on top of a flow where no actual cryptography protects the buyer.
The free one: zaddr
zaddr.net appeared weeks later with the opposite economics. It is a whitelist for 2,800 pixel “faces” that will live on Zcash’s Orchard shielded pool. The mint is “not scheduled,” the price is “undecided,” and — the notable part — applying is free.
The application flow, per the project’s own apply page, is:
- Sign in with X, using read-only scopes (
tweet.read,users.read) — the page states “we read your handle. we cannot post, dm, or follow.” - Complete a task.
- Allocate your spot to a shielded address — the page accepts
u1…unified andzs1…sapling addresses, and repeats the good advice to “paste — do not retype.”
No email. No wallet connection. No signature. No payment. The project also runs a public checker where anyone can look up whether an X username holds a ticket, and a spread map that displays its growth: at the time of writing, 7,105 “infected” accounts across 114 countries, each country annotated with its “patient zero.”
Judged strictly as an application surface, this is close to best practice. Read-only OAuth. No secrets requested. Receiving addresses only. The WHOIS record shows the domain was registered September 11, 2026 — a six-day-old domain would normally be a red flag, but for a whitelist project a fresh domain is expected, and nothing about the flow itself is phishy.
So why does the free one deserve an article?
What a clean whitelist still collects
Because the product is not the pixel faces. The product — the thing being assembled, at zero monetary cost to participants — is a database with three columns: an X identity, a shielded address, and whatever the map’s IP geolocation contributes. Seven thousand rows so far, growing through a task-referral loop that the project gamifies with virus metaphors (“infected,” “contagious,” “patient zero”).
Look at each column:
The X identity. A handle is a platform asset, not a key you hold. It can be suspended, transferred, or sold, and it is anchored to everything else the platform knows about you. Our encrypted-claims review covered why handle-based membership is a marketing list, not cryptographic identity — that analysis applies unchanged here.
The shielded address. On its own, this is the low-risk item. A shielded address does not expose balances or history the way a transparent address does; that is the entire point of the shielded pools. Handing one over is closer to handing over a mailbox slot number than an account statement. The address is not the problem. The binding is the problem: once one company’s server holds “this handle → this shielded address,” the chain’s privacy properties are irrelevant to that record. Zcash’s cryptography hides the notes from the chain’s view. It cannot hide the row in a database you have never audited.
The metadata. The spread map uses IP geolocation (the page credits db-ip.com). Participation timestamps, task completion, referral chains — a whitelist built on virality necessarily records who infected whom. That is a social graph, and social graphs are re-identifying. Research on “anonymized” datasets has repeatedly shown that a few linking points — a country, a first participant, a time window — collapse privacy claims fast.
There is also a forward-looking cost. If the mint eventually costs ZEC, every participant will make a shielded payment to the project. The payment itself stays shielded, but the act of paying from your allocated address to the project’s address is visible to the project as a relationship: it confirms the address is funded, active, and controlled by the identity that registered it. The whitelist pre-builds the graph; the mint completes it.
None of this is hidden. The site’s own tagline is unusually honest about the inversion: “Every face is public. Every owner isn’t.” That is true of the chain. It is not true of the operator’s database — where every owner is exactly, nameably, on file.
The two models, side by side
| ZecBit | zaddr | |
|---|---|---|
| Cost to apply / mint | $8 per genesis plate | Free; mint unscheduled, price undecided |
| What you hand over | X sign-in + ZEC payment | X sign-in + shielded address |
| Asset at time of application | Testnet-only standard, no mainnet ETA | 2,800 faces, Orchard pool, not yet minted |
| Social proof | Forum swarm reviewers flagged as inorganic | 7,105-account virus map with country-level “patient zeros” |
| Outcome so far | Grant rejected Sept 4; 0.1 ZEC payment complaint with txid Sept 6 | Operating, whitelist open |
| What it is really assembling | Payments from buyers | An identity-to-address mapping |
Two different products, one shared insight: in the whitelist era, the first thing sold is never the NFT. It is participation itself — paid in money (ZecBit) or in identity data (zaddr).
Whitelist hygiene: what any application should and should not ask for
The Zcash pair generalizes. For any allowlist, on any chain, run these four checks before you apply:
1. Follow the money direction. A legitimate application takes nothing. If a whitelist wants payment “for your slot” or “to activate eligibility,” stop — fake airdrop channels run on exactly that instinct, and ZecBit is what the endgame looks like: cash out before the asset exists.
2. Read the OAuth screen. If a project asks you to sign in with X or Discord, check the permission list. Read-only scopes (tweet.read, users.read) let a project verify you exist. Write scopes (posting, DMing, following) let it run a spam operation from your account. zaddr’s flow shows what defensible looks like; the apply page even spells out what the token cannot do.
3. Count the cryptographic acts demanded of you. Exactly zero should involve secrets. Providing a receiving address: normal. Signing a message with a wallet: unnecessary for an allowlist and a favorite phishing vector. Exporting a viewing key or a seed phrase: disqualifying, in any context, ever. If you want a refresher on which Zcash secret does what, our shielded-address glossary entry and nullifier entry cover the pieces without math.
4. Price the social proof. A whitelist that markets urgency — infection counters, country leaderboards, referral tasks — is engineering FOMO on purpose. That does not make it fraudulent. It does mean the crowd you are trusting is partly the product being sold. A six-day-old domain with 7,105 signups is a growth story; a six-day-old domain with 7,105 signups and no product is a waiting room. You can leave a waiting room. You cannot un-give a mapping.
The takeaway
The ZecBit thread is a complete small-scale case study: an asset that could not exist on mainnet, sold for real ZEC, defended by a swarm, rejected by the community’s grant committee, and ending with a public txid and no refund. Save the forum link; it is one of the cleanest teaching examples of 2026.
zaddr is the opposite case, and the harder lesson. Nothing about it is a scam. The application is free, the scopes are read-only, the addresses are receiving-only. And still, everyone in that waiting room is handing over the same thing: a row in a database that binds who they are on X to where their funds will live on a privacy chain. The privacy Zcash gives you against the world does not extend to the company you volunteered the linkage to.
Free does not mean costless. On a whitelist, you are always paying with something — make sure you know what it is.
This article is educational analysis, not investment advice, and names projects only where public records (forum threads, on-chain transactions, WHOIS, project pages) support every claim made. Onchain Diary covers stolen funds and privacy pools and airdrop safety in related guides.
Frequently Asked Questions
Is zaddr.net a scam?
There is no public evidence of fraud at zaddr.net. Its application is free, its X OAuth flow requests read-only scopes (tweet.read, users.read), it never asks for a wallet connection, a signature, a seed phrase, or a viewing key, and a shielded address alone does not expose balances. The concern raised in this article is structural, not criminal: the project is building a centralized database that maps social identities to shielded addresses, and participants should recognize what they are handing over rather than assume 'free' means 'nothing at stake.'
Is it safe to give a project my Zcash shielded address?
The address itself is the low-risk part. A shielded address (a u1… unified or zs1… sapling address) does not publish its balances or transaction history the way a transparent Bitcoin-style address does. The higher-risk part is the binding: when you pair that address with an X account, an email, or an IP in one company's database, you have created an identity-to-funds mapping that no amount of cryptography on the chain can undo. If that database leaks or is sold, the mapping leaks with it.
What is the difference between a shielded address and a viewing key?
A shielded address is a receiving identifier. Sharing it lets someone send you funds; it does not let them see your history. A viewing key is a grant of read-only visibility into your shielded transactions, and an outgoing viewing key or spending key is far more powerful still. A legitimate whitelist will never need anything beyond a receiving address. Any project that asks for a viewing key, a spend authorization signature, or a seed phrase during an application is asking for something it has no business holding.
How do I spot a fake crypto whitelist or allowlist?
Four checks cover most cases. Check the payment direction: a real allowlist application takes no money; ZecBit charged for minting an asset that could not exist on mainnet. Check the OAuth scopes on any social sign-in: read-only scopes are defensible, write scopes are not. Check what cryptography you are asked to perform: receiving an address is normal, signing messages or exporting keys is not. Check the timeline: a domain registered days before a hyped mint, combined with referral-driven virality, is a pattern worth treating with patience rather than urgency.