Looking for feedback: Fauzec faucet and Zexplorer

Zcash Apps
1

Hi everyone,

I have been building 2 Zcash tools and would like feedback from the community before I harden the APIs and UX too much:

Both are still alpha. Fauzec is the more stable one. Zexplorer is moving faster, and some upstream-backed routes may still be rough while I keep improving the indexer and deployment path.

Fauzec is a testnet faucet that I want to be useful for scripts and automated tests, not only from a browser perspecttive. Zexplorer is a Zcash-only explorer and API that tries to be precise about what public chain data can show, what is private by design, and what a client can safely depend on

I am posting them now because I would rather hear what feels wrong while the architecture is still easy to change

Fauzec

Fauzec sends testnet ZEC from https://fauzec.com. It currently runs on testnet, sends 1 TAZ per claim, supports Unified Addresses and Sapling addresses, and publishes its HTTP contract at:


https://fauzec.com/.well-known/openapi.json

There is already useful faucet work in the ecosystem. ZecFaucet, for example, sends 1 TAZ to Unified Addresses and uses a browser proof-of-work challenge. Fauzec’s angle is the typed HTTP contract, idempotent claim state, shielded receipt memo, and a path toward automation that can still preserve abuse controls.

The part I care most about is the API shape. The faucet is not meant to be only a page where a human pastes an address and clicks a button. The claim flow is:


POST /api/v1/claim

GET /api/v1/status/{network}/{request_id}

That means a wallet test, SDK quickstart, local dev script, or CI job can submit a claim and poll until it sees confirmed, failed, or a cooldown/refusal code. The API accepts a caller-provided request_id, so retries can be idempotent instead of accidentally asking for multiple drips.

The public deployment still has an anti-abuse gate. The browser flow uses Cloudflare Turnstile for now. For real headless CI use, I am interested in feedback on the cleanest model: bearer-token allowlists, proof-of-work, GitHub Actions identity, or something else. The goal is to make testnet wallet validation easy without turning the faucet into something that gets drained immediately.

Some details that may be useful:

  • The API returns machine-readable error codes, including cooldowns, unsupported address kinds, faucet dry, wallet unavailable, and claim not found

  • Every shielded drip carries an encrypted receipt memo by default. The memo contains fauzec/v1, the request ID, the next eligible timestamp, and the support URL. Only the recipient wallet can decrypt it

  • The faucet mines and auto-shields its own testnet rewards, so it is not only waiting for manual refills

  • Donations are optional, and the donations panel tries to separate public donor-visible inflow from the faucet’s own mining and change flow

The memo is one place where I especially want opinions. I added it because it gives wallets and tests something deterministic to verify after the claim confirms. But it also occupies the memo field, so I want to know whether people see that as useful or noisy.

Fauzec feedback I would like:

  • Is the claim-then-poll flow the right shape, or would a long-polling request or webhook be better for tooling?

  • What would make this safe and convenient for CI without opening the abuse floodgates?

  • Is 1 TAZ per claim and a 24-hour address cooldown reasonable for current testnet workflows?

  • What examples would you actually use: curl, TypeScript, Python, GitHub Actions, wallet SDK tests, something else?

Zexplorer

Zexplorer is at https://zexplorer.app. It is a Zcash-only explorer backed by a custom indexer, with a typed API exposed at:


https://zexplorer.app/api/v1/openapi.json

There are already useful Zcash explorers and APIs, and they all cover different parts of the space. Some are multi-chain explorers with Zcash support. Some are more Zcash-native. Some have APIs, broadcast tools, payment disclosure tooling, viewing-key tools, or analytics.

With Zexplorer I’m trying a slightly different contract. I want every response to make these things explicit:

  • Which network the data came from: mainnet, testnet, or regtest

  • How fresh the indexed view is: tip-height, tip-hash, derive lag, observed time, etc

  • Which facts are public, which facts are temporarily unavailable, and which facts are private by design

The current API surface includes:

  • Blocks and block detail

  • Transaction detail and recent transactions

  • Mempool summary, activity, and rolling event counts

  • Fee summaries using Zcash/ZIP-317 language rather than Bitcoin fee-rate assumptions

  • Value-pool summaries for transparent, Sprout, Sapling, and Orchard when the upstream source can provide them

  • Typed search for blocks, transactions, and address-like inputs

  • Transparent address balance, UTXOs, and activity

  • Raw transaction broadcast

  • ZIP-311 payment disclosure verification (WIP)

  • A WebSocket stream at /api/v1/stream with topics such as chain.committed_v1, mempool.added_v1, mempool.mined_v1, and capability.changed_v1.

Zexplorer is less stable than Fauzec right now. The UI and some upstream-backed paths will change. I am sharing it early because the API vocabulary and first screens are the parts where community feedback is most useful.

Zexplorer feedback I would like:

  • Which explorer features are missing first: better transaction pages, testnet reliability, address pages, mempool views, fee views, value-pool views, charts, API examples, or something else?

  • Are the privacy labels clear enough, especially around shielded inputs, fees, payment disclosures, and address search?

  • Should I prioritize mainnet polish, testnet usefulness for builders, or both equally?

  • What would make you choose this API over an existing explorer API for scripts or wallet tooling?

What I am hoping to learn

  • Things that are missing

  • Things that are confusing

  • Things that should not be built this way

  • Things you would need before using either tool in a wallet, SDK, support workflow, or CI pipeline

In this early phases, lots of breaking changes are expected, but if you try either tool and something feels awkward, please let me know. The earlier the feedback comes in, the easier it is for me to fix the shape instead of patching it later.

Thanks!

6 Likes
2

Hey these are super cool I’ve spent couple hours looking for a faucet that works

would drop my honest feed back asap

Just glad to see this thought I’d reply

3

The mainnet explorer is ready zexplorer with some recent changes to how the information is displayed

2 Likes