Fig. 06 · The shielded lane: funded from the hub, held for 2-of-3 FROST approval, one Ironwood transaction, read by the auditor with a viewing key.
What each party sees
Vaults
Each(customer, period) gets its own shielded vault: a ZIP-32 account, or a FROST vault whose spend authority is split between signers. Because a viewing key is per vault, disclosing one customer’s October payments reveals nothing about any other customer, any other period, or the treasury.
A batch is one transaction
1
Payment request
The recipients, amounts and memos become a ZIP-321 payment request URI.
2
Build
zcash-devtool pczt create --payment-uri … builds one shielded transaction with N outputs as an unsigned PCZT (partially constructed Zcash transaction). Each output carries a ZIP-302 text memo, encrypted to its recipient.3
Prove
pczt prove adds the zero-knowledge proofs.4
Authorize
A single-key vault signs directly. A FROST vault waits for its threshold of approvals, then
corridor-frost co-signs.5
Combine and send
pczt combine merges proofs and signatures; pczt send broadcasts. The ZIP-317 fee is reserved from the delivered ZEC up front and booked to expense:zcash-fees from the mined transaction.Tooling
- zcash-devtool (librustzcash, Ironwood-aware), syncing through
testnet.zec.rocks. Its wallet database is read read-only for observation. The production path is the Z3 node stack and Zallet. - Orchard has been sealed since NU6.3 (July 2026), so all new notes land in Ironwood.
- Compact blocks carry no memos: after
sync, Corridor runsenhanceso memos are fetched and decrypted before reconciliation. - One small patch (
pczt create --payment-uri) lives inservices/zcash-frost/patches/.
Inside the saga engine
The shielded lane is not a separate subsystem. The planner produces:zcash.shieldedBatch splits the delivered ZEC across recipients by their USD share, builds and proves the PCZT, opens an approval request and waits until the vault’s threshold approves, co-signs with exactly the approving signers, broadcasts, waits for mining, and books one entry per recipient output plus the fee. Each delivery and broadcast is recorded durably so it is never repeated; failures after broadcast go to manual_review.