People have been asking where to get testnet coins on this forum for about ten years. It comes up often enough that I wanted to build one properly and keep it running.
Live: https://zcashfaucet.jinolabs.xyz
Paste a testnet address, solve a small proof-of-work in the browser, get 0.1 TAZ as a shielded z2z transaction.
Why I built it
I came to Zcash wanting to build application tooling and didn’t get very far, because the first thing you need is testnet coins. So I stopped and solved that first.
My view is that tooling and documentation are part of the protocol rather than something that comes afterwards. A missing RPC reference fails as quietly as a bug in the code, and it costs you more developers.
How it’s put together
The faucet runs its own stack rather than sitting in front of someone else’s:
| Piece | What it means |
|---|---|
| Zebra full node | My own view of the chain, no trusted third party |
| Zallet wallet, with Zaino embedded | Every send is built and broadcast by my own wallet, so nobody else can move the funds |
| Solo Equihash miner | It mines part of its own funding |
| Browser proof-of-work | No captcha vendor. It calls nobody and tracks nobody |
It was built on the post-zcashd stack from the start, since zcashd reached end of life on 2026-07-18. It runs post-Ironwood too. NU6.3 has been active on my testnet since height 4,134,000, the wallet’s notes sit in the corrected Ironwood pool, and it was paying shielded drips on the new circuit before mainnet’s own activation on 2026-07-28.
The rule it’s built around
This is the part I’d most like people to pick at.
Zcash transactions carry an expiry height taken from the tip your node reports. If your node has fallen behind, it will happily build a transaction that is already expired by the time it’s broadcast, so it can never be mined. A faucet in that state hands you a txid and a good feeling.
Mine checks its tip against an independent reference and refuses to build the payment instead. That decision is node.canBuildTx on /api/status, and it’s kept separate from the looser “is the node behind” signal on purpose. One question is about availability. The other is about money.
Three more rules come from the same idea.
“Working”, “broken” and “cannot tell” are three different answers, and only one of them is good news. An unreachable explorer isn’t evidence of a fork, and a check that couldn’t run must never read like one that ran and found nothing.
Being ahead isn’t the same as agreeing. A node in front of every external reference looks identical to a node on its own fork. That’s safe for an expiry height, since ahead can’t be stale, but it isn’t evidence that you agree with the network. The status text says exactly that rather than reporting a comfortable “in sync”.
Nothing reports success without checking what it left behind. The deploy confirms that the wallet accepts a new credential and rejects a deliberately wrong one. A probe that only ever sees a 200 can’t tell real authentication from a server that says yes to everything.
The tests work the same way. The ops suite runs 688 assertions, and it refuses to run at all on a machine without sha256sum, because in that one case a drift check compares two empty listings, finds them equal and passes while checking nothing. A suite that answers wrongly is worse than one that admits it can’t answer.
So do the measurements. The panel reads a heartbeat the miner writes itself rather than an environment variable saying mining is on, because a config flag can’t go false when the process dies. The box publishes what’s installed, the status page turns that into a verdict, and CI fails when the two disagree. unknown counts as a failure, not a pass.
Live as I write this: node ready at height 4,230,538, 1002 TAZ in the wallet, box 29 of 29 installed and enabled, miner heartbeat 2 seconds old. It’s all on /api/status with no login, so you can check rather than take my word for it.
What’s weak
Mining is a lottery ticket, not a budget. It won blocks 4,227,889 and 4,227,915 six minutes apart on 2026-07-31, which is 2.5 TAZ and the first income this has earned. It doesn’t change the arithmetic. A dominant miner on public testnet takes most heights and extends its own chain, so a small miner’s blocks usually get orphaned.
Chain-split detection isn’t finished. Comparing a block hash at a common height is what would actually detect a split. Today node.chain reports cannot-verify rather than an answer it hasn’t earned. I’m working on it.
There’s no published API contract yet. The endpoints exist but aren’t formally described, so anything automated has to guess at them. That’s first on the list below.
It’s one box. Quick to rebuild isn’t the same as highly available, and I don’t want to suggest otherwise.
Testnet only. TAZ has no monetary value. Don’t point this at mainnet, and don’t reuse a testnet key anywhere real.
What’s next
I’ll post progress in this thread rather than starting new ones.
- A published HTTP contract at
/.well-known/openapi.json, so CI jobs can rely on the endpoints instead of scraping them. - A claim path for machines (#134). Browser proof-of-work is decent anti-abuse and poor ergonomics for a CI job that needs TAZ at 3am. This is the harder of the two problems and I’d like opinions on it: a gate that a build agent can pass honestly but a farm still can’t cheaply farm.
- A real drip after every merge to main (#131), verified on chain. Green CI against mocks isn’t the same as a faucet that actually paid somebody.
- Finishing chain-split detection, so that
cannot-verifybecomes a real answer. - Alerting (#215). The watchdog and the smoke probe can spot a dead faucet but can’t page anyone yet.
It’s open source, and help is welcome
The whole thing is MIT and built to be run by other people, not just by me. CONTRIBUTING.md covers how to work on it, and there’s a local mock mode so you can develop against it without a node or any real coins.
Two kinds of help would make a real difference right now.
If you use it and something breaks or confuses you, please open an issue or just say so in this thread. Reports from people who aren’t me are worth more than my own testing, because I already know where the sharp edges are and I’ll route around them without noticing.
If you want to write code, the machine-friendly claim path (#134) is the most interesting open problem, and the API contract is the most immediately useful. I’ll review anything that comes in, and I’m glad to help someone get set up if the first hour is the hard part. It usually is.
And if you’d rather run your own copy than contribute to mine, that’s a good outcome too. That’s what the licence is for.
On money
I can cover the bills myself for a few months. After that I’d appreciate some help. There’s a fund page for that, and a donate page for testnet TAZ, which costs the giver nothing and goes straight back out as drips. While this is up, nobody has to run a node and mine their own TAZ just to test something. That’s the whole point of it. Keeping it that way is mostly a server bill, and if that’s covered I can put my time into the next thing in the way instead of this one.
What I’d like from the community
- Is 0.1 TAZ per address per day the right shape? It’s sized for someone testing a wallet flow. If you run CI, tell me what you actually need and I’ll size it against the reserve instead of guessing.
- If you run node infrastructure, the freshness gate and the ahead-versus-agreeing distinction are the claims I’m least sure about. If the reasoning is wrong, I’d rather find out before more things depend on it.
- What should a machine-friendly claim path look like? I have ideas but no strong opinion yet, and the people who’d use it are on this forum.
- What blocked you when you started building on Zcash? Testnet coins were the first wall I hit, so that’s the one I fixed. I’d like to hear the rest from people who aren’t me.
If you just need TAZ, it’s up, it’s shielded and there’s no signup. If it’s down when you try it, please say so here.
-- Aayush Giri · github.com/Giri-Aayush
