ZECMON
witness node · linking…
> ENTER UNIFIED FULL VIEWING KEY
Read-only. Never a seed phrase. Nothing stored.
> LOCATING BIRTHDAY
key
—
Walking backwards from the chain tip in 50,000-block strides, looking for the earliest note this key can see.
—
- phase
- —
- birthday
- searching
- at height
- —
- blocks
- 0
- notes
- 0
- elapsed
- 0s
> NOTES WITNESSED
> NOTHING ABOVE NU6 — GO DEEPER?
We swept every block from NU6 to the chain tip and this key could not see a single note. That rules out any wallet funded in roughly the last year — but not an older one.
Looking below NU6 means walking back to NU5, the block Orchard itself began. That stretch of chain scans about ten times slower per block than the recent part, so a full sweep takes upwards of half an hour of real scanner time. It runs one at a time, in a queue.
In a hurry, or doing this often? Seneschal's paid scan takes the priority lane and returns the same result as JSON over x402.
> IRONWOOD
—
ABOUT · LIMITS · AGENTS
What this is
A unified full viewing key (uview1…) lets someone
read a Zcash wallet's incoming shielded notes. It cannot
spend. It is not a seed phrase — if what you have is twelve or
twenty-four words, don't paste it here, or anywhere that isn't your
own wallet.
Give us one and we scan the chain in front of you. First backwards from the tip in 50,000-block strides, hunting the earliest note the key can see — that's the wallet's birthday. Once it's found, the bar re-scales to birthday → tip and walks forwards, lighting up every note as it passes.
That backwards walk stops at NU6 (block 3,042,000). Below there the chain scans roughly ten times slower per block, and a full sweep to NU5 takes upwards of half an hour — so if we find nothing above NU6 we offer the deeper sweep rather than quietly spending the time. It runs one at a time, in a queue, and you are shown your place in it.
Two pools, one key
NU6.3 Ironwood activated at block 3,428,143 on 28 July 2026, adding a second shielded pool alongside Orchard. From that block, consensus steers payments to you into Ironwood — same addresses, same viewing key, but the notes land in a new commitment tree that older software cannot read.
Every scan here reads both pools and reports the union, so
a balance shown on this page is the whole picture. Notes in the
new pool are badged ironwood in the list, and the
Ironwood panel tells you which pool this key is actually
receiving into — which is the only thing a scan can honestly
observe. It cannot tell what wallet you run.
What we keep
Nothing. The key goes to our scanner in memory, lives as long as the scan job, and is never written to a database or a log. Close the tab and the job is cancelled.
Limits
- One scan at a time per browser — starting another aborts the first.
- Fair use per IP. A cold walk of the whole chain is real work. Hit the cap and the scanner says so, with a retry time.
- One deep sweep at a time, for everybody. Ask for one while another is running and you wait, with your position shown. Paying buys a place near the front of that queue — not a bigger scanner.
- First 50 notes listed. Every note found is drawn on the bar; the list is capped.
Heavier use
Unattended, scheduled, or more than a glance? Seneschal runs it as a service — Private Watch pings a webhook the moment funds land, and /v1/private/historical returns this same scan as JSON over x402. Fundraising instead? ziving.org.
For agents
Don't scrape this page. There are three machine surfaces:
- /agents.txt — what you can do here, in plain text
- /.well-known/agent.gopher — discovery card (Gopher-over-HTTPS)
- MCP — tools
winbit32_zecmon_info,winbit32_zecmon_scan,winbit32_zecmon_scan_status
zecmon.com · a winbit32 / seneschal instrument · scanning via orchard + ironwood · source