I’m Joshua Kassabian. I run CopperSeventhLLC, a software consulting firm, and I’ve submitted a Zcash Community Grants application for a project called the Zcash Selected-Payment Receipts SDK.
The project starts with a fairly simple problem:
How can someone prove the relevant facts about one shielded payment without giving another application an ongoing ability to observe their wallet activity?
Imagine I pay a merchant with shielded ZEC and later there’s a question about the payment. Maybe an invoice needs to be reconciled, support needs to confirm what happened, or a business needs evidence associated with an order.
The merchant needs information about that payment.
They shouldn’t necessarily need a reusable viewing capability that can continue observing other activity.
That’s the problem I’m proposing to solve.
What I’m proposing
The project would create an open-source way for a supported wallet to let a user select a payment, clearly preview what information will be disclosed, and export payment-specific evidence.
Separate software could then independently verify that evidence.
The grant would fund:
a versioned selected-payment receipt/evidence format
wallet-side export tooling with an explicit disclosure preview
an independent verification library and command-line verifier
a minimal Testnet reference wallet demonstrating the complete workflow
a separate reference merchant/invoice verification application
positive, negative, compatibility, and privacy-oriented tests
The reference wallet is intentionally small. I’m not proposing another general-purpose Zcash wallet. Its purpose is to provide a complete working implementation even if an existing wallet team does not integrate the SDK during the grant period.
Likewise, this is not another payment processor or accounting platform.
The goal is reusable infrastructure that those applications can integrate.
How this could work in a real merchant system
A selected-payment receipt does not have to operate in isolation.
A merchant may already have an authenticated customer account, order, invoice, or payment reference in its own system.
For example, suppose a merchant has:
Customer account → Order #1842 → expected payment reference
If an invoice-specific memo or other appropriate reference was captured as part of that payment workflow and associated with the merchant’s internal record, selected-payment evidence could then be independently verified and corroborated against that existing information:
That creates practical uses for payment support, invoice reconciliation, fulfillment disputes, and business records while preserving the ability to disclose one relevant payment rather than granting ongoing wallet visibility.
The receipt does not need to invent the customer relationship.
The merchant already knows its customer and order. The receipt supplies independently verifiable evidence about the selected shielded payment that can be matched against that relationship.
Being precise about what is actually proven
One thing I want to be careful about with this project is not turning a useful piece of evidence into a broader cryptographic claim than it actually supports.
A selected-payment receipt by itself should not automatically be treated as proof of the identity of whoever happens to present it.
Instead, the software should clearly distinguish between things such as:
the selected payment evidence is valid
the payment details match the expected invoice/reference
the relevant chain-confirmation requirement has been satisfied
the merchant’s authenticated account/order records establish the customer relationship
Those facts can work together without pretending they are the same thing.
The same philosophy applies to privacy.
Before exporting anything, the user should be shown what information the receipt actually makes available to the recipient, including memo information where applicable.
I think that transparency is particularly important for something being built for Zcash.
Why I think this belongs in the ecosystem
Zcash already has the hard cryptographic foundations.
There is existing payment-disclosure work, including ZIP 311, and maintained Zcash libraries contain relevant transaction-recovery primitives.
I’m not proposing to replace those or claim to have invented payment disclosure.
What I see missing is the practical end-to-end developer layer:
select payment → understand disclosure → export evidence → independently verify it → bind it to an application record → correctly communicate what was and was not established
That is what this grant is intended to deliver.
Where existing Zcash components already solve part of the problem, the project will reuse them. Where implementation produces something generally useful upstream, the intent is to contribute that work appropriately rather than maintain unnecessary forks.
Independence matters too
The grant-funded core would be open source and independently operable.
Creating or verifying supported receipts would not require a CopperSeventhLLC account or permanent hosted service.
If my company disappeared someday, the basic receipt format and verification tooling should not stop working because somebody forgot to renew a server.
There may eventually be commercial opportunities around integrations or managed tooling, but those are not required for the grant-funded infrastructure to remain useful.
Scope and funding
The full proposal requests $42,000, including $7,000 in startup funding, for a proposed 12-week implementation.
The project is divided into four milestones:
1. Establish the implementation baseline.
Formalize the versioned evidence model, disclosure boundaries, supported configuration, threat model, executable Testnet proof, negative tests, and initial independent technical review.
2. Build the complete reference workflow.
Deliver the reference wallet, local export workflow, standalone verifier, and consuming merchant/invoice application.
3. Exercise the implementation under failure and misuse conditions.
Expand compatibility, negative, privacy, duplicate-use, and chain-observation testing and have an intended-user representative independently reproduce the workflow.
4. Review and release it.
Complete scoped independent technical/security review, address material findings, and publish the open-source v1 release and documentation.
The first milestone turns the technical groundwork already completed for this proposal into a formal, reproducible implementation baseline. It establishes the supported evidence model, configuration, Testnet proof, threat model, and initial independent technical review before the broader reference implementation is completed.
That sequencing is intentional: privacy-sensitive infrastructure should begin from clearly documented claims and disclosure boundaries, with independent review incorporated early enough to strengthen the implementation rather than being treated as a final checkbox.
Full application
The complete application—including the technical approach, risks, budget, milestones, acceptance criteria, and disclosure boundaries—is here:
GitHub:
I’d especially appreciate feedback from people working on Zcash wallets, merchant/payment tooling, or the underlying cryptography.
Two implementation questions would be particularly useful:
1. Which existing merchant or wallet workflows would be the strongest first integration target for this selected-payment evidence model?
2. Which existing Zcash components or disclosure work should this build on or contribute back to so that it complements rather than duplicates existing work?
I’m also interested in technical challenges to the implementation or evidence boundaries. The goal is to build something that fits cleanly into the existing Zcash ecosystem and is genuinely useful to developers and users working with shielded payments.
Thanks @hhanh00. for requesting clarity around the technical approach sections implementation details. I wanted to share that response and attached it below
The exported material is an output-specific recovery key
The first implementation is a sender-side selected-output disclosure, not a new zero-knowledge circuit and not a signature from my service asserting that a payment happened.
For a supported Orchard output, the wallet would use the outgoing viewing key actually used for that output, locally, to derive its 32-byte outgoing cipher key (ock) from the action’s cv_net, cmx, and ephemeral public key. This uses the existing protocol derivation exposed through Domain::derive_ock; the reusable ovk is not included in the receipt.
This is an illustrative format, not a claim of an adopted standard. The amount, recipient, and memo are recovered from transaction ciphertext, rather than accepted as assertions in this JSON.
The reference wallet would preserve the local recovery capability and the mapping to the finalized transaction/action. Before export, it would run recovery itself and show the user what will be disclosed. If the required outgoing recovery material is unavailable, export is unavailable; I am not claiming this works retroactively for every wallet or for outputs deliberately created without outgoing recovery.
Relevant implementation: Orchard note encryption and outgoing-key derivation.
The verifier checks the actual transaction output
The verifier would obtain the full transaction from its configured chain-data source, parse it using maintained Zcash transaction libraries, recompute its transaction ID, and select the specified pool/action. It would not accept a receipt-supplied plaintext, commitment, or confirmation count as authoritative.
For Orchard, the recovery path uses OrchardDomain::for_action and zcash_note_encryption::try_output_recovery_with_ock. That path:
• Authenticates and decrypts the selected outCiphertext using ock, recovering pk_d and esk.
• Derives the note-encryption key and authenticates/decrypts encCiphertext.
• Parses the note under the correct domain, including its recipient, value, and randomness.
• Checks the recovered ephemeral secret against the note-derived value, the reconstructed ephemeral public key against the action, and the reconstructed note commitment against cmx.
The complete ciphertext matters: the memo is recovered through the encrypted-note path, not authenticated merely by comparing the note commitment. For the v5 Orchard example, ZIP 244’s transaction-ID construction commits to the action ciphertext, including the encrypted memo and outgoing ciphertext.
References: Recovery API, recovery implementation, and ZIP 244.
Orchard is the concrete example here, not an assumption that different pools are interchangeable. The implementation will pin a compatible library set and dispatch only explicitly supported pool/note/transaction versions. An Ironwood profile would use its corresponding domain and separate compatibility tests, not be silently treated as Orchard.
Chain confirmation is a separate check with an explicit trust model
Output recovery by itself does not establish that the transaction was mined. The reference verifier would use an operator-configured validating node, such as Zebra, for accepted-chain transaction and block information, and record the block hash, height, observed tip, and confirmation policy.
An externally hosted node remains a trust dependency and is identified as such; querying it can also reveal which transaction the operator is checking. The receipt itself is not an independent proof of consensus or a self-contained light client. Offline output checking remains possible with the transaction bytes, but cannot claim fresh chain confirmation without suitable chain evidence.
If the node is unavailable, the transaction is unconfirmed, or its recorded block is no longer on the accepted chain, the report reflects that separately. The merchant application does not mark an invoice paid from output recovery alone.
Reference: Zebra RPC transaction and block methods.
Invoice matching uses the merchant’s existing records
For the reference workflow, the merchant creates a random invoice-specific reference before payment and associates it with an authenticated account/order, expected recipient, and exact amount in integer zatoshis. The payment request places that reference in the selected output’s memo.
After recovery, the application compares the recovered recipient, amount, and memo reference with that existing invoice record. Recipient matching uses the concrete receiver for the selected pool, not merely a Unified Address display string. It does not trust an invoice ID added to the receipt after the payment, and it does not infer payer identity from knowledge of the memo.
Duplicate credit is prevented using an atomic uniqueness constraint on the underlying payment identity—(network, pool, txid, action_index)—rather than a hash of the exported file. Re-encoding or copying a receipt therefore cannot create a second credit in that merchant database. A matching payment stays associated with the pre-existing order/account; the receipt presenter is not automatically made its owner or authorized to receive a refund.
This establishes payment-to-invoice correspondence within the authenticated merchant workflow. It does not claim to identify who controlled the transaction’s spending authority.
The disclosure boundary and ZIP 311 distinction are explicit
The OCK approach permits recovery of the selected output’s recipient, exact amount, full memo, and associated note data. It is output-selective, not field-selective. The preview must disclose that scope; hiding a field in the UI would not make it inaccessible to a receipt holder.
This is intentionally not a ZIP-311 payment disclosure. ZIP 311 requires spend-authority evidence and explains the danger of treating a signature-stripped disclosure as valid. The proposed artifact therefore has a distinct type, no generic “payer verified” result, and no automatic downgrade from a failed stronger proof into accepted payment authorization.
The verifier would expose separate output, invoice-match, and chain-status results, with payer authority explicitly not established by this profile. Receipts are sensitive, forwardable disclosure material, so the reference workflow keeps them out of URLs, telemetry, public logs, and blockchain writes.
Reference: ZIP 311, particularly its verification and security considerations.
What remains to be implemented and validated
The grant work is the local export integration, safe artifact handling, transaction/pool dispatch, standalone verifier, chain adapter, invoice-binding example, and reproducible tests—not a reimplementation of the recovery cryptography. The reference wallet would be a thin controlled-Testnet application using the existing librustzcash wallet backend and local persistence; spending material remains local and is never supplied to the receipt verifier.
Milestone 1 makes this specific path executable with a real Testnet transaction and an independently reproduced verification run. The negative cases include the wrong OCK, wrong action/transaction, altered ciphertext, incorrect invoice details, unsupported formats, duplicated payment evidence, and unavailable or changed chain observations. Those are proposed acceptance tests, not results I am claiming have already been achieved by the complete toolkit.
The remaining review work is to assess this composition, its privacy boundaries, and the intended workflow—not to choose an unspecified cryptographic mechanism after funding.
Thank you for submitting your proposal. After careful consideration by the ZCG and a period for community comments on the forum, the committee has decided not to advance this proposal.
We genuinely appreciate the work and dedication you put into your application and hope you’ll continue to participate and contribute to the Zcash community. Meeting minutes.
The committee believes a standalone implementation will not deliver sufficient value to the community, but agrees that payment receipts are useful.
We refer you to ZIP 311: Zcash Payment Disclosures
and would encourage you to bring it to Ironwood with support from the protocol engineers.
