I’m announcing the first official production release of the NozyWallet CLI — an Orchard-first, shielded-only Zcash wallet for users who run their own node stack.
I’m doing server-side Orchard note scanning via a reserve UFVK (read-only) over lightwalletd — same trial-decryption / sync territory you’ve clearly solved at the wallet layer.
For read-only UFVK scanning, did you go through zebrad’s JSON-RPC or lean on lightwalletd’s compact blocks?
Hello @mrnobody for Orchard note discovery / trial decryption (what /api/sync and nozy sync use for balance today), we go through zebrad JSON-RPC getblockhash + getblockverbosity2, parse Orchard actions from the full block, then trial-decrypt with the wallet’s Orchard IVKs (external + internal). We do not trial-decrypt from the compact-block cache yet for that path.
lightwalletd compact blocks are a separate pipeline in our stack:
Zeaking (zeaking::lwd) downloads compact blocks over gRPC into local SQLite (lwd_compact.sqlite)
Exposed as nozy lwd sync-to-tip, POST /api/lwd/sync/compact*, desktop/extension companion LWD routes
That cache is for chain data / resume / future scan input it does not update balance or notes.json by itself
So today integrators can be in a split state: compact cache caught up, but balance still driven by an RPC note scan into notes.json. We fixed the worst bug there (sync overwriting vs merge + /api/balance reading the same store), but the architecture is still two steps until we finish the unified orchestrator.
The Landing:
For note scanning and balance, we use Zebrad JSON-RPC: one path to find notes and read balance, it works with Zebrad-only setups, witnesses and treestate come from the same RPC, and it’s simpler for integrators and deposit checks. The downside is it’s heavy on large rescans and isn’t ideal for server-side UFVK scanning at scale.
For compact blocks, we use lightwalletd only as a cache right now: less bandwidth, resumable SQLite, and the usual lightwalletd pattern that’s the long-term shape we want. The tradeoff is you need a separate lightwalletd service, and scanning plus witness replay from compact still isn’t fully wired on our side.
Do you see NozyWallet primarily as a power-user wallet for people running their own infrastructure, or do you eventually see it becoming something that can onboard less technical users as well?
Either way, it’s great to see more Orchard-first development happening in the ecosystem.
Thanks again — this clears up the tradeoff a lot. I’m wiring the same lightwalletd compact-block path into ZecPad’s reserve scanner, so your notes are well-timed. Will share how it goes once it’s tailing properly. Great to see more Orchard-first tooling here
I’ll say both for Now: Nozy is Orchard-first and built for privacy power users running their own infrastructure (zebrad, local keys, optional compact/LWD cache) a privacy hub when you control the stack. CLI is production-ready for that today.
Next: The mobile app is for less technical users everyday send/receive and wallet flows. Once Crosslink ships, we expect voters and stakers to use mobile/lighter clients without running a node, while operators keep the full self-hosted path.
Thanks for the encouragement and more Orchard-native tooling is exactly what we’re aiming for.
NozyWallet v2.4.1.1 — Teriyaki Hot (CLI Lite) is out.
We’ve productized the production nozy CLI as CLI Lite for operators and power users next to Zebrad: uptime/health checks, data peeks, sync/send — without the desktop WebView. Same wallet files and crypto core as before; not a second wallet.
appreciate the mention.