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

[Kenbak]

Added!

[Milton]

Actually more TOR nodes than I expected

Needs some UI fixes on mobile as you can’t see the TOR count unless you rotate to landscape mode

[Kenbak]

Will fix, thanks for flagging!

EDIT: FIXED

[Kenbak]

CipherScan - Milestone 2 Progress Report

Milestone 2 Deliverables - All Complete

#	Deliverable	Status
1	TX Linking (CipherScan + external explorers)	Done
2	TX Page Labels (Bridge Entry / Bridge Exit badges)	Done
3	Address Page Integration (Cross-Chain Activity section)	Done
4	Historical Swap Data (PostgreSQL + 7d/30d volume charts)	Done
5	Human-readable TX Explanations	Done
6	Database Optimizations (Materialized Views)	Done
7	API Input Validation (Zod)	Done

All 7 deliverables pass a 46-check automated verification script: verify.js

What Was Built

TX Linking
Click any cross-chain swap on CipherScan and it opens the ZEC transaction page with links to external block explorers (Etherscan, Solscan, Mempool.space, NearBlocks, TronScan, etc.) for the source chain side. Example: Transaction 5ae07a6b7a...8da40e | CipherScan — Zcash Explorer

TX Page Labels
Bridge transactions display “BRIDGE IN” / “BRIDGE OUT” badges in the transaction header with source/destination chain and token info (e.g., “TRON (USDT) → ZEC”).

Address Page Integration
Addresses with bridge activity show a “Cross-Chain Activity” section with swap history, entry/exit counts, and total volume bridged. Example: Transparent Address t1Ku2KLynd...9tfFP8ML | CipherScan — Zcash Explorer

Historical Swap Data
104,000+ swaps stored in PostgreSQL with paginated history, 7d/30d volume trend charts, and per-chain breakdowns. cipherscan.app/crosschain

Human-readable TX Explanations
Every transaction page now shows a plain-English summary sentence. Handles shielded, transparent, mixed, coinbase, shielding, deshielding, and bridge transactions.

Database Optimizations
5 materialized views pre-compute heavy analytics queries over 100k+ swap records. Response times dropped from 10s+ to under 350ms. Views are refreshed automatically after each sync cycle.

API Input Validation (Zod)
All API routes validate inputs with Zod schemas. Invalid requests return structured 400 errors with per-field details. Covers 11 endpoints including txid format, pagination bounds, period enums, and broadcast payloads.

Infrastructure & Backend Work

• NEAR Intents Integration: Full pipeline - API polling, token map resolution via 1Click API, Zcash txid matching, PostgreSQL storage, and automatic retry for unmatched swaps.
• Cross-Chain Analytics Page: Dedicated /crosschain page with volume charts, chain breakdowns, popular pairs, and live swap feed.
• Privacy Dashboard: /privacy page with shielded transaction stats, pool distribution, and recommended swap amounts.
• Swap API: Real-time swap initiation via NEAR Intents 1Click API at /api/swap.
• Newsletter System: Weekly digest pages at /newsletter.

Note on NEAR Intents Data

The NEAR Intents API does not always return transaction hashes for every swap. This can affect either side, sometimes the source chain hash is missing, sometimes the Zcash txid is unavailable. When a hash is missing, we cannot build an external explorer link for that leg of the swap. This is an upstream data limitation from the NEAR Intents API, not a CipherScan issue.

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

Kenbak

[gorusys]

I am getting a “Transaction Not Found” page when I search for a pending tx.
Is CipherScan not showing mempool transactions?

[Kenbak]

That is odd. You can see the mempool txs here normally.

Zcash Mempool Viewer | CipherScan

[hanh]

dunno why they keep moving … it’s a bit annoying to follow

[Kenbak]

There is a normal list below. it was to make it visual but i will improve it for sure.

[hanh]

Not sure what it is meant to convey… Also, they have less info than once mined.