### 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)
@ReubSand
### Organization Name
Michael Moore (FlatlandFoundry.com)
### How did you learn about Zcash Community Grants
I’ve followed Zcash since its early development, starting with the Zerocoin and Zerocash protocols and the network’s launch in 2016. My engagement has primarily been independent, including maintaining a small X (Twitter) account focused on privacy, economics, and related topics, and following ongoing discussions in the ecosystem. I became aware of the Zcash Community Grants program through the community forum and broader development discussions.
### Requested Grant Amount (USD)
$90,000
### Category
Infrastructure
### Project Lead
```project-lead.yaml
Name: Michael Moore
Role: Lead Developer / Project Lead
Background: Background in operations, process improvement, and manufacturing systems. Over 17 years of experience optimizing workflows, developing internal tools, and improving efficiency in production environments. Experienced in full-stack development, including JavaScript/Node.js, React Native, and Python, with a focus on building practical systems that solve real-world problems.
Developer of Zonp, a wallet-native commerce system built on Zcash, including memo-based transaction protocols, QR interaction flows, IPFS storefront integration, and backend services for coordination and reputation.
Responsibilities: System architecture and protocol design
Wallet and mobile application development
Backend API and infrastructure development
Security implementation (authentication, signing, verification)
Merchant onboarding and real-world testing
Documentation and protocol specification
```
### Additional Team Members
```team-members.yaml
N/A
```
### Project Summary
Zonp is a wallet-native commerce layer for Zcash that transforms shielded transactions into complete economic events by embedding structured data—payments, invoices, and receipts—directly into memo fields. The project focuses on securing and productionizing this system through transaction-linked authentication, verified reputation, and merchant-ready workflows.
Zonp expands Zcash usage by enabling real-world private commerce between buyers and merchants, turning shielded transactions from simple value transfers into active economic coordination.
### Project Description
Zonp is a wallet-native commerce layer for Zcash that transforms shielded transactions from simple value transfers into complete, private economic interactions.
By treating the Zcash memo field as a structured data channel, Zonp enables transactions to carry orders, invoices, receipts, and encrypted messages between participants—without exposing any metadata on-chain. This allows buyers and sellers to coordinate multi-step workflows (such as purchase, fulfillment, and feedback) entirely through private transactions.
A working prototype has been developed and validated on Zcash mainnet, demonstrating structured memo encoding, multi-memo payload handling, encrypted messaging, IPFS-hosted storefronts, and a transaction-linked reputation system. This confirms that private commerce is feasible today using existing Zcash infrastructure.
The focus of this project is to transition Zonp from a functional prototype into secure, production-ready infrastructure. The primary upgrade introduces cryptographic authentication of all interactions, shifting the system from a “parse → trust” model to a “verify → trust” model by embedding signatures into memo payloads and enforcing identity validation.
In parallel, the project will formalize a reusable memo-based transaction specification that can be adopted by other wallets and services, enabling interoperability across the Zcash ecosystem.
Zonp expands Zcash from private payments into private economic coordination, providing a foundation for marketplaces, merchant tools, and new classes of privacy-preserving applications.
### Proposed Problem
Zcash provides strong privacy for payments, but it lacks a standardized way to represent and coordinate higher-level economic interactions at the transaction layer. Today, transactions primarily convey value transfer, while memo fields are used inconsistently and without a shared structure across wallets and services.
As a result, Zcash transactions cannot natively represent commerce—such as orders, invoices, receipts, or item-level purchase details—which limits adoption to simple transfers rather than real-world economic activity.
This creates several key limitations:
No standardized method for encoding invoices, receipts, or purchase details within transactions
Payments cannot be reliably linked to specific orders or interactions without relying on external systems
Wallets and services lack a common framework for interpreting structured transaction data
Reputation and trust systems cannot be securely derived from on-chain activity due to the absence of authenticated, transaction-linked interactions
Because of these constraints, real-world commerce on Zcash depends on fragmented, application-specific solutions that operate outside the transaction layer. This reduces interoperability, increases complexity, and prevents the emergence of a unified, transaction-native commerce ecosystem.
Without a standardized and secure method for encoding and authenticating structured transaction data, Zcash remains primarily a payment network rather than a platform for broader economic coordination.
### Proposed Solution
Zonp addresses these limitations by introducing an application-layer framework that standardizes how structured data is encoded, authenticated, and interpreted within Zcash transactions. It defines a consistent model for using memo fields as a transport layer for structured payloads, enabling transactions to represent complete economic interactions rather than simple value transfers.
At its core, Zonp provides a structured memo specification for encoding payments, invoices, receipts, and item-level purchase details in a compact, machine-readable format. This allows wallets and services to interpret transaction intent consistently without requiring changes to the underlying Zcash protocol.
To ensure correctness and security, Zonp implements transaction-linked authentication through cryptographic signatures embedded within memo payloads. This establishes a “verify → trust” model, where all interactions are cryptographically bound to their originating wallet and resistant to spoofing or unauthorized actions.
Building on this foundation, Zonp enables verifiable reputation derived from authenticated, transaction-backed interactions, allowing trust to emerge directly from real economic activity.
A working wallet-based implementation demonstrates this model in practice, including structured memo handling, encrypted messaging, and IPFS-based storefronts. The primary deliverable is a reusable, interoperable transaction framework that can be adopted by other wallets and services.
Recent improvements in Zcash shielded transaction usability make higher-level application-layer protocols feasible, but without structured transaction semantics, real-world merchant adoption remains blocked. Zonp directly addresses this gap.
### Solution Format
The primary deliverable of this project is open-source software and technical documentation that define and implement a structured, authenticated transaction model for Zcash.
Key deliverables include:
A reference wallet implementation demonstrating structured memo encoding, signing, and parsing
A formal memo specification for encoding payments, invoices, receipts, and related transaction types
An authentication model based on transaction-linked cryptographic signatures
A transaction-backed reputation system derived from authenticated interactions
Supporting infrastructure, including backend coordination services and IPFS-based storefront integration
All components will be released as open-source, with comprehensive documentation to support adoption by other wallets, developers, and services.
The project will also include demonstration materials illustrating end-to-end transaction workflows and real-world commerce scenarios enabled by the system.
### Dependencies
Zonp operates as an application-layer system built on existing Zcash functionality and does not require any protocol modifications.
Core dependencies include:
The Zcash network and shielded transactions, which provide the underlying transport and privacy guarantees
Zcash wallet and key infrastructure for transaction creation, memo encryption, and key management
Standard cryptographic libraries for implementing transaction-linked authentication
Supporting components include:
IPFS (Kubo) for optional decentralized storefront hosting
Backend services for coordination tasks such as reputation tracking and storefront indexing
Mobile and web frameworks used for the reference wallet and user interface
Zonp is designed to function independently of external partnerships or protocol changes, enabling it to be developed, tested, and deployed as a standalone system.
### Technical Approach
Structured memo model
Zonp defines a compact binary memo format that encodes transaction intent—payments, invoices, receipts, and item-level data—allowing consistent, machine-readable interpretation across wallets and services.
Transaction-linked authentication
A “verify → trust” model is established by embedding cryptographic signatures within memo payloads, ensuring all interactions are bound to wallet identity and resistant to spoofing.
Reference wallet implementation
A working wallet encodes, signs, broadcasts, receives, and verifies structured memo payloads, serving as both a validation environment and a reference for ecosystem adoption.
Reputation from authenticated interactions
Reputation is derived from verified, transaction-backed activity, requiring both proof of transaction and cryptographic identity.
Supporting infrastructure and interoperability
Backend services, IPFS-based storefronts, and QR-based flows validate real-world usability, while the memo format and authentication model are formalized into a reusable specification for broader adoption.
### Upstream Merge Opportunities
Zonp is an application-layer system built on existing Zcash functionality and does not require modifications to upstream Zcash repositories for its core implementation.
Upstream repositories to modify: None
Planned upstream changes: None for initial delivery
The structured memo transaction model, authentication framework, and interoperability patterns developed in this project may inform future discussions around wallet standards, memo interpretation, and developer tooling.
Any upstream collaboration would be considered after the transaction model, authentication layer, and reference implementation have been validated.
### Hardware/Software Costs (USD)
$4,500
### Hardware/Software Justification
The requested hardware and software costs support development, testing, and real-world validation of Zonp.
Mobile devices are required to test QR-based interactions, multi-device transaction flows, and buyer–seller workflows across separate physical devices.
Development hardware and peripherals support ongoing mobile and backend development, as well as local testing environments.
Cloud infrastructure and hosting are used to operate backend coordination services, including APIs, databases, and IPFS pinning for storefront content. These are necessary to validate transaction flows, reputation tracking, and merchant-facing functionality under realistic conditions.
Software tools and services support build, testing, and deployment workflows.
These costs are minimal and focused on enabling practical development and validation rather than serving as a primary component of the grant budget.
### Service Costs (USD)
$10,000
### Service Costs Justification
Service costs support the backend infrastructure required to develop, test, and validate Zonp in real-world conditions.
This includes cloud hosting, database infrastructure, and API services used for coordination features such as transaction-linked reputation, storefront indexing, and interaction tracking.
IPFS pinning and content hosting services are required to support decentralized storefronts and ensure persistent availability of merchant content.
Additional costs include development and testing environments, as well as logging and monitoring tools needed to validate system performance under realistic usage conditions.
These services enable end-to-end testing of transaction workflows, authentication, and reputation systems as a functioning, production-like environment.
### Compensation Costs (USD)
$75,500
### Compensation Costs Justification
The requested compensation supports full-time development of Zonp over the project duration, covering design, implementation, testing, and deployment.
As the sole developer, responsibilities include system architecture, wallet development, backend infrastructure, security implementation (including transaction-linked authentication), reputation system design, and preparation of technical documentation and specifications.
The project is expected to require approximately 5–6 months of full-time work, with funding tied to milestone completion. This includes both core development and real-world validation, such as merchant onboarding, transaction testing, and iterative refinement.
The requested amount reflects a reasonable full-time rate for an independent developer working across mobile, backend, and applied cryptographic systems.
### Total Budget (USD)
$90,000
### Previous Funding
No
### Previous Funding Details
N/A
### Other Funding Sources
No
### Other Funding Sources Details
N/A
### Implementation Risks
1) Authentication and security complexity
Implementing transaction-linked authentication requires precise signature validation. Errors could lead to incorrect trust assumptions. This is mitigated by prioritizing security, enforcing strict verification rules, and validating behavior through controlled testing.
2) Memo size and transaction constraints
Zcash memo size limits may require multi-memo handling and efficient encoding. The current prototype already supports multi-memo payloads, and further refinement will ensure reliability across transaction flows.
3) Interoperability and standardization
As an application-layer model, adoption by other wallets is not guaranteed. This is addressed through clear specification and a working reference implementation to encourage integration.
4) Usability and merchant onboarding
Adoption depends on ease of use. Complex workflows could limit usage. This risk is mitigated through simplified wallet flows, QR-based interactions, and real-world merchant testing.
5) Backend dependencies
Some features rely on backend services (e.g., reputation and storefront indexing), introducing operational complexity. This is mitigated by keeping these components minimal and replaceable.
6) Scope and solo development constraints
As a single-developer project, scope management is critical. This is addressed through milestone-based development and prioritization of core infrastructure and security.
### Potential Side Effects
1) Inconsistent interpretation across wallets
Different wallets may implement the memo format differently, leading to partial compatibility. This is mitigated through clear specification and a reference implementation.
2) Increased transaction complexity
Structured data, authentication, and multi-step workflows increase processing complexity. This is addressed through strict validation rules, well-defined formats, and iterative testing.
3) Reliance on supporting infrastructure
Some features depend on backend services (e.g., reputation and storefront indexing), introducing operational dependencies and potential metadata exposure through access patterns or request logs. This is mitigated by minimizing data collection and keeping services modular and non-essential.
4) Metadata and usage pattern leakage
While transaction contents remain encrypted, repeated structured interactions may still create indirect behavioral patterns. This is mitigated by minimizing metadata and avoiding deterministic or identifying patterns.
5) Reputation system misuse
As with any rating system, attempts at manipulation are possible. Zonp mitigates this through transaction-linked verification and cryptographic identity, with ongoing refinement as needed.
### Success Metrics
1) Security and authentication
100% enforcement of signature verification for authenticated interactions (orders, messages, reputation events)
Rejection of invalid or unsigned interactions in controlled testing
Demonstrated transition from “parse → trust” to “verify → trust”
2) Functional transaction workflows
Successful end-to-end flows (invoice → payment → receipt)
Reliable encoding, transmission, and parsing of structured memo payloads
Demonstration of multi-step, memo-based transaction coordination
3) Verified reputation system
Reputation events tied to valid transaction identifiers (tx_id)
Rejection of invalid or unauthenticated submissions
Reputation updates based on verified economic activity
4) Real-world usage
Onboarding of 3–5 independent merchants
Completion of at least 10 real transactions
Demonstrated end-to-end usage (QR → payment → receipt)
5) Developer and ecosystem readiness
Publication of memo-based transaction specification
Open-source reference implementation and documentation
Successful reproduction of basic workflows by external developers or testers
### Startup Funding (USD)
$20,000
### Startup Funding Justification
Startup funding enables full-time development to deliver the first milestone focused on security and authentication.
While a working prototype of Zonp already exists, this phase transitions the system from a functional demonstration to a secure, production-ready foundation. The primary focus is implementing transaction-linked authentication, including memo-level signing, signature verification, and enforcement of “verify → trust” behavior across all critical interactions.
This funding also supports initial operation of backend infrastructure and testing environments required to validate authentication under real-world conditions.
Providing upfront funding ensures uninterrupted development and rapid delivery of a critical milestone, reducing execution risk by validating the system’s security foundation before progressing to later phases.
### Milestone Details
```milestones.yaml
Milestone 1 — Transaction-Linked Authentication
Timeline: Month 1–2
Funding: $20,000
Description:
Implement transaction-linked authentication by adding cryptographic signatures to structured memo payloads, establishing a “verify → trust” model in which all interactions are validated before processing.
Deliverables:
Memo-level signing implementation
Signature verification pipeline
Enforcement of authenticated interactions (orders, messages, reputation events)
Integration into the wallet-based reference implementation
Acceptance Criteria:
Valid signed interactions are processed successfully
Invalid or unsigned interactions are rejected
Demonstration of authentication behavior in controlled test scenarios
Milestone 2 — Secure Backend and Storefront Protection
Timeline: Month 2–3
Funding: $15,000
Description:
Secure backend coordination services and storefront operations to prevent unauthorized actions and ensure integrity.
Deliverables:
Authenticated API endpoints
Secure storefront publish/update/delete mechanisms
Replay protection and request validation
Acceptance Criteria:
Unauthorized requests are rejected
Authenticated requests are processed correctly
Demonstration of secure storefront operations
Milestone 3 — Verified Reputation System
Timeline: Month 3–4
Funding: $20,000
Description:
Implement a reputation system tied to authenticated, transaction-backed interactions.
Deliverables:
Transaction-linked reputation model (tx_id + signature)
Rating and feedback submission system
Reputation scoring pipeline
Acceptance Criteria:
Invalid or unauthenticated ratings are rejected
Valid ratings update reputation correctly
Demonstration of transaction → rating → reputation flow
Milestone 4 — Merchant Usability and Real-World Validation
Timeline: Month 4–5
Funding: $20,000
Description:
Improve usability and validate the system through real-world merchant interactions.
Deliverables:
Simplified merchant onboarding flow
QR-based payment and interaction flows
End-to-end transaction workflows (invoice → payment → receipt)
Acceptance Criteria:
3–5 merchants onboarded
At least 10 real transactions completed
Demonstration of full transaction lifecycle
Milestone 5 — Specification and Documentation
Timeline: Month 5–6
Funding: $15,000
Description:
Formalize the transaction model and publish documentation for ecosystem adoption.
Deliverables:
Memo-based transaction specification
Authentication and interaction model documentation
Developer documentation and example implementations
Acceptance Criteria:
Public documentation repository
Clear specification of memo structure and authentication model
Reproducible example workflows for developers
```
### Supporting Documents
```files.yaml
Supporting documents outlining Zonp’s system design, protocol architecture, and development roadmap:
Zonp Simplified Flowchart (Non-Technical Overview)
https://raw.githubusercontent.com/ReubSand/zonp-docs/efeb209cc9baf526830fdef3422dfd35a597602a/zonp_simplified_flowchart.pdf
Zonp Roadmap
https://raw.githubusercontent.com/ReubSand/zonp-docs/efeb209cc9baf526830fdef3422dfd35a597602a/zonp_roadmap.pdf
Zonp Architecture (Cryptographic Design)
https://raw.githubusercontent.com/ReubSand/zonp-docs/bbf5424b5480aee02ee23707ccd9f69f9cd4d46f/zonp_cryptographic_architecture.pdf
Zonp Transaction Flow (End-to-End System)
https://raw.githubusercontent.com/ReubSand/zonp-docs/bbf5424b5480aee02ee23707ccd9f69f9cd4d46f/zonp_transaction_flow.pdf
```