I’ve been working through what it would take for a small business to run real operations on shielded ZEC. Accepting payment is the easy part now. The BTCPayServer plugin keeps improving and ZCG funded 0conf and multi account support in May. The hard part comes after the sale. The bookkeeper needs records and the auditor needs proof, and tax season doesn’t care that your chain is private.
Viewing keys are supposed to be the answer here. Hand your accountant read access without giving up spend control or exposing anything to the public chain. On paper that’s a better disclosure model than anything a transparent chain offers, because the business chooses who sees what instead of broadcasting everything to everyone.
But I can’t find much evidence that anyone uses them this way. Wallet support is uneven, and there’s no tooling that turns a viewing key into something an accountant would recognize, like an exportable ledger or a clean income report.
So I’m asking the merchants and builders here. Has anyone run real books off a viewing key? What broke? And if nothing like this exists yet, is that because nobody needs it, or because nobody’s built it?
Worth grounding this first, because the merchant-bookkeeping case and the regulatory case are the same primitive: a viewing key is just selective disclosure, “blind to the market, visible to a designated holder on demand, and no single party holds the whole picture.” That’s not only a convenience for handing your accountant read access; it’s the model I formally submitted to Brazil’s central bank (a Banco Central / DENOR public consultation on crypto-as-a-service), proposing exactly ZIP-316 viewing keys (IVK/OVK/FVK) with no spend power, the disclosure key held under threshold/MPC split across authorities, and every access written to an append-only immutable log (“audit the auditor”). Same building blocks the accountant case needs, one run-up.
And here’s the thing that makes your post land: the gap is identical on both ends. The primitive is mature and in production: Zcash shielded pools + viewing keys on mainnet for years, Halo 2 (no trusted setup).
What’s missing in both the merchant→accountant flow and the operator→regulator flow is the same unbuilt upper layer: the thing that turns a viewing key into an artifact the other side actually recognizes, a clean ledger for the accountant, a scoped + logged disclosure for the auditor. The encryption is done; the boring middle is not. So everything below applies to the regulatory framework as well.
We have already created examples of reconciliation systems using viewing keys: ZECA, shielded voting, and more to come.
We do this with CipherPay, merchant pastes their viewing key, we handle trial decryption and they get a real-time payment dashboard. Amounts, status, memos, CSV export. Fully non-custodial.
ZGo is a Zcash payment app that generates orders, handles currency conversions and keeps track of ZEC prices for users. All orders can be exported for accounting purposes:
If you use a local zebrad + local lwd server when connecting zkool’s graphql then YES! ( recommended! ) You dont have to do this however, you can use any public lwd server like zec.rocks with the caveat that you are trusting that lwd server.
Thank you so much! I asked about this but I think it may have gotten lost. I make privacy focused apps for the most part and I wanted to try and figure out an e2e solution LemonSqueesy is great because it takes care of taxes and all that for you. saneapps dot com if anyone wants to give ideas or feedback on how I can move more Zcash.
The piece that keeps getting flattened here is that “viewing key” isn’t one thing, and that distinction is exactly why accounting-grade export is harder than a payments dashboard. Roughly: an incoming viewing key (IVK) sees the notes you received plus their memos, an outgoing viewing key (OVK) sees what you sent, and a full viewing key (FVK) sees both and can also tell which of your own notes were spent. In unified terms that’s a UIVK vs a UFVK (ZIP 316).
The dashboards mentioned above are essentially IVK-based, great for “what did I get paid” (the receivables side). But a bookkeeper’s ledger needs the FVK, because you have to see outgoing payments and correctly identify your own change notes, or you double-count change as income. That classification layer (income vs change vs expense, reconciled against price at tx time, memos as line-item detail) is the boring-but-real thing nobody has built. The primitives already expose all of it (ZIP 316 keys, ZIP 302 memos); what’s missing is the accounting semantics on top.
One design point for the auditor case: to give an accountant scoped access you often want the minimal key (incoming-only) rather than the full one, so they see receipts without your entire spend history.
We are actively supporting builders for exactly this type of much needed tooling in our current hackathon!
