Summary
Add Zcash (mainnet + testnet) to the openscan-explorer/explorer-metadata repository so the explorer can load it the same way it loads Bitcoin and Solana.
Motivation
data/networks.json and the accompanying schema are the source of truth for which networks the explorer knows about. Zcash needs entries there before #398 can render anything. Filed here for tracking; the work itself lands in explorer-metadata.
Proposed Solution
1. schemas/network.schema.json — extend the type enum. It is currently ["evm", "bitcoin", "solana"]; add "zcash". This is the blocking change: without it the new entries fail schema validation.
Zcash is a Bitcoin fork and reuses the bip122: CAIP-2 namespace, so it is tempting to reuse type: "bitcoin". Don't — the RPC surface differs enough (shielded pools, hash_or_height as a string, numeric verbosity, object-bag address-index params) that the explorer needs its own adapter branch, which keys off type.
2. data/networks.json — add two entries, following the existing Bitcoin shape:
{
"type": "zcash",
"networkId": "bip122:00040fe8ec8471911baa1db1266ea15d",
"slug": "zec",
"name": "Zcash Mainnet",
"shortName": "Zcash",
"description": "Privacy-preserving cryptocurrency with shielded transactions",
"currency": "ZEC",
"color": "#F4B728",
"isTestnet": false,
"logo": "assets/networks/zcash-mainnet.svg",
"links": [
{ "name": "Website", "url": "https://z.cash", "description": "Official Zcash website" },
{ "name": "Docs", "url": "https://zebra.zfnd.org", "description": "Zebra node documentation" },
{ "name": "GitHub", "url": "https://github.com/ZcashFoundation/zebra", "description": "Zebra repository" }
]
}
Plus a testnet entry with networkId: "bip122:05a60a92d99d85997cce3b87616c089f", slug: "tzec", isTestnet: true.
Both networkId values are CAIP-2 identifiers derived from the first 32 hex chars of each genesis block hash, verified live via getblockhash(0):
| Network |
Genesis hash |
chain |
| Mainnet |
00040fe8ec8471911baa1db1266ea15dd06b4a8a5c453883c000b031973dce08 |
main |
| Testnet |
05a60a92d99d85997cce3b87616c089f6124d7342af37106edc76126334a2c38 |
test |
Note Zcash is not in the chainagnostic bip122 registry (which lists only Bitcoin, Bitcoin Cash, Litecoin and Dogecoin), so these are derived from the CAIP-4 rule rather than copied — same as how the Bitcoin entries were produced.
3. data/rpcs/ — add a zec/ directory alongside the existing btc, evm, solana.
⚠️ RPC availability is genuinely poor, and this is the main risk on this issue. I probed every candidate provider: zcash.drpc.org returns Unknown network, blockpi returns unknown host, lava.build 403s, and PublicNode, Ankr, GetBlock, Blockdaemon, OnFinality, Dwellir, AllThatNode and BlastAPI have no Zcash host at all. The only free no-key JSON-RPC endpoints are two Tatum gateways:
https://zcash-mainnet-zebrad.gateway.tatum.io
https://zcash-mainnet.gateway.tatum.io
Measured constraints on those:
- They share a single per-IP bucket of 5 req/min — verified by alternating rapid-fire requests across both hosts (1–3 succeeded, 4–8 all
429, regardless of host). Listing both buys redundancy, not throughput.
- The gateway whitelists methods. Working:
getblockchaininfo, getblockcount, getbestblockhash, getblockhash, getblock (verbosity 1 and 2), getblockheader, getrawtransaction, gettxout, getdifficulty, getmempoolinfo, getrawmempool, getnetworkinfo, validateaddress. Blocked with -32601: every z_* and getaddress* method, plus getinfo, getpeerinfo, getmininginfo, getblocksubsidy, getstandardfee, getbestblockheightandhash.
- An API key raises the rate limit but does not unlock any method — I tested a real key against all 14 blocked methods and every one still returned
-32601. The whitelist is fixed, not tier-based.
So a hosted-only setup supports the core explorer views (blocks, transactions, mempool, address validation) but cannot support shielded-pool or address-index features. Those need a self-hosted zebrad (mainnet RPC port 8232, enable_cookie_auth = false). Worth deciding up front whether we run one.
4. assets/networks/ — add a Zcash logo (zcash-mainnet.svg, and testnet variant if that is the convention).
Acceptance Criteria
Summary
Add Zcash (mainnet + testnet) to the
openscan-explorer/explorer-metadatarepository so the explorer can load it the same way it loads Bitcoin and Solana.Motivation
data/networks.jsonand the accompanying schema are the source of truth for which networks the explorer knows about. Zcash needs entries there before #398 can render anything. Filed here for tracking; the work itself lands inexplorer-metadata.Proposed Solution
1.
schemas/network.schema.json— extend thetypeenum. It is currently["evm", "bitcoin", "solana"]; add"zcash". This is the blocking change: without it the new entries fail schema validation.Zcash is a Bitcoin fork and reuses the
bip122:CAIP-2 namespace, so it is tempting to reusetype: "bitcoin". Don't — the RPC surface differs enough (shielded pools,hash_or_heightas a string, numeric verbosity, object-bag address-index params) that the explorer needs its own adapter branch, which keys offtype.2.
data/networks.json— add two entries, following the existing Bitcoin shape:{ "type": "zcash", "networkId": "bip122:00040fe8ec8471911baa1db1266ea15d", "slug": "zec", "name": "Zcash Mainnet", "shortName": "Zcash", "description": "Privacy-preserving cryptocurrency with shielded transactions", "currency": "ZEC", "color": "#F4B728", "isTestnet": false, "logo": "assets/networks/zcash-mainnet.svg", "links": [ { "name": "Website", "url": "https://z.cash", "description": "Official Zcash website" }, { "name": "Docs", "url": "https://zebra.zfnd.org", "description": "Zebra node documentation" }, { "name": "GitHub", "url": "https://github.com/ZcashFoundation/zebra", "description": "Zebra repository" } ] }Plus a testnet entry with
networkId: "bip122:05a60a92d99d85997cce3b87616c089f",slug: "tzec",isTestnet: true.Both
networkIdvalues are CAIP-2 identifiers derived from the first 32 hex chars of each genesis block hash, verified live viagetblockhash(0):chain00040fe8ec8471911baa1db1266ea15dd06b4a8a5c453883c000b031973dce08main05a60a92d99d85997cce3b87616c089f6124d7342af37106edc76126334a2c38testNote Zcash is not in the chainagnostic bip122 registry (which lists only Bitcoin, Bitcoin Cash, Litecoin and Dogecoin), so these are derived from the CAIP-4 rule rather than copied — same as how the Bitcoin entries were produced.
3.
data/rpcs/— add azec/directory alongside the existingbtc,evm,solana.zcash.drpc.orgreturnsUnknown network,blockpireturnsunknown host,lava.build403s, and PublicNode, Ankr, GetBlock, Blockdaemon, OnFinality, Dwellir, AllThatNode and BlastAPI have no Zcash host at all. The only free no-key JSON-RPC endpoints are two Tatum gateways:Measured constraints on those:
429, regardless of host). Listing both buys redundancy, not throughput.getblockchaininfo,getblockcount,getbestblockhash,getblockhash,getblock(verbosity 1 and 2),getblockheader,getrawtransaction,gettxout,getdifficulty,getmempoolinfo,getrawmempool,getnetworkinfo,validateaddress. Blocked with-32601: everyz_*andgetaddress*method, plusgetinfo,getpeerinfo,getmininginfo,getblocksubsidy,getstandardfee,getbestblockheightandhash.-32601. The whitelist is fixed, not tier-based.So a hosted-only setup supports the core explorer views (blocks, transactions, mempool, address validation) but cannot support shielded-pool or address-index features. Those need a self-hosted
zebrad(mainnet RPC port 8232,enable_cookie_auth = false). Worth deciding up front whether we run one.4.
assets/networks/— add a Zcash logo (zcash-mainnet.svg, and testnet variant if that is the convention).Acceptance Criteria
"zcash"added to thetypeenum inschemas/network.schema.jsondata/networks.jsonand passing schema validationdata/rpcs/zec/created with the reachable endpointsassets/networks/zebradfor the shielded/address-index surface