RFF - Zonp Wallet-native Commerce update

Zcash Apps
1

If someone wanted to sell something using Zcash today, where would they do it?

What marketplace exists? What standard exists to send an invoice, receive payment, and keep a clear record of what was purchased?

You can send a payment, sure. But beyond that:

  • No standard way to attach structured meaning to a transaction

  • No native concept of invoices or receipts

  • No clean way to link a payment to an order

  • No built-in record beyond “a transaction happened”

For simple transfers, that’s fine. For actual commerce, it gets complicated quickly.

Zonp is an attempt to create a marketplace layer for human commerce using Zcash.

What I built

I’ve been working on a system called Zonp to solve this directly at the transaction layer.

The idea is to treat each Zcash transaction as a complete economic event, not just a value transfer, by embedding structured data into memo fields:

  • Payments

  • Invoices

  • Receipts

  • Item-level purchase details

This allows the wallet itself to function as:

  • A payment system

  • A receipt and record system

  • A lightweight commerce interface

Conceptually, it brings together:

  • Marketplace-style interactions (similar to eBay)

  • Integrated payments and receipts (similar to PayPal)

…but implemented directly within Zcash transactions, rather than through centralized platforms.

What’s working right now

This is not a roadmap—it’s a working prototype.

Zonp enables direct, in-person transactions and one-click creation of IPFS-hosted storefronts, supporting use cases such as product sales, services, and donations.

Current capabilities include:

  • Wallet flows for:

    • Payments

    • Invoice requests (automatically closed upon payment)

    • Receipt generation and tracking

  • Structured memo encoding/decoding (compact, not raw JSON)

  • Multi-memo chunking and reassembly for larger payloads

  • QR-based interaction layer (payments, invoices, contacts)

  • IPFS-based storefront generation

  • Backend coordination layer via zonp.app

  • Early-stage reputation system designed to link interactions and reviews to real transactions

In practice, this works end-to-end and demonstrates that Zcash can support stateful, multi-step commerce interactions using shielded transactions and memo fields.

The tradeoff (being upfront)

Right now, the system has prioritized developing a working prototype—functionality first, with security now the priority.

That means:

  • Authentication and authorization are not yet fully hardened

  • Some actions (such as storefront updates or reputation events) require stronger verification

  • API-level protections need to be tightened

This wasn’t accidental—it was necessary to validate the model in practice.

Next phase: security hardening

The focus now is transitioning from a working prototype into something safe and reliable for real-world use.

A key part of this phase is moving from a “parse → trust” model to a “verify → trust” model.

This includes introducing cryptographic signatures on memo payloads, so that every order and message is both encrypted and tied to a verifiable wallet identity before any actions are executed.

This authentication layer is also foundational for the reputation system—interactions can only contribute to reputation if they are cryptographically tied to real participants, preventing spoofed orders, fake messages, or manipulated feedback.

Key areas I’m working on:

  • Transaction-linked authorization (signing actions)

  • Authenticated API interactions (preventing spoofed requests)

  • Securing storefront publishing and reputation updates

This phase is about making the system robust enough for real users, not just proving that it works.

Where this is going

I’m planning to submit a proposal to the Zcash Community Grants to:

  • Harden the system for production use

  • Formalize a memo-based protocol for interoperability

  • Improve wallet stability and UX

  • Expand merchant and storefront functionality

  • Implement a fully verified reputation system built on authenticated, transaction-linked interactions

Why I think this matters

If this approach holds up, it means:

Zcash doesn’t just support private payments—it can support private commerce workflows directly at the transaction layer.

That’s a different category of capability than what exists today.

Looking for input

Appreciate any thoughts—especially from those working on wallets, memo handling, or user-facing Zcash tools.