The tool that came out of our developer sprints and workshops and why I think it makes every stage of the funnel work better.
Over the past few months, together with @ZecHub, I’ve been building a developer education funnel for Zcash: the 6–7 week Zcash Developer Workshop, the two-day Zcash Developer Sprint (our first ran with the LAUTECH Blockchain Club with the 2nd and 3rd already planned), and, ahead of us, a Developer Residency and Academy. The through-line of all of it is one goal: raise a new generation of Zcash developers, starting in emerging regions where the talent is deep.
This post is about a tool that came directly out of running those programs: create-zcash-app and why it makes every stage of that funnel work better. I’d love the community’s feedback while I take it further.
The wall we kept hitting
Running the Workshop and the Sprint taught the same lesson from two directions: the Zcash concepts aren’t what stops new developers; getting to a running starting point is.
The clearest example is one I lived. To give our Workshop developers a network to build on, we set out to sync a node and it took us over two weeks of babysitting the sync before we finally had Zebra up and a local network for people to build against. Two weeks, before a single participant could ship a line of application code. That is not a barrier we want a new developer in Buenos Aires or Nairobi or New York to face in this new journey.
The pattern shows up everywhere in this work. Learning resources are fragmented, there’s no clear pathway from “curious” to “building,” and many interested developers simply never reach the building stage and when they get close, the recurring friction is always the same handful of things: node and RPC setup, address types, wiring up shielded-deposit detection.
But here’s the other half, and it’s the hopeful one: when we do get people past setup, the difference is night and day. In the Sprint’s Mini Build Challenge, participants went from fundamentals to seven shipped prototypes in two days ; an Ironwood (NU6.3) migration assistant, peer-to-peer tipping apps, an RPC studio, a privacy-preserving escrow prototype. The appetite and the capability are there. The on-ramp is the bottleneck. So I built the on-ramp.
What create-zcash-app is
create-zcash-app is a scaffolder — think create-next-app, but for shielded Zcash apps. One command:
npx create-zcash-app
…and a developer goes from nothing to a working shielded-payments app running against a local Zcash chain in minutes instead of days. It scaffolds a real, runnable starter app, wires it to a local regtest chain, and ships a small helper CLI so you can fund an address and watch the deposit land in your own UI. All local, all deterministic — nothing to sync, no “works on my machine.”
Underneath it is a TypeScript SDK that hides the hard parts behind a clean API: generate a Unified Address, check balances by pool, build and broadcast a shielded send, and detect an incoming shielded payment with a viewing key. The shielded-note trial-decryption, the Rust-and-gRPC part that might scares new develolpers off all happens under the hood. The SDK targets the current post-Ironwood stack (both the Orchard and Ironwood pools), so what you build is current, not a year behind the protocol.
It deliberately does not reinvent the node layer. It sits on top of the existing Zcash dev stack (Z3, Zebra + Zaino) — and that layer is getting faster and lighter on its own: Zakura, the new Zebra-derived node from Valar Group and Project Tachyon, bootstraps a full node from a snapshot in minutes and supports Ironwood from day one. I’m not out to duplicate any of that. create-zcash-app is the application layer that’s been missing on top of it — the scaffolded app and the developer-friendly SDK — and it’s node-agnostic by design, riding whatever node and indexer you point it at.
From learning to shipping: regtest, then testnet
The scaffolder ships a path, not just a starting point. It targets two networks, and you move between them by changing a single config value:
- regtest — to learn. A local, offline chain with fake money that starts instantly. This is where you build your first app and where every workshop runs: no sync waits, no faucet hunting, deterministic and reproducible on every laptop in the room.
- testnet — to validate. The same app, pointed at the public Zcash testnet (which already runs the current Ironwood upgrade) with test coins. This is where a developer proves their app works against real, live infrastructure — real sync, real block times — before taking it anywhere.
And it stops there, deliberately. Shipping to mainnet is the developer’s own step in their own product; the scaffolder never points a newcomer at real funds. That’s a safety decision as much as a scope one: on both supported networks a developer literally cannot lose anything, which for a learning-and-onboarding tool is exactly the property wanted. regtest is the default; testnet is one opt-in flag away, and the SDK you write against is identical on both.
What it gives you
The scaffolder offers a few starting points, all reductions of one flagship:
- Full-stack Next.js app — the shape most application developers reach for (the flagship)
- Backend / service template
- Scanner service — watch an address, react to deposits
- Browser-only wallet-lite — client-side, via a WASM build
Why this is the on-ramp our funnel needed
This is the part I care about most, because I’ve felt its absence.
No one should ever repeat that two-week node sync — and the ecosystem is fixing it from both ends. At the node layer, newer software like Zakura now bootstraps a full node from a snapshot in minutes instead of days. At the app layer, the scaffolder means regtest is instant and local, while a real network is one config flag away on testnet — not a node you babysit for a fortnight. Between them, a facilitator can take a room from zero to a detected shielded payment in a single session, instead of losing the first sessions to environment setup and Docker debugging instead of teaching Zcash.
I’m building a facilitator-ready workshop lab on top of the flagship template — a guided, checkpointed “zero to detected shielded payment” walkthrough, the thing I plan to ship and the thing I teach with are the same artifact, and the tutorials can’t silently rot as the stack moves, because they are the templates. It’s also designed to meet a developer where they are which is a guided path for someone seeing Zcash for the first time, more room to customize for someone who’s built before — so one tool serves a whole workshop room and the developer who keeps building on their own afterward. It slots into every stage of the funnel:
- Sprint — the Build/Learn/Ship challenge starts from a working app, so two days go to building, not configuring.
- Workshop — the build weeks run on the scaffolder instead of a self-synced node, so the curriculum reaches real application work far sooner.
- Residency — teams start from a runnable shielded app instead of a blank node, so collaborative projects begin at the interesting part.
And because graduating from regtest to testnet is a one-flag change, a participant can take the exact app they built in the room and validate it against a live network on their own — onboarding doesn’t stop at the classroom door.
How it connects to the proposed builders portal
I’m also working on a Zcash developer portal (builders-zcash) which was conceived after a meeting with @Michae2xl and @shieldedmark, is proposed to be a structured, curriculum-style front door for learning to build on Zcash, in the spirit of the build portals other ecosystems use to onboard newcomers. The relationship is intentional: the portal is the discovery and learning surface; create-zcash-app is the runnable payoff the tutorial ends in. You study a lesson, run one command, and you’re inside a functioning app. The workshop lab lives as a track inside the portal, so learning and doing sit in one place and the fragmented-resources problem I keep running into gets a single, coherent home.
How it plans to help other ambassador communities
This is where “raising developers for the ecosystem” becomes something bigger than my own sessions. Our very first Sprint ran with a university blockchain club, and the format is built to be repeatable by any Zcash ambassador community. we don’t want them to hit the same setup wall we did i.e. potentially their own two-week node sync — before teaching a single useful thing.
A shared scaffolder plus a facilitator-ready lab means any ambassador community, in any region, can run a hands-on Zcash onboarding session without rebuilding the harness from scratch. It turns one program into a template the whole ambassador network can run. I’m building it with that reuse in mind from the start which are facilitator notes, classroom-ready prompts, deterministic fixtures so every laptop behaves the same, basically because a funnel that only I can run doesn’t scale, and a funnel anyone can run is how we actually raise developers across the ecosystem.
Why it’s good for the ecosystem
The logic is simple, and both programs have made it concrete for me: fewer builders is an adoption ceiling. Every developer who bounces off the setup is a Zapp that never got built and an integration that never happened. Collapsing time-to-first-app from days (or a two-week sync) to minutes — and pairing it with a training program that scales across communities — is one of the highest-leverage things we can do for Zcash adoption, especially in regions where the developer talent is deep.
Where I’m at, and what I’m asking
I’m actively building this, and it’s already past the whiteboard: a local regtest stack (Zebra + Zaino) is standing up on my machine, and I’m wiring up a local funding flow currently. The SDK and the flagship template are still underway, and the builders portal is in progress. It’s the natural next piece of the developer-raising work I’ve been sharing across the Sprint, the Workshop, and the broader Raising Developers for the Zcash Ecosystem effort. While I take it further and formalize it, I’d appreciate the community’s feedback:
- Does this match an issue you’ve seen onboarding developers to Zcash?
- Anything about the SDK surface or the template set you probably think should be shaped differently?
- Ambassador Community leads would you use a shared scaffolder + workshop lab? What would you need from it to run a session in your community?
Feedback and criticism are very welcome. This came out of watching real developers hit a real wall in my own workshops , including a two-week wall of my own and I want to build the thing that actually gets them over it, for our community and for the ecosystem.