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 are actively supporting builders for exactly this type of much needed tooling in our current hackathon!