Good night y’all! So happy to have finally contributed to Zcash by being a builder myself! That I get the grant or not, it’s super nice to be active for Zcash, and hopefully you’ll enjoy what I’ve been working on.
Link to grant request on github: Retroactive Grant Application - ShieldedScan · Issue #62 · Financial-Privacy-Foundation/ZcashCoinholderGrantsProgram · GitHub
Link to my explorer: https://shieldedscan.xyz/
Content of the request:
Terms and Conditions
-
I agree to the Grant Agreement terms if funded
I agree to Provide KYC information if funded above $50,000 USD
I agree to disclose conflicts of interest
I understand that this grant program is only eligible for completed work, as it is a retroactive grant program. Applications for planned or partially completed work will not be considered. All completed work will be verified and accepted by its intended users or their representatives, who will confirm that the outputs meet the required quality, functionality, and usability before the work is listed as an option for Coinholder voting.
I agree that for any new open-source software, I will create a CONTRIBUTING.md file that reflects the high standards of Zcash development, using the
librustzcashstyle guides as a primary reference.I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any merge, branch, pull request, and commit guidelines as exemplified in the librustzcash repository.
I understand all grants are valued in USD but will be disbursed in Shielded ZEC. I acknowledge and accept that disbursement amounts may fluctuate based on the ZEC/USD exchange rate at the time of payment.
Application Owners (@octocat, @octocat1)
Organization or Individual Name
ShieldedScan
Additional Team Members
None
How did you learn about the Lockbox: Coinholder Retroactive Grants Program?
By being active on X with the Zcash community
Requested Grant Amount (USD)
4060
Category
Infrastructure
Project Summary
ShieldedScan is a free, no-tracker, cypherpunk-styled Zcash block explorer. It lets users explore blocks and transactions, including cross-chain transfers, as well as shielded pools and network analytics through charts, tables and visualisations such as Sankey diagrams. The explorer also offers a free, keyless API.
Project Description
ShieldedScan is a Zcash block explorer built to give the community a different way to look at the chain, with an interface that fits Zcash’s cypherpunk atmosphere rather than the generic explorer look. It goes beyond browsing blocks and transactions: it adds analytics that help users make sense of transaction fees, shielded activity and the Ironwood migration, for example. Rather than seeing the chain only as UTXOs for transparent transactions and encrypted data for shielded pools, the aim is a global view of what is happening on Zcash and how it is evolving. I also put particular emphasis on cross-chain flows.
What is on the site today:
-
Chain browsing: blocks and block detail, transactions and transaction detail, address pages with full history, the mempool, and universal search over heights, hashes and addresses.
-
Shielded pools: all four pools including Ironwood, pool balances, shielding and unshielding volumes, and the Ironwood migration since activation.
-
Analytics: an analytics overview plus 11 dedicated charts; shielded supply, pool balances, shielding flow, transactions by type, median fee, fee totals, difficulty, block size, price, Ironwood balance and cross-chain volume.
-
Cross-chain: a transfer list with filters, per-transfer detail, and a flows view with Sankey diagrams and per-chain trends, covering NEAR Intents and Maya Protocol.
-
Reference pages: transparent rich list with balance-band distribution, supply accounting by value pool, a halving countdown, a market-cap comparison, and an observed reorg log.
-
API: a free, keyless public API with 26 documented endpoints, each with a pinned example and an in-browser playground at /api-docs.
-
Testnet: a second full deployment at testnet.shieldedscan.xyz, with its own node, database and API.
I run my own Zcash archive node (Zakura) with a derived Postgres index, on a single server, so there is no dependency on a third-party data provider. That covers all four shielded pools including Ironwood, per-transaction fees across the whole chain, address history, the transparent rich list, supply accounting by value pool, a halving countdown, and cross-chain ZEC movement collected from public swap protocols. The analytics are limited to what the chain actually publishes: counts, fees, net pool flows and shielding versus unshielding volume.
There are no trackers, no cookies and no request logging, and the API is free and keyless.
Some things are deliberately absent: no viewing-key field, no privacy score, no transaction linkability analysis. My focus is on aggregate views of the chain rather than analytics aimed at individual addresses. That said, all of it is public data, so if the community asks for a given metric I see no reason not to build it.
The end goal is a Zcash explorer that users enjoy, with selected analytics giving a more global view of the chain. Please note I launched the explorer less than two weeks ago, so it is very recent, but I am putting my heart into improving it.
Technical Approach (how you did it)
Architecture: The site is Next.js and TypeScript in strict mode, deployed on Netlify. Chain data comes from my own Zcash archive node with a derived Postgres index, both on a single server. The frontend reaches them only through a read-only API on that machine; Postgres and node RPC are never publicly exposed. The data types mirror Zcash’s own semantics rather than what happens to be convenient for the interface, and the UI has no knowledge of where its data comes from, so the source can change without touching a page.
Building the index: A follower service walks blocks from the node into Postgres. The full transaction backfill ran from genesis to the tip and completed on 2026-07-31, and I verified it before trusting it: no blocks missing transactions, transaction counts reconciling against the blocks’ own totals, and addresses checked against the node. Per-transaction fees were derived across the whole chain on 2026-08-01, with coverage stated on the page wherever it isn’t complete. A gap in historical difficulty, caused by adding a column after part of the chain had already been ingested, was found and repaired on 2026-08-08. Aggregations that would otherwise scan millions of rows are materialised and refreshed on timers, and chain list pages use keyset pagination rather than offsets, so paging cost doesn’t grow with the chain.
Node: Zakura in archive mode, currently v1.1.0, upgraded from v1.0.5 on 2026-08-06. Zakura releases carry an end-of-support height at which the node halts, so a cron job alerts on new releases and approaching deadlines. Ironwood (NU6.3) activated on mainnet on 2026-07-28, adding a fourth shielded pool, which required changes to fee derivation and pool accounting.
Correctness process: Two rules did most of the work. Anything the chain doesn’t state directly, like a block’s miner or a transaction’s fee, is computed in one place and used everywhere, so the index and the page can’t disagree. And nothing counts as verified until it’s checked against something independent: the node, an outside source, or the deployed site itself. Reading configuration or passing tests proved unreliable often enough that curling production became routine.
Testing: CI runs formatting, type checking, linting, unit tests and a production build on every push. A Playwright suite then checks properties rather than known values: that no page overflows on a phone, that pagination never duplicates or skips a row, that a list row and its detail page agree, that shielded values never render as numbers, and that every text colour is readable against its background by the WCAG AA standard.
Deployments: Two independent ones, mainnet and testnet, sharing one codebase with separate nodes, databases and credentials, so testnet figures can’t render as mainnet. Testnet went live 2026-08-05, and the public API launched 2026-08-01.
Time Period of Work Completion
July 2026 - August 2026
Total Budget (USD)
4060
Budget Breakdown
- Compensation:
- $(USD): 4000
- Justification: Covers frontend, indexer and API development, node and database operations, design and product decisions. This is time already spent building and launching the explorer, not a forecast.
- Technology/Software:
- $(USD): 0
- Justification: The stack is entirely open source (Next.js, TypeScript, Postgres,
Zakura, Hono, Playwright). No licences or paid tooling.
- Infrastructure/Hosting:
- $(USD): 45
- Justification: Costs already incurred and self-funded: the server hosting the
Zakura archive node, Postgres and the API from late July, block storage added in
early August, and Netlify frontend hosting. Partial months, hence the small figure.
- Services/Contractors:
- $(USD): 0
- Justification: All development and operations handled by me. No contractors,
agencies or paid data providers. Chain data comes from the node I run, and
cross-chain and price data from free public APIs.
- Other:
- $(USD): 15
- Justification: Domain registration, paid for the current term.
- Total $(USD): 4060
Previous Funding
No
Previous Funding Details
No response
Other Funding Sources
Yes
Other Funding Sources Details
I accept shielded ZEC donations on the site, but they have brought in very little so far and are unlikely to cover infrastructure costs.
Success Metrics
An honest limitation first: the explorer has no trackers, no cookies and no request logging, so I have no visitor counts or per-user statistics to report. What I can evidence is what exists and that it works.
Quantitative
- A complete index of Zcash mainnet from genesis to the tip and in sync, covering every block and transaction with transparent inputs and outputs resolved and per-transaction fees derived.
- A free, keyless public API with 26 documented endpoints, each with a working example and an in-browser playground.
- A second full deployment for testnet, with its own node, database and API.
- All four shielded pools supported, including Ironwood from the day it activated.
- Cross-chain ZEC transfers collected from two public swap venues, shown as flows and as individual transfers.
- 22 end-to-end test suites alongside unit and component tests, checking properties across every page rather than known values.
- No user data collected: no cookies on any route, no request logs, no client-side storage.
Qualitative
- Zcash has another independent explorer, with its own node, index and API, so the ecosystem’s public view of the chain does not run through a single provider.
- Analytics that cover shielded pools, cross-chain flows and network activity.
- An API anyone can use with no account, no key and no identification.
- A design built for Zcash, with a cypherpunk-styled interface.
Proof of completion
Mainnet: https://shieldedscan.xyz/
Testnet: https://testnet.shieldedscan.xyz/
Conflict of Interest Disclosure
I work as a Product Manager at Routescan, which operates block explorers for EVM chains. ShieldedScan is an independent personal project with no connection to Routescan: it was built and is operated on my own time, on infrastructure I pay for personally, using no Routescan code, data, tooling or resources. Routescan has no interest in ShieldedScan, no claim on it. Any grant funds would be paid to me personally rather than to my employer.
I have no other affiliation with Zcash organisations, no relationship with ZCG members, and no financial interest in any other Zcash explorer or in any project this application would compete with.
Community Forum Posting
- I understand it is my responsibility to post a link to this issue on the Zcash Community Forums after this application has been submitted so the community can give input. I understand this is required in order for the community to discuss and vote on this grant application. Note: If you are unable to post on the forum (for example, due to new user restrictions), please leave a comment below, and we will adjust your posting permissions.