# Grant Application: Zcash Selected-Payment Receipts SDK

**URL:** <https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729>\
**Category:** Applications\
**Created:** [September 21, 2026, 3:13pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729 "2026-09-21T15:13:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![inkedinlove](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/inkedinlove/32/48534_2.png) [@inkedinlove](https://forum.zcashcommunity.com/u/inkedinlove)\
**Post date:** [September 21, 2026, 3:13pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729/1 "2026-09-21T15:13:48Z")

</div>

Hi everyone,

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
- documentation and a threat model
- independent Zcash-domain technical/security review

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:

**Customer account → Order #1842 → expected reference → verified selected payment**

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:**

> <https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/437>
>
> \### Terms and Conditions
> 
> \- \[x\] I agree to the \[Grant Agreement\](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded
> \- \[x\] I agree to \[Provide KYC information\](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
> \- \[x\] I agree to disclose conflicts of interest
> \- \[x\] I agree to adhere to the \[Code of Conduct\](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and \[Communication Guidelines\](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
> \- \[x\] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
> \- \[x\] I agree that for any new open-source software, I will create a \`CONTRIBUTING.md\` file that reflects the high standards of Zcash development, using the \[\`librustzcash\` style guides\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
> \- \[x\] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any \[merge\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), \[branch\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), \[pull request\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and \[commit\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the \`librustzcash\` repository.
> \- \[x\] I agree to post request details on the \[Community Forum\](https://forum.zcashcommunity.com/c/grants/33)
> \- \[x\] I understand it is my responsibility to post a link to this issue on the \[Zcash Community Forums\](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
> 
> \### Application Owners (@Octocat, @Octocat1)
> 
> @inkedinlove
> 
> \### Organization Name
> 
> CopperSeventhLLC
> 
> \### How did you learn about Zcash Community Grants
> 
> Through research into Zcash ecosystem development needs and current Zcash Community Grants opportunities.
> 
> \### Requested Grant Amount (USD)
> 
> $42,000
> 
> \### Category
> 
> Infrastructure
> 
> \### Project Lead
> 
> \`\`\`project-lead.yaml
> Name: Joshua Kassabian
> Role: Project Lead / Lead Architect
> Background: Founder of CopperSeventhLLC, a software consulting firm. Software developer experienced in designing and delivering production applications, integrations, deterministic workflow systems, and blockchain-funded software projects. Previous blockchain grant-funded work includes successfully delivered projects in the Stellar and Avalanche ecosystems.
> Responsibilities: Technical architecture, implementation leadership, project management, acceptance criteria, integration design, technical documentation, milestone evidence, and delivery oversight.
> 
> Joshua personally implemented and delivered his previous Stellar-funded software projects, including Pakana.net and Stellar Razor and Blazor Suite. He will be responsible for implementation and delivery of this proposal through CopperSeventhLLC.
> \`\`\`
> 
> \### Additional Team Members
> 
> \`\`\`team-members.yaml
> None. Joshua Kassabian will serve as the sole core developer and project lead through CopperSeventhLLC.
> 
> Independent Zcash-domain technical/security review is budgeted separately under Service Costs. The external reviewer has not yet been selected; their qualifications and review scope will be documented before the review work begins.
> \`\`\`
> 
> \### Project Summary
> 
> CopperSeventhLLC proposes an open-source toolkit for exporting and independently verifying evidence about selected Zcash shielded payments without requiring the verifier to receive a reusable viewing key. The project will include a scoped receipt format, reference wallet, standalone verifier, consuming reference application, tests, and documentation.
> 
> \### Project Description
> 
> Zcash provides strong transaction privacy, but that privacy creates a practical problem when a user needs to demonstrate facts about a particular shielded payment to a merchant, support team, accountant, or other application.
> 
> Existing viewing-key approaches can provide ongoing visibility into classes of transactions. Our project explores a narrower disclosure model: the user deliberately selects a supported payment and exports evidence specific to that payment.
> 
> We will build an open-source Selected-Payment Receipts SDK consisting of a defined evidence format, local export workflow, independent verification library and CLI, minimal reference wallet, and consuming reference application. The verifier will distinguish among cryptographic output evidence, invoice/application matching, and chain-confirmation status rather than collapse them into a single “verified” result.
> 
> The initial scope deliberately does not claim to prove payer identity, wallet ownership, completeness of financial history, or arbitrary zero-knowledge predicates. It will not create another payment processor or require CopperSeventhLLC to operate a permanent verification service.
> 
> The goal is to turn existing Zcash cryptographic capabilities into a reproducible developer workflow that applications can integrate while exposing less ongoing wallet information than a reusable viewing capability.
> 
> \### Proposed Problem
> 
> A Zcash user may need to demonstrate that a particular shielded payment contains the details relevant to a transaction without granting the verifier an ongoing ability to observe additional wallet activity.
> 
> This matters in ordinary workflows such as resolving a merchant-payment dispute, matching a payment to an invoice, or sharing selected transaction evidence for business records.
> 
> Existing Zcash primitives support recovery and disclosure of transaction information, and ZIP 311 documents broader payment-disclosure concepts, but a developer still lacks a simple end-to-end toolkit combining user-controlled export, explicit disclosure preview, independent verification, chain-status handling, application binding, and a working reference integration.
> 
> The security boundary is also easy to misunderstand: evidence that a selected output contains particular payment information does not by itself prove that the person presenting that evidence was the original payer. A useful implementation must communicate and enforce that distinction.
> 
> \### Proposed Solution
> 
> We will build an open-source Selected-Payment Receipts SDK that lets a supported wallet locally create a scoped evidence artifact for a selected shielded payment and lets an independent application verify that artifact without receiving a reusable viewing key.
> 
> Before export, the wallet will show the user what information the artifact exposes. The verifier will separately report the validity of the selected-output evidence, application/invoice binding, and independently observed chain status. It will not represent output evidence as proof of payer identity.
> 
> A minimal reference wallet will demonstrate the complete lifecycle on controlled Zcash Testnet infrastructure: receive funds, make a supported shielded payment, select the payment, preview the disclosure, export the artifact, and verify it using separate software.
> 
> A consuming reference application will demonstrate a practical payment-support or invoice-verification workflow. Negative tests will cover modified evidence, incorrect transaction/application binding, unsupported formats, duplicate use, unavailable chain observations, and other defined failure cases.
> 
> Existing maintained Zcash libraries will be reused rather than reimplementing cryptographic primitives.
> 
> \### Solution Format
> 
> Open-source software and technical documentation consisting of:
> 
> \* Selected-payment evidence profile and versioned artifact format.
> \* Wallet-side export library and explicit disclosure-preview workflow.
> \* Minimal Testnet reference wallet demonstrating export end to end.
> \* Independent verification library and command-line verifier.
> \* Reference consuming application demonstrating payment/invoice verification.
> \* Chain-status and application-binding checks kept separate from cryptographic output verification.
> \* Positive, negative, compatibility, and privacy-oriented test fixtures.
> \* Developer documentation, threat model, integration examples, and reproducible build/test instructions.
> 
> The core project will be independently operable and will not require a hosted CopperSeventhLLC service.
> 
> \### Dependencies
> 
> The project will use maintained Zcash protocol and wallet libraries rather than implement shielded cryptography from scratch. Expected technical dependencies include Zcash note-encryption and transaction libraries, Orchard/current supported pool components, Testnet infrastructure, and a supported source of chain data.
> 
> The exact dependency versions and initial supported transaction/pool profile will be frozen during Milestone 1 following technical review.
> 
> The project also depends on an independent Zcash-domain technical reviewer and at least one intended-user or intended-user representative to validate milestone usability and functionality, as required by the grant process. These roles will be identified before the relevant milestone is considered complete.
> 
> Integration into an existing production wallet is desirable but is not a delivery dependency. If no wallet maintainer participates during the grant period, the project-controlled minimal reference wallet will demonstrate the complete export workflow.
> 
> No third party will be represented as a partner or committed integrator without their explicit agreement.
> 
> \### Technical Approach
> 
> The implementation will begin by defining the exact claims made by a selected-payment receipt and the evidence required to support each claim.
> 
> Wallet-side code will use maintained Zcash libraries to obtain the payment-specific material required for the supported disclosure path. Receipt creation will occur locally. Before export, the user will receive an explicit preview of the information recoverable from the artifact, including memo disclosure where applicable.
> 
> The verifier will independently process the artifact and bind recovered payment information to the referenced transaction and expected application/invoice data. Chain observation will be performed separately so that “payment contents verified” and “confirmation policy satisfied” remain distinct conclusions.
> 
> The receipt format will be versioned and network/pool aware. Unsupported configurations will fail explicitly rather than receive a generic successful result.
> 
> The reference wallet and consuming application will run first on controlled Testnet infrastructure. Tests will include valid examples and deliberately modified artifacts, incorrect bindings, duplicate-credit attempts, unavailable/stale chain observations, and unsupported versions.
> 
> The project will not collect spending keys, implement custody, or create new consensus rules. A scoped independent technical/security review will be completed before final release.
> 
> \### Upstream Merge Opportunities
> 
> We intend to reuse existing Zcash libraries rather than maintain unnecessary forks. The initial architecture will identify whether any generally useful changes belong upstream in repositories such as the maintained Zcash Rust libraries or related wallet components.
> 
> Any upstream contribution will follow that repository’s contribution, review, branch, commit, and merge requirements. We will coordinate with maintainers before proposing changes that alter public interfaces or disclosure behavior.
> 
> The receipt profile, verifier, reference wallet, and consuming application can remain independent repositories where appropriate. We will not make grant completion dependent on an upstream maintainer accepting a pull request that is outside our control.
> 
> If implementation reveals a generally useful library capability that can be cleanly separated from project-specific code, we will prepare an upstream contribution and document its status. No upstream merge or maintainer endorsement is claimed in advance.
> 
> \### Hardware/Software Costs (USD)
> 
> $1,000
> 
> \### Hardware/Software Justification
> 
> Project-specific development and testing infrastructure, including CI/build execution, temporary Testnet services, development databases/storage, and other directly attributable tooling required to reproduce supported configurations. No general company equipment, unrelated hosting, or personal hardware is included.
> 
> \### Service Costs (USD)
> 
> $5,000
> 
> \### Service Costs Justification
> 
> Reserved for scoped independent Zcash-domain technical/security review of the receipt design and implementation. The reviewer will evaluate the defined claims, disclosure boundary, use of maintained Zcash primitives, negative cases, and final implementation within an agreed scope.
> 
> The final reviewer and scope will be documented before this allocation is spent. If qualified review can be obtained for less than the allocated amount, unused grant funds will not be repurposed without ZCG approval.
> 
> \### Compensation Costs (USD)
> 
> $36,000
> 
> \### Compensation Costs Justification
> 
> Engineering compensation covers an estimated 400 hours performed by Joshua Kassabian, totaling $36,000:
> 
> \* Architecture and integration: 120 hours at $100/hour = $12,000.
> \* Core implementation: 200 hours at $90/hour = $18,000.
> \* Testing, documentation, and release: 80 hours at $75/hour = $6,000.
> 
> These are workstream allocations for one developer, not separate staffing positions. Independent technical/security review is separately budgeted under Service Costs and is not included in these engineering hours.
> 
> \### Total Budget (USD)
> 
> $42,000
> 
> \### Previous Funding
> 
> No
> 
> \### Previous Funding Details
> 
> \_No response\_
> 
> \### Other Funding Sources
> 
> No
> 
> \### Other Funding Sources Details
> 
> \_No response\_
> 
> \### Implementation Risks
> 
> Primary implementation risks are:
> 
> 1. Disclosure semantics: A selected-output artifact may be incorrectly interpreted as proving payer identity or wallet ownership. The implementation will expose narrowly defined claims and explicitly distinguish payment-output evidence from payer authority.
> 2. Privacy over-disclosure: Payment-specific recovery may expose more information than a user expects, including memo contents. The wallet will preview the complete disclosure boundary before export, and documentation will describe what a recipient can retain or forward.
> 3. Wallet data availability: Some historical payments or wallet configurations may not retain the material necessary to create the supported artifact. Unsupported cases will be reported explicitly.
> 4. Protocol/library evolution: Supported Zcash formats and libraries may change. Dependencies and supported profiles will be version-pinned and documented.
> 5. Chain-state ambiguity: Valid payment contents do not alone establish confirmation status. Chain observation will remain a separate result with source and availability recorded.
> 6. Technical-review findings: Independent review may identify an unsafe assumption. The first milestone is designed as a technical gate so the project can be corrected or formally rescoped before full implementation.
> 7. External integration availability: A production wallet may not integrate during the grant period. A project-controlled reference wallet removes that dependency while intended-user validation remains required.
> 
> \### Potential Side Effects
> 
> A receipt can reduce ongoing disclosure compared with sharing a reusable viewing capability, but it also creates a portable artifact containing information about a selected payment. A recipient may copy or retain disclosed information after receiving it; deletion from our software cannot revoke information already shared.
> 
> A copied receipt could also be presented by someone other than the original payer. The software therefore must not treat possession of a receipt as identity authentication, refund authorization, wallet ownership, or proof of spending authority.
> 
> Poorly designed integrations could double-credit the same payment, expose sensitive memo contents, or display a misleading “verified” result when chain status is unavailable. The reference integration will include duplicate-use controls and separate output, application-binding, and chain-status results.
> 
> The project will not claim that selected receipts prove completeness of accounting records or that undisclosed transactions do not exist.
> 
> \### Success Metrics
> 
> Success will be measured by reproducible technical and usability outcomes rather than transaction volume.
> 
> \* A supported Testnet wallet can create a selected-payment receipt without exporting a reusable viewing or spending key.
> \* The standalone verifier can independently validate supported receipt evidence.
> \* The verifier rejects modified artifacts, incorrect application/invoice bindings, unsupported versions/networks, and other defined negative cases.
> \* Chain-confirmation status is reported separately from cryptographic payment evidence.
> \* The disclosure preview accurately describes all payment information recoverable from the exported artifact.
> \* The reference consuming application prevents the same payment evidence from being credited twice under its demonstrated workflow.
> \* A clean third-party checkout can reproduce the documented workflow using published instructions.
> \* At least one intended-user representative validates the functionality and usability of the delivered workflow.
> \* Independent technical review is completed and material findings are resolved or explicitly documented before v1 release.
> \* Source, tests, fixtures, documentation, and build instructions are publicly released under the approved open-source licenses.
> 
> \### Startup Funding (USD)
> 
> $7,000
> 
> \### Startup Funding Justification
> 
> The $7,000 startup allocation is included within the $42,000 total request and is needed to establish dedicated engineering capacity at project kickoff, freeze the initial supported Zcash configuration, implement the first executable proof, and begin independent Zcash-domain technical review.
> 
> The project intentionally places technical validation early so that the remaining implementation is not built on an unreviewed disclosure assumption. Startup funding will be applied only to grant work and will not reimburse pre-application research or unrelated company expenses.
> 
> \### Milestone Details
> 
> \`\`\`milestones.yaml
> Schedule and acceptance clarification: The dates below assume a December 1, 2026 kickoff and will be adjusted to the agreed start after the grant agreement is completed and startup funding is received. Before work begins, we will agree with ZCG on the technical-review scope, intended-user validation arrangements, and evidence required for each milestone payment. Delivery does not depend on a production wallet adopting the SDK or an upstream maintainer merging our code.
> 
> \- Milestone: 1
> Amount (USD): 7000
> Expected Completion Date: 2026-12-22
> User Stories:
> - "As a Zcash user, I want to understand exactly what information a selected-payment receipt reveals before I export it, so that I can make an informed privacy decision."
> - "As an integrating developer, I want a precisely defined and technically reviewed receipt format, so that I know what evidence I may safely rely on."
> Deliverables:
> - Versioned selected-payment receipt/evidence profile defining supported claims, disclosure boundaries, network/pool/version handling, and explicit non-claims.
> - Threat model covering copied receipts, over-disclosure, incorrect application binding, stale or unavailable chain observations, and misuse of payment evidence as payer authentication.
> - Frozen initial dependency and compatibility matrix using maintained Zcash libraries.
> - Executable Testnet proof demonstrating creation and independent verification of a supported selected-payment artifact using maintained Zcash components.
> - Initial negative tests demonstrating rejection of modified evidence and unsupported or incorrectly bound inputs.
> - Initial Zcash-domain technical review of the evidence model and implementation approach.
> Acceptance Criteria: "The intended-user representative and technical reviewer can reproduce the supported Testnet proof from documented instructions; the verifier successfully validates the supported unmodified artifact and rejects the defined modified/unsupported cases; the documentation explicitly identifies all information disclosed by the artifact and states that selected-output evidence alone does not establish payer identity, wallet ownership, or spending authority. Material technical-review findings are either resolved or documented with an agreed correction before Milestone 2."
> 
> \- Milestone: 2
> Amount (USD): 12000
> Expected Completion Date: 2027-01-19
> User Stories:
> - "As a Zcash user, I want to select a supported shielded payment, preview its disclosure, and export evidence locally without sharing a reusable viewing or spending key."
> - "As a merchant or application developer, I want to independently verify a supported receipt and match it to an expected payment or invoice without depending on a CopperSeventhLLC hosted service."
> Deliverables:
> - Minimal Testnet reference wallet implementing the supported receive, send, payment-selection, disclosure-preview, and receipt-export workflow.
> - Wallet-side receipt/export library using maintained Zcash cryptographic components rather than reimplementing shielded cryptography.
> - Standalone verification library and command-line verifier.
> - Reference consuming application demonstrating payment/invoice binding.
> - Separate verifier results for cryptographic payment evidence, application/invoice binding, and chain-observation/confirmation status.
> - Versioned receipt format and developer integration documentation.
> Acceptance Criteria: "From a clean documented setup, a user can receive Testnet funds, make a supported shielded payment, select that payment, preview the complete defined disclosure, export a receipt, and have separate verifier software validate the supported evidence without receiving a reusable viewing key or spending key. The consuming application can bind valid evidence to the expected payment/invoice, while incorrect bindings and unsupported receipt versions fail explicitly. Verification does not require a CopperSeventhLLC hosted service."
> 
> \- Milestone: 3
> Amount (USD): 10000
> Expected Completion Date: 2027-02-02
> User Stories:
> - "As an integrating developer, I want predictable failure behavior and reproducible test fixtures, so that I do not accidentally treat incomplete or manipulated evidence as a verified payment."
> - "As an intended user, I want the workflow independently reproducible, so that I can evaluate whether it is understandable and useful outside the development team's environment."
> Deliverables:
> - Expanded positive, negative, compatibility, and privacy-oriented test suite.
> - Tests for modified artifacts, incorrect transaction/application bindings, unsupported network/version combinations, duplicate-credit attempts, unavailable or stale chain observations, and other applicable failure cases identified during review.
> - Explicit handling of chain-status unavailability without converting an unknown result into a false payment conclusion.
> - Duplicate-use protection in the demonstrated consuming-application workflow.
> - Reproducible fixtures and clean-environment setup instructions.
> - Intended-user validation session and documented findings.
> - Updated threat model, compatibility matrix, and disclosure documentation based on implementation evidence and user feedback.
> Acceptance Criteria: "All published tests produce their documented results; intentionally modified or incompatible artifacts are rejected or reported with the correct bounded status; unavailable chain evidence is reported as unavailable rather than as proof of payment or nonpayment; the reference consuming application prevents the same receipt from being credited twice within its demonstrated workflow; and at least one intended-user representative independently reproduces the core workflow and confirms whether the delivered functionality meets the stated user stories. Any material validation findings are documented and addressed or explicitly carried into Milestone 4."
> 
> \- Milestone: 4
> Amount (USD): 6000
> Expected Completion Date: 2027-02-23
> User Stories:
> - "As a Zcash developer, I want a documented open-source implementation that I can run, inspect, integrate, and maintain without relying on the original grant recipient."
> - "As a Zcash ecosystem participant, I want the final project's security and privacy claims to match what the implementation actually proves."
> Deliverables:
> - Scoped independent technical/security review of the final supported implementation.
> - Remediation of material in-scope review findings or explicit documentation of any accepted limitations.
> - Public version 1.0 release of the receipt profile, export components, standalone verifier, reference wallet, reference consuming application, tests, fixtures, and developer documentation.
> - Reproducible build and test instructions plus a CONTRIBUTING.md consistent with applicable Zcash development standards.
> - Final compatibility/support matrix and documented privacy/security boundaries.
> - Final project report describing delivered functionality, validation results, known limitations, and recommended future work.
> Acceptance Criteria: "An independent technical reviewer completes the agreed review scope; material findings are resolved or transparently documented before release; a clean third-party environment can build and run the documented v1 workflow and test suite; the public release does not require CopperSeventhLLC infrastructure to create or verify supported receipts; and the intended-user representative confirms that the final deliverables satisfy the agreed milestone user stories and usability requirements."
> \`\`\`
> 
> \### Supporting Documents
> 
> \`\`\`files.yaml
> 
> \`\`\`

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 for taking the time to read through it.

**Joshua Kassabian**  
CopperSeventhLLC

---

<div class="post-metadata">

**Author:** ![inkedinlove](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/inkedinlove/32/48534_2.png) [@inkedinlove](https://forum.zcashcommunity.com/u/inkedinlove)\
**Post date:** [September 22, 2026, 3:01pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729/2 "2026-09-22T15:01:45Z")

</div>

Thanks **[@hhanh00](https://github.com/hhanh00)**. for requesting clarity around the technical approach sections implementation details. I wanted to share that response and attached it below 👇

1. 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.

Conceptually, the artifact is:

{  
“type”: “zcash-selected-output”,  
“version”: 1,  
“network”: “testnet”,  
“pool”: “orchard”,  
“txid”: “”,  
“action\_index”: 0,  
“ock”: “\<32-byte output-specific key, hex encoded\>”  
}

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

---

<div class="post-metadata">

**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\
**Post date:** [September 30, 2026, 1:25pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729/3 "2026-09-30T13:25:25Z")

</div>

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.](https://forum.zcashcommunity.com/t/zcash-community-grants-zcg-meeting-minutes-9-28-2026/57928)

---

<div class="post-metadata">

**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\
**Post date:** [September 30, 2026, 1:35pm UTC](https://forum.zcashcommunity.com/t/grant-application-zcash-selected-payment-receipts-sdk/57729/4 "2026-09-30T13:35:09Z")

</div>

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](https://zips.z.cash/zip-0311)  
and would encourage you to bring it to Ironwood with support from the protocol engineers.