Zcash Block Explorer Grant

Nighthawk Team plans to develop an optimized, open source version of block explorer for Zcash.

Applicant background

Nighthawk Wallet Team has 20+ years of combined experience in software development, devops and cloud infra.

With this grant, we want to build a block explorer for Zcash that supports features requested by the community. Additionally, we plan to host the block explorer for both testnet and mainnet with tor support.

Motivation and overview

The goal of this grant is to make available reliable explorers without ads and built with modern frameworks. All open sourced for the community to participate in. The block explorer will serve the needs of Zcash users who need a reliable source of their Zcash transactions data and the status of the network. This grant falls under Zcash Foundation’s Mission of Innovation, Privacy(via tor hosted instance) & Inclusivity(enabling third parties to link to tx data).

Technical approach

Architect a Block Injector that works with zcashd and create a front UI to navigate the Zcash transactions, blocks. The Block Injector is a small program whose responsibility is to communicate with zcashd through RPCs and store the blocks in a block cache faithfully. This component will be implemented in Go lang in order to re-use components from lightwalletd. The block cache will be powered by a traditional db like Postgres, older blocks will be stored to power the features of the block explorer.

The explorer will be built with:

Elixir - a dynamic, functional language designed for building scalable and maintainable applications.
Phoenix - a web framework for the Elixir lang to build the explorer.
Tailwind - CSS for UI components.
The explorer will directly query zcashd RPCs for as much functionality as possible, but for certain features, it will query the block cache(mainly when creating index index of blocks and speeding up lookups).

Core features: Broadcast raw transaction, Payment Disclosure option for Sapling Shielded transactions, No logging/analytics

Functionality: No cookies

Add-on features: Get transactions by Viewing Key & JSON output, Network Statistics, Shielded Pool Balances, Hashrate, Tx Volume, Price

Hosting features: https + v3 onion No Google, no Cloudflare, no Amazon, no Github, no hCaptcha

Execution risks

Keeping up with upcoming changes in zcashd APIs with NU5 and ZIP 224. Possible change of plan to use zebrad instead of zcashd for querying block data.


Hosting stability with excess traffic and possible scaling woes. Decentralization is possible with open source code and ability for community members to host their own versions of Zcash block explorer.

Tasks and schedule

July/August Delivery Timeline: 5 weeks over 3 months to develop, fine-tune and host the block explorer.
Follow up grant will be scheduled to accomodate changes coming from the NU5 and Halo support.

Budget and justification

$37,200: Team Development, QA, Testing & Deployment Costs, Documentation, Github Page setup (5 weeks ~ 150 hrs @ $250/hr) Total: $37,200

$12,000: Hosting on Large Instances for 1 year + tor v3 setup, use lightwalletd.com infra for testnet blocks. $1,800: Devops costs to upkeep and monitor service, certs, warrant canary

Total: $37,200 + $13,800 = $51,000


I like many of the features of zcha.in , like mining pool statistics, shielded pools balances, hashrate, tx volumes, etc… but it doesn’t always work correctly for some reason.

Would also be good to have a payment disclosure option for Sapling shielded transactions. The one on Blockchair is only for Sprout:


It should be accessible via v3 onion.


I think it only makes sense to have Zcash explorer that supports Sapling payment disclosure (and viewing key if possible).

Also, I would like to see a guide for everyday user on how accessing the block explorer might compromise their privacy (network, cache, etc.).


@aiyadt I think it should be explicitly stated that the work will be Open-sourced.


It would be awesome if there was a URL you could point a viewing key at, and get a list of recent transactions to that viewing key in JSON.

If this could offer a proof that it was the complete list, that would be even better!

(You should definitely do some testing with this too to get a sense of resource use. Having a zcashd watch many different viewing keys is still expensive, in our experience. Back when Zbay used a full node we pushed for some changes that sped it up but it’s still tricky. You might be better off running a ton of lightwallet cli’s in parallel.)


Work on detection keys would be really useful too, though that’s probably out of scope.

This way you could look for transactions to an address without revealing them (just their existence) to the explorer.


This sounds like a great explorer, both in terms of features and diversity among the ecosystem. Having multiple explorers makes it easier to notice if there is a problem with one


feature requests:

  • transaction pusher, a la in in xmrchain.net, where you can paste a transaction as text/hex and have it submitted. rationale: those unable to route their client through Tor can still practically break (some of) the transfer layer chain between their IP and their transaction activity if they access the explorer through its onion address.
  • no cookies.
  • absolutely, ruthlessly no JS on the user-facing side.
  • absolutely, ruthlessly no connections outside the domain of the explorer. not even for DDoS protection. no Google, no Cloudflare, no Amazon, no Github, not even hCaptcha. only local and open source code shall run. if worried about DDoS, look for self-hostable alternatives.
  • the explicit exclusion of any logging or analytic features in the software. I can already see reluctance toward this, but if you design an explorer specifically for the most private coin, then make the most of user privacy. otherwise there’s no point to it.
  • toolkit to easily publish a warrant canary.

Thank you for your inputs @slush

I’ve added the broadcast transaction, no cookies/JS/captcha/analytics.

Would you mind expanding on the toolkit to easily publish a warrant canary?


“toolkit” may be an exaggeration, I mean having a dedicated section on the site for managing and viewing canaries, and showing an automatic alert if the canary is dead (this would require a server-side setting for canary frequency).

1 Like

This block explorer is very promising and I look forward to using it. Is there an ETA for completion?

1 Like

@Javier We’re looking at approx. 90 days timeline for development & testing, 10 days for optional deployment for hosting it. Add 15-30 days grant review period and 1-2 weeks for release of funds from ZF(following KYC/AML verification), I’d put out a Q3 release for the explorer.

1 Like

The grant application is live at ZF Grants - Zcash Block Explorer

1 Like

Thanks for bringing this up, we will research this after having the block explorer set up and come up with an implementation plan if feasible.

You may want to check out the open source Blockbook project from the Trezor team to see if you can leverage any of that work. Blockbook supports Zcash and powers Guarda’s Zcash and Ycash block explorers:



I spoke with Aditya at nighthawk a couple weeks back about the block explorer proposal and wanted to add notes here. ZOMG’s two main questions on this proposal were:

  1. Why do we need another block explorer?
  2. Will this pull focus away from the Nighthawk team’s work on their wallet?

For the first one, Aditya said that this block explorer is for ZEC specific features. He gave payment disclosures as one example, and we can see a lot of other examples in the requests from folks in this thread.

For the second, Aditya said their team is structured in such a way that they have someone who works on backend/devops and isn’t working on the mobile apps who can focus on this. For me this still raises some concerns about getting spread thin, since every new project will require a degree of management and come with some overhead, but on balance I think if it makes sense to Aditya and the Nighthawk Team that’s good enough for me and I think we should suppor them.

Looking forward to discussing this with others at the meeting tonight!

1 Like

I hope the ZOMG and Zcash Community see value in having an open source explorer that puts Zcash support first. The motivation section of this grant emphasizes on the reliability of an explorer. One of the well known explorer, zchain still hasn’t fixed the issue displaying incorrect transaction fees: Incorrect tx fee when sending ZEC from t-addr to z-addr · Issue #303 · ZcashFoundation/zecwallet · GitHub

Blockchair is a great service but it has trackers https://blockchair.com/terms/ads_20200114.pdf

Almost every stable cryptocurrency project has an open-source explorer which bring out the features of the specific chain, and as a creator of light wallets, having access to an up-to-date explorer is required to finish the end-to-end experience of a Zcash mobile user.


Great news!

We’ve approved this proposal!

I just checked now and I see that there’s just one milestone. We’d prefer to have this split up so that there’s some piece paid up front and some piece paid on completion.

Can you create milestones, say 2 or 3, along these lines, with appropriate payouts at each stage?

Once that’s done please ping me and I’ll approve it and set things in motion.


@ZOMG Thank you for approving the block explorer grant!

Following the upfront funding, we plan to start development, buy necessary software licenses for the UI components, setup 1 year term hosting for testing the initial sync and start alpha level deployment.

And over the next 2 months we will deploy a basic block & transaction explorer capability based on RPC. As part of the the delivery around 4 months from now(& before July) we will aim to deliver the Open Source Code with the performant block injector & Zcash specific features listed in the grant along with tor support.