CipherScan 2026 - Privacy Intelligence for Zcash

[Kenbak]

CipherScan 2026: Privacy Intelligence Platform for Zcash

Hello Zcash Community ,

I’m excited to share our grant application for CipherScan 2026. It’s been an incredible journey building in the Zcash ecosystem, and I’m looking forward to continuing this work with your support.

GitHub Application: Grant Application - CipherScan · Issue #179 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

Background

CipherScan started as a hackathon project in November 2025 and has grown into a full-featured Zcash explorer with a focus on privacy analysis. Cipherscan won 1st place in two tracks at the ZyPherpunk Hackathon (Zcash Data & Analytics and Data & Analytics), which validated the direction we’ve taken.

My goal for 2026 is to evolve CipherScan into a privacy intelligence platform, giving users and developers the tools to understand, measure, and improve their privacy practices on Zcash.

-–

What’s Already Live

Everything below is publicly available today:

- Mainnet Explorer: https://cipherscan.app

- Testnet Explorer: https://testnet.cipherscan.app

- Client-side Memo Decryption: Your viewing key never touches our servers (WASM)

- Inbox Scanner: Full wallet scan with viewing key, entirely in-browser

- Privacy Risk Detection: Linkability heuristics to spot common mistakes

- ZEC Flows: Cross-chain tracking via NEAR Intents (15+ chains)

- Privacy Dashboard: Real-time shielded adoption metrics

- Public API & Lightwalletd: Free infrastructure for developers

We also run a custom blockchain indexer built from scratch, currently indexing 3M+ mainnet blocks.

-–

What We’re Proposing for 2026

Cipherscan proposal focuses on three priorities:

1. Privacy Wallet Scanner

Upgrade the Inbox Scanner to show sent + received transactions, per-transaction privacy scores, and an overall wallet grade (A-F). Export options for PDF privacy audit reports.

2. Privacy Score API v2

New endpoints for wallet developers:

- Address and transaction privacy scores

- Common amounts with best anonymity sets

- Pre-transaction advisory

This lets wallets guide users toward better privacy before they transact, not after.

3. Human-Readable Transaction Explanations

Plain-language summaries on every transaction page. For new users, raw blockchain data is incomprehensible, we want to fix that.

Plus ongoing infrastructure maintenance (Zebra, Lightwalletd, custom indexer, database optimization).

-–

Budget Summary

Category	Amount
Infrastructure	$4,800
Development (25 hrs/week × 48 weeks × $45/hr)	$54,000
Total	$58,800

Grant funding keeps the API endpoints free for all Zcash developers.

-–

Milestones

Milestone	Deliverable	Completion
1	Privacy Wallet Scanner	Q1 2026
2	Privacy Score API v2 + Human-Readable Explanations	Q2 2026
3	Wallet Outreach + Privacy Index	Q3 2026
4	Infrastructure + 2027 Planning	Q4 2026

Deliverable order may shift based on wallet partner availability, protocol updates, or community priorities. Quarterly structure and total deliverables remain the same.

-–

Links

- Live Explorer: https://cipherscan.app

- Memo Decryption: CipherScan - Zcash Blockchain Explorer

- Privacy Dashboard: CipherScan - Zcash Blockchain Explorer

- ZEC Flows: CipherScan - Zcash Blockchain Explorer

- API Docs: CipherScan - Zcash Blockchain Explorer

- Devfolio (Hackathon): https://devfolio.co/projects/cipherscan-fa99

- Twitter: @cipherscan_app

-–

I’d love to hear your feedback and answer any questions. Thank you for considering this proposal!

— Kenbak

[Stupp]

Can Cipherscan detect shielded transactions?

[Kenbak]

What do you mean exactly by detect shielded tx?

We show shielded txs on the blockchain (with hidden amounts/addresses).

If it’s your tx, you can decrypt it with your viewing key, fully client-side, we never see your key.

[kralux]

excuse my ignorance on this question but how are we able to know the number of ZEC in each pool if the amounts for each shielded transaction is hidden? Is it by deducting it from the transparent count? If that is the case then how do we know when it goes from one shielded pool to another? Thanks!

[dismad]

As seen here,

This is true for Sapling, Orchard and any future shielded pool unless changed in the protocol.

[ZCG]

@Kenbak at the most recent meeting, ZCG voted to approve this proposal. Congratulations!

To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread.

Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests.

[Kenbak]

Thank you ZCG and the community for the support. Excited to deliver on the milestones and keep improving CipherScan for Zcash users and developers. Updates coming quarterly. Let’s Build!

[Kenbak]

CipherScan - Milestone 1 Progress Report (Q1 2026)

Milestone 1 Deliverables - All Complete

#	Deliverable	Status
1	Unified Address Decoder	Done
2	Mempool Explorer	Done
3	Accurate Fee Calculation (transparent, shielded, mixed)	Done
4	Supply & Circulating Supply APIs	Done
5	WASM Decryption Module (npm package)	Done
6	Decode Raw Transaction Tool	Done
7	Broadcast Transaction Tool	Done
8	Developer Tools Hub	Done

All 8 deliverables pass a 29-check automated verification script: verify.js

---

What Was Built

Unified Address Decoder

Visit any UA on CipherScan and it decodes into its component receivers (Orchard, Sapling, Transparent) in a tabbed interface. Example: cipherscan.app/address/u1fh3kwyl9…

Mempool Explorer

Live view of unconfirmed transactions from Zebra. cipherscan.app/mempool

Fee Calculation

Our Rust indexer now correctly computes fees for all transaction types, including fully shielded and mixed transactions using valueBalance fields. Fees are cross-referenced against 3xpl and Blockchair and match ZIP-317 expectations.

Supply APIs

Public endpoints for integrators:

• GET /api/supply — pool breakdown (transparent, sprout, sapling, orchard, lockbox)
• GET /api/circulating-supply — plain text (CoinGecko/CMC compatible)
• GET /api/circulating-supply?format=json — JSON with maxSupply

WASM Decryption Module

Published as @cipherscan/zcash-decoder on npm (v1.0.6). Decrypt shielded memos entirely client-side, your viewing key never touches our servers. cipherscan.app/decrypt

Decode & Broadcast Tools

Decode raw transaction hex client-side at /tools/decode. Broadcast signed transactions via /tools/broadcast. All accessible from the Developer Tools hub.

---

Infrastructure & Backend Work

• Rust Indexer: Fixed fee calculation for shielded and mixed transactions.
• Testnet Parity: Testnet now runs all the same as mainnet.

UI/UX Improvements

• Refreshed color scheme
• Network node map with Zcash-themed color tiers
• Tooltips on all network stats with sentence-case formatting
• Privacy widget layout improvements on the homepage
• Updated favicon and icons for crisp rendering at all sizes
• Improved light mode contrast
• SEO fixes

---

Happy to answer any questions. Thanks again for the support!

Kenbak

[operational-anxiety4]

A really cool project, and it’s obvious a lot of serious work has already gone into it. Having better visibility tools around Zcash privacy is something the ecosystem definitely benefits from.

That said, there are two things that feel a bit concerning to me.

First is the whole idea of privacy scoring. I get the intention – helping users avoid common mistakes – but turning privacy into a simple score or grade (A-F) can be misleading. Privacy on Zcash is very contextual. A transaction that looks “weak“ from a heuristic perspective might still be perfectly fine depending on the user’s threat model. My worry is that users will treat the score as an objective truth instead of a rough heuristic. If that happens, people might either get a false sense of security or panic over something that isn’t actually a real privacy issue.

The second thing is the risk of normalising chain analysis heuristics, even if the goal is educational. Tools that model linkability can unintentionally end up documenting exactly how transactions can be analysed. That’s useful for research, but it also means you’re effectively codifying analysis patterns that others can reuse. In privacy ecosystems this balance is always tricky: helping users vs strengthening the analysis playbook.

I think both of these are solvable, though. The key will probably be how the scoring presents (clear disclaimers, explaining uncertainty, maybe focusing more on guidance than grades) and being very transparent about the limits of the heuristics.

[Milton]

At the risk of appearing demanding, here is a new feature request: displaying how many of the nodes are connected through Tor.

[Kenbak]

Thanks a lot for the feeback! Here are my thoughts.

@operational-anxiety4

Privacy on Zcash is very contextual. A transaction that looks “weak“ from a heuristic perspective might still be perfectly fine depending on the user’s threat model

That’s fair, but I’d push back slightly. If a user uses only shielded transactions, their privacy is strong by default, there’s not much to analyze. The risks we flag come from mixing transparent and shielded behavior, like shielding and then deshielding a similar amount within minutes. That’s where most privacy leaks happen in practice.

The wording is deliberately cautious: we never say “this transaction is linked,” we say “this could be linkable.” I think for people already fluent in blockchain, the scoring might feel obvious. But for everyday users, it helps them understand why certain patterns are risky in a way that raw blockchain data never will.

Zcash has incredible privacy technology, but in my view, the tech is only as good as users’ habits. If we want better privacy practices, we need to make these concepts visible and understandable, not just hope people figure it out on their own.

@operational-anxiety4

The second thing is the risk of normalising chain analysis heuristics, even if the goal is educational. Tools that model linkability can unintentionally end up documenting exactly how transactions can be analysed. That’s useful for research, but it also means you’re effectively codifying analysis patterns that others can reuse. In privacy ecosystems this balance is always tricky: helping users vs strengthening the analysis playbook

I completely agree this is a real tension. But the reality is that chain analysis companies already use these heuristics, and more sophisticated ones, behind closed doors. The asymmetry today is that analysts have the tooling and regular users don’t. CipherScan tries to close that gap: if an analyst can spot your round-trip deshield, you should be able to spot it too, ideally before they do.

That said, you’re right that disclaimers matter. We do have them on the privacy risk page, but they could be more prominent. I’ll make them more visible. And we’re always open to community input on where the line should be drawn, if there’s a specific heuristic the community feels shouldn’t be surfaced publicly, that’s a conversation worth having.

@Milton Not demanding at all, good suggestion! I’ll look into it and add it to the roadmap if feasible