Curious what people are building on Zcash right now.
What are you working on? What problem are you trying to solve, and why Zcash specifically? Apps, tools, integrations, research, doesn’t matter how big or small.
Also, what do you think is missing from the ecosystem? What should someone be building that nobody else is?
Would especially love to hear from new folks of the community who might not have shared their work on the forums before!
Zcash has shielded memos but no standard way to put structured application data in them. No typed events, no deterministic hashing, no Merkle commitment, no on-chain anchoring. ZIP 302 defines the container but says nothing about payloads.
ZAP1 fills that gap. It is an open attestation protocol that writes typed lifecycle events into a BLAKE2b Merkle tree and anchors roots on Zcash mainnet via shielded memos. Anyone with a leaf hash can verify the full proof path to the anchor transaction. 4 roots anchored on
mainnet so far, 15 event types implemented. MIT licensed.
Source and docs: GitHub - Frontier-Compute/zap1: ZAP1 structured memo protocol for Zcash. BLAKE2b Merkle commitments, Orchard shielded anchoring, verification SDK. · GitHub. Verify the whole thing in one command: git clone && bash scripts/check.sh - 14 checks against the live API, crates.io, proof bundles, and tests.
For Rust or JS developers: the verification SDK is on crates.io (zap1-verify, 83KB WASM, 1 dep) and npm (@frontiercompute/zap1). There is also a memo decoder on crates.io (zcash-memo-decode) that classifies ZAP1, ZIP 302 TVLV, plain text, binary, and empty memos with 0 dependencies.
Operators can deploy their own instance - the setup generates keys, .env, and docker-compose in one command. Conformance kit included. Live demo and API docs at frontiercompute.io.
A Solidity verifier is also published (GitHub - Frontier-Compute/zap1-verify-sol: Solidity verifier for ZAP1 Merkle proofs. Verify Zcash shielded attestations on any EVM chain. · GitHub) - verify ZAP1 Merkle proofs on any EVM chain using the EIP-152 BLAKE2b precompile. Zcash attestations verifiable on Ethereum without a bridge or custodian.
ZIP draft PR open at ZIP: Structured Memo Protocol for Application-Layer Attestation (ZAP1) by Zk-nd3r · Pull Request #1243 · zcash/zips · GitHub.
I am not building on Zcash yet but I’ve been seriously thinking about it lately, and honestly what pulls me in is not just privacy as a feature, but privacy as a default design principle.
One idea I’ve been exploring is a lightweight “proof of action” system where users can prove they completed something (could be work, contributions, or even learning milestones) without revealing the actual underlying data. Sort of like a reputation layer but without turning into a surveillance system. Most platforms today force you to trade visibility for credibility and that feels fundamentally broken.
Zcash seems like one of the few exosystems where something like that could actually make sense, especially if you lean into zero-knowledge proofs properly instead of just treating them like a buzzword.
What I feel is missing right now is not capability but approachibility. There’s insane tech here, but very few entry points for builders who are not already deep into crypto. Feels like we need more “middle layer” tooling. Things that abstract complexity just enough so devs can experiment without spending weeks understanding the math first.
If I do end up building this, I’d want it to be something people can plug into easily. Not another isolated experiment but something composable that others can build on. Curious if anyone else has thought along similar lines or is already working on reputation systems or zk-based attestationsz on zec.
This is really cool. I’ve actually been exploring using memos for structured messaging and application-layer data, so the timing is perfect. Will definitely be digging into this.
I’ve been reading through ZIP-231 as well. The move from a fixed 512-byte per-output memo to bundled, multi-recipient memo data would be a significant quality-of-life improvement for anyone building on top of the memo field. Disappointing that it didn’t get through, hopefully it gets another shot in a future governance round.
The proof-of-action idea is cool, reputation without it becoming a tracking system is a hard problem and most just don’t bother solving it.
The memo field could actually be useful for something like that, attest to something on-chain without exposing it to anyone except the verifier. Worth exploring for sure!
Agree on the tooling gap, that’s something I’ve been thinking about too. What kind of attestations are you thinking about, work contributions, on-chain activity?
Appreciate it. ZAP1 formalizes that pattern, typed payloads with BLAKE2b Merkle commitments anchored via Orchard memos. ZIP 1243 is the draft for partType registration.
Memo decoder on the API (/memo/decode endpoint) handles ZAP1, ZIP 302, and plain text. Or npx @frontiercompute/zcash-mcp for the full MCP toolset.
Agreed on 231. 512 bytes is workable but bundled memos would make multi-output attestation cleaner.
Yeah exactly, most systems just default to “track everything and call it reputation” because it’s easier, not because it’s better.
For attestations, I’m thinking a mix, but leaning more toward off-chain action with on-chain proofs. Things like work contributions, completed tasks, learning milestones, even participation in communities. The key idea is that the signal exists, but the raw data doesn’t need to be exposed publicly.
On-chain activity is interesting too, but if we only focus there, it kind of defeats the purpose since that’s already somewhere observable. I am more interested in proving things that normally can’t be proven without revealing too much.
Long term, I think the real unlock is making attestations reusable. ike you prove something once and then selectively disclose it in different contexts without redoing the whole process.
Still early thoughts, but I feel like if this clicks, it could open up a completely different category of apps on Zcash.
ZAP1 caught my attention. Structured memos with cross-chain verification solve a real bottleneck for building anything useful on top of shielded transactions.
The Solidity verifier for EVM chains is a smart call. Tooling like that is where adoption actually gets built.
What you’re describing is close to what ZAP1 does today. Attest an off-chain action to the Merkle tree, anchor the root to Zcash, share the proof with whoever needs it. The raw data never goes on-chain. The verifier checks the proof path against the anchor.
Reusable proofs are already there, the proof bundle is portable JSON (leaf hash, Merkle path, root, txid). Verify it against any chain where the root is registered. Solidity verifier is live on Sepolia for the cross-chain case.
That’s actually really interesting, I didn’t realise ZAP1 had already gone that far with it. The merkle anchoring + portable proof bundle makes a lot of sense, especially for keeping raw data off-chain while still having something verifiable. That already solves a big part of the problem.
Where I think it gets more interesting through is context reuse. Not just verifying a proof, but being able to derive different “views” from the same underlying attestation. Right now it still feels like you’re passing around full proof bundles each time, which works, but doesn’t fully abstract the underlying event.
What I’m currious about is whether ZAP1 (or something built on top of it) could support more granular selective disclosure. Like proving properties of an action instead of the action itself.
Feels like the next step is moving from “proof of event“ to “proof of attributes.“ If thatlayer clicks, this could go way beyond attestations into something closer to a privacy-preserving identity or reputation primitive.
Good question. You’re pointing at the right gap.
What ZAP1 does today: hash the event payload with BLAKE2b, commit the leaf to a Merkle tree, anchor the root to Zcash, hand you a portable proof bundle (leaf, path, root, txid). The raw data stays with whoever created it. Verifier only sees hashes and the proof path. That’s the proof of
event layer.
What you’re describing: proving properties of the event without revealing the event itself, is the next layer up. Instead of handing someone the full leaf and letting them re-hash to verify, you’d generate a ZK proof that says “this leaf satisfies predicate X” and attach that to the same Merkle anchor. The root is already on-chain. The trust model doesn’t change, you’re just narrowing what the verifier learns.
Example: you attested 50 completed tasks. Today you can prove each one individually by sharing the proof bundle. With an attribute layer, you could prove “I completed more than 20 tasks of type X” without revealing which ones, when, or the exact count. Same Merkle root, same Zcash anchor, but the proof is over a circuit instead of a hash path.
The building blocks are there. ZAP1 leaves are BLAKE2b commitments with a fixed structure (type byte + length-prefixed fields). Clean input for a circuit. The Solidity verifier on Sepolia already checks Merkle paths on-chain, adding a SNARK verifier for attribute proofs is straightforward from there. Not built yet. But the architecture doesn’t need to change to support it. It’s an addition on top of the existing anchor/proof layer, not a replacement. The hard part was getting the anchoring and cross-chain verification right. That’s done. The attribute proof layer is where it gets interesting next.
More detail in the Grant Application: ZAP1 Protocol Hardening and Zaino Integration and the GitHub - Frontier-Compute/zap1: ZAP1 structured memo protocol for Zcash. BLAKE2b Merkle commitments, Orchard shielded anchoring, verification SDK. · GitHub . Proof bundle spec is in
docs/PROOF_BUNDLE_V2.md, Solidity verifier is Address: 0x3fD65055...03005C87F | Etherscan Sepolia .
Update since last post.
Custody page is up: frontiercompute.cash/custody.html - split-key wallets where the agent transacts but nobody holds the full key. Policy enforced by Sui Move, every operation attested to Zcash.
v0.5.0 of zcash-ika shipped. The same secp256k1 dWallet that signs Zcash transparent now also derives Bitcoin addresses and builds BTC transactions. One key pair, two UTXO chains. Zcash is the primary path: ZIP 244 sighash, P2PKH, mainnet proven.
npm i @frontiercompute/zcash-ika
Hi, I’m new here. I’ve been building zcashtracker dot com a dedicated charting and data resource for the zcash community. It’s just gone live.
I think Zcash is the most important innovation for the sovereign individual but much of the data is scattered across generic crypto sites. So I’ve bought Zcash analytics together into a zcash specific platform, to give it the attention it deserves.
It initally includes:
My goal is to give people who are new to Zcash and the Zcash community a way to understand Zcash’s relative role among other major assets and to learn more about it.
I’d love any feedback from you all. Check out zcashtracker dot com
Thanks!
Hey, welcome! The zcashtracker site looks super awesome, and great interface/sleek design! Thanks for your contributions to the Zcash ecosystem/community 
Hi shieldedonly
Thanks for the positive feedback.
I want to make Zcash visual, understandable, and accessible to all, so having a great design is important for onboarding people to Zcash.
Feel free to share charts from it as it will help spread the word about Zcash:
zcashtracker dot com
What I’m working on
I’m building an application layer on top of Zcash that treats the wallet as a coordination interface — not just a payment tool.
The core question I’m exploring:
Can shielded transactions and memo fields serve as a structured data transport for multi-step interactions like commerce, messaging, and reputation?
My current view is that this is possible in practice. I have a functional prototype, though not yet released.
The problem
Most wallet UX treats transactions as isolated events.
But real-world interactions are stateful:
orders
confirmations
fulfillment
reputation
There’s currently no standard way to coordinate these flows using only shielded infrastructure.
The 512-byte memo limit is often seen as a hard constraint here.
What the system demonstrates
At a practical level, the system shows that it is possible to:
encode structured, multi-step interaction data within memo constraints
extend effective payload capacity through chunking + reconstruction
maintain usable application flows entirely within shielded transactions
layer additional payload protection at the application level
Without going into implementation details, a significant part of the work has been around:
improving data density within memo constraints
designing a deterministic reconstruction model across multiple memos
and exploring how payload-level encryption behaves alongside Zcash’s existing guarantees
Why Zcash specifically
This design depends on:
encrypted memo fields by default
a shielded transaction graph
On transparent systems, this kind of coordination would expose sensitive data.
Zcash uniquely allows:
What I think is missing
1. Structured memo conventions
There’s no shared schema or standard for memo usage beyond free-form text.
2. Application-layer coordination patterns
The protocol provides primitives, but not interaction models.
3. Practical exploration of limits
There’s a lot of discussion about constraints (e.g., 512 bytes), but fewer working examples that push those limits in real usage scenarios.
Tradeoffs I’m aware of
Off-chain discovery/reputation introduces privacy compromises (e.g., address indexing)
Additional payload protection at the application layer does not make the system post-quantum secure, but may provide limited defense-in-depth depending on the threat model
There are open questions around scalability, scan performance, and UX
Intent
I’m not trying to claim this is a perfect or complete solution.
What I’m trying to show is:
Some of the perceived constraints (memo size, coordination limits) may be more flexible than they appear, depending on how the application layer is designed.
What I’d want feedback on
Where do memo-based designs break down in practice?
Are there known limits (performance, reliability) when pushing memo usage this way?
Are there better approaches to coordination that don’t rely on off-chain components?
Cool site, I would suggest a different font, it kind of hurts my eyes reading it! Your art reminds me of cyperpunkzero a little bit! Thanks for making 
Hey! I’m actually working on something along these lines. Would love to connect. Maybe we could collab on something 
Published a technical walkthrough on using the EIP-152 BLAKE2b precompile for Zcash proof verification on Ethereum. Covers the 213 byte input format, personalization strings, gas costs, and the live mainnet contract.
https://dev.to/zknd3r/verifying-zcash-proofs-on-ethereum-with-eip-152-4h8
Looking good. Would be nice to have a market cap view as well, especially since ZEC’s all-time price chart is so distorted by the early value peak. And personally, I prefer candlestick charts to keep an eye on price, so wondering if those are planned. Maybe with trading volume.
Final feedback I’d provide is the discrepancy between the crypto pairs and the graphs overlaying the prices of gold and the S&P 500. Why not - as with the other comparison graphs - use ounces or a ratio there?