Zonp Wallet-native Commerce App

Zcash Apps
1

I’m currently building an application-layer system on top of Zcash and wanted to share the design direction to get feedback from people more familiar with protocol and wallet-level constraints.

The core idea I’m exploring is:

Can Zcash support stateful, multi-step interactions purely through shielded transactions + memo fields?

Instead of treating transactions as isolated events, I’m experimenting with using memos as a structured data transport layer to coordinate interactions like:

  • payments

  • invoices

  • receipts

  • messaging

  • basic commerce workflows

System components (current architecture)

At a high level:

  • Zcash → private settlement layer

  • Memo field → structured data transport

  • IPFS (Kubo) → storefront/catalog hosting

  • Off-chain service → discovery + reputation

This is not a protocol change or fork—everything operates within existing Zcash functionality.

What is currently implemented (prototype level)

  • Structured memo payloads (compact encoding rather than raw JSON)

  • Multi-memo chunking for larger payloads

  • Wallet-side parsing of transaction intent (payment vs message vs receipt)

  • QR-based exchange of payment/invoice requests

I’m also experimenting with application-layer payload encoding and optional symmetric encryption (e.g., AES-256) applied inside memo fields.

To be clear, this does not replace Zcash’s protocol-level memo encryption. The intent is more along the lines of:

  • standardizing payload structure

  • isolating application-layer data formats from protocol changes

  • and exploring a defense-in-depth model for payload confidentiality

Forward-looking note (quantum considerations)

I’ve also been thinking about how systems like this should behave under a future quantum threat model.

My understanding is:

  • Zcash’s current security relies on elliptic curve cryptography, which would be vulnerable to Shor’s algorithm

  • Symmetric primitives such as Advanced Encryption Standard (AES-256) are comparatively more resilient, with quantum attacks like Grover’s algorithm reducing effective security but not making them trivial to break

The additional AES layer is not intended to make the system “post-quantum secure,” but rather:

  • to preserve confidentiality of memo payloads under weakened protocol assumptions

  • to separate application-layer data from underlying cryptographic primitives

  • and to explore forward-compatible patterns if Zcash evolves toward post-quantum designs

Areas I’m unsure about / looking for feedback:

  1. Memo usage as a transport layer

  • Are there known issues with systematic (not occasional) memo usage?

  • Any assumptions in wallets or nodes that this might violate?

2. Multi-memo transactions

  • Practical limits on number of outputs/memos per transaction

  • Known reliability or relay edge cases

  • Best practices for chunking and reassembly

3. Light client implications

  • Does increased memo usage impact scan performance significantly?

  • Any known bottlenecks at the light client layer?

4. Privacy considerations

  • Risks of structured or semi-standardized memo formats

  • Potential metadata leakage patterns even with encrypted memos

5. Application-layer encryption

  • Is additional symmetric encryption (e.g., AES) inside memos considered redundant in practice? Or does it provide meaningful defense-in-depth for certain use cases?

For example, under a future quantum threat model, if protocol-level cryptography (e.g., elliptic curve assumptions) were weakened, it’s unclear what portions of transaction data would remain protected.

My intuition is that even in such a scenario, an independently encrypted memo payload (e.g., via AES-256) could still preserve the confidentiality of application-layer data, even if other aspects of the transaction were compromised or observable.

I’m interested in whether this layered approach is considered useful in practice, or if it’s viewed as unnecessary given the current design of memo encryption.

Forward-looking dependencies

Some parts of this design assume future capabilities:

  • ZSAs (for stable-value transactions)

  • Potential Zcash-native stable assets

I’m interested in how application-layer systems like this should think about forward compatibility with those features.

Intent

This is an attempt to understand:

  • where the boundaries of the current design are

  • what breaks under real usage patterns

  • and whether this is a viable direction at all

If this approach conflicts with how Zcash is intended to be used, I’d rather understand that early.

1 Like
2

Memo fields can carry structured state, but the harder problem is who holds the canonical view across steps. If both parties only see their own shielded outputs, you need an off chain coordinator or a memo schema both wallets parse the same way. Memo standardization matters here.

3

Thanks for the reply. Yes I agree. I plan to write a “Zonp Memo Spec” document other wallets could share, but I’m not finished developing. What I have works, but the next phase would “compress” memo fields even further. But I should probably create a v1 and v2, because v2 would operate much differently.