June 16, 2026 monthly update
Hello Zcash family,
Lowo here still living my life as a ZEC member, still building in public, still grateful for this thread.
If you’ve followed my posts here, you know this journey isn’t just about price or one wallet. It’s about showing up month after month as part of a global community that chose privacy when most of the industry didn’t. We face real obstacles together: node operators keeping infrastructure alive while zcashd sunsets and Zebrad takes the lead; wallet teams shipping Orchard-first UX while the protocol evolves; researchers and auditors stress-testing circuits most people will never see; educators at ZECHUB and ZAC helping new people find their footing; governance and grants trying to fund the right work fairly. It’s not easy. It’s not always pretty. But what keeps me here is watching how hard this community works protocol devs, Foundation, ZODL, Shielded Labs, wallet builders, node runners, forum contributors all pushing in the same direction: make Zcash the best privacy blockchain in the world.
Not the loudest chain. Not the most hype. The best private internet money, built right, with math and coordination when it matters. And at the center of that future is Orchard.
Orchard isn’t a side feature or a legacy pool we talk about in passing. Orchard is the future of shielded Zcash unified addresses, modern zk design, the path the ecosystem is building on. Everything we’re doing in Nozy, in Crosslink planning, in Ironwood, in wallet pilots it orbits Orchard. When Orchard sneezes, the whole ecosystem catches a cold. When Orchard gets stronger, we all level up.
That’s why the last ~30 days hit so hard, and why I want to document them here.
The Orchard incident + NU6.2 (what the network went through)
Late May, Taylor Hornby (security researcher working with Shielded Labs) found a critical soundness bug in the Orchard circuit the kind of flaw that could have allowed undetectable counterfeit ZEC inside the Orchard pool. Not something you want to read about on a Monday.
The ecosystem moved fast:
- May 29 — private disclosure to ZODL
- June 2 — emergency soft fork: Orchard actions temporarily disabled on mainnet (around block 3,363,426) while the fix was prepared
- June 3 — NU6.2 hard fork: Orchard re-enabled with a corrected circuit (around block 3,364,600)
Node operators needed Zebra 4.5.3 → 5.0.0 (or current zcashd releases). Sapling and transparent transactions kept working during the Orchard pause. As far as public reporting goes, no evidence of exploitation but the community is rightly not asking anyone to “just trust us”; that’s part of why Ironwood is on the roadmap.
Huge respect to ZODL, ZF, Shielded Labs, Project Tachyon, and everyone who coordinated that response. Five days from disclosure to NU6.2 is not normal protocol work that was an emergency sprint. And it reminded me why Orchard-first development isn’t optional for wallets like Nozy it’s A MUST.
Orchard took a hit, the community responded, and we’re still building on it, because shielded Zcash is Orchard, and Orchard is where this chain is going.
I attended the “There Is No Orchard Backdoor” Office Hours call
A few days before the May 29 disclosure, Shielded Labs hosted a special session to answer the backdoor narrative directly not with slogans, with a walkthrough: What the session was (and wasn’t)
Connor framed it clearly: this was about how to audit Orchard for a privacy backdoor not absolute mathematical proof for everyone in 90 minutes, but where to look and what evidence would look like if something intentional were hiding in the protocol.
Important scope from the talk:
- In scope: privacy in Orchard shielded actions — could someone break note confidentiality or deanonymize users via a hidden trapdoor?
- Explicitly out of scope that day: soundness / inflation, transparent pool, wallet client bugs, network layer, user OPSEC, custody
- Trusted setup: Orchard uses Halo 2 — no trusted setup (unlike Sprout/Sapling; Sapling’s ceremony had ~87 participants — all would’ve had to collude to counterfeit). That’s an inflation story, not a “they can read your notes” backdoor story. Sprout had a bug that was fixed before Sapling launched — history lesson, not Orchard’s model today.
The talk’s goal: evidence there is no intentional privacy backdoor, not “trust us forever.”
That scope matters in hindsight. Three days later, Taylor Hornby found a soundness bug — counterfeit ZEC in the pool, not a “read everyone’s notes” backdoor. Different category. The Office Hours session didn’t fail because soundness wasn’t on the whiteboard that day; it answered a different question the timeline was asking loudly on CT.
Orchard is Halo 2 where a backdoor could hide (in theory)
Connor laid out four places someone would hunt if they believed in an intentional backdoor:
- Commitments
- Note encryption
- Curves / arithmetic
- The proof system itself
Full cryptanalysis = thousands of lines and a long whiteboard. The session was a map, not the whole hike.
Real mainnet tx as case study
They pulled a real recent mainnet shielded transaction about 37 KB of JSON leaving the wallet, and broke it down:
- 26 fields always present (+ Orchard action fields)
- 13 = chain metadata (not the privacy core)
- 6 = transparent / legacy shielded pools (empty in the example tx)
- 7 = Orchard-critical for privacy review
Each Orchard action (spend or output) has 8 computed fields worth scrutinizing:
- Nullifier — Poseidon over nullifier key (NK) and note commitment (CM); blinding (ψ); discrete-log structure; stops double-spend without revealing which note
- RK (randomized public key) — sender’s key with randomness so you can’t fingerprint them
- Spend auth sig — signature under the private key for RK
- CV (value commitment) — Pedersen commitment on value balance + randomness (RCV); hash-to-curve on specific strings
- CMX — x-coordinate of note commitment point; Sinsemilla over sensitive note material (address, value, ρ, ψ, etc.)
- Ephemeral key — part of the encryption / DH story
- Enc ciphertext / out ciphertext — encrypted note payload
Building blocks that stuck with me
Pedersen commitments described as perfectly hiding (even an unbounded adversary shouldn’t pull secrets out). Homomorphic: commitments add → commitment to the sum of values. Shielded balance math is nearly impossible without that it’s structure, not magic.
Poseidon — ZK-friendly hash; Orchard-specific constants are audit targets (Grain LFSR generation per the Poseidon paper and Zcash spec). Unusual hash functions deserve extra eyes before you trust a system with them.
Note encryption Connor called this the most sensitive area for a privacy backdoor hunt:
- DH shared secret → key derivation → ChaCha20-Poly1305
- Implementation in
zcash_note_encryption (small Rust surface, minimal deps)
- Same cipher family as Signal — not proof alone, but real-world trust signal
Tachyon note (forward-looking): encryption may move out of the core protocol so users can choose layers (Signal-style, PGP, etc.) interesting for wallet builders like us.
Halo 2 proof ~14.5 KB per Orchard bundle; public inputs from the tx, private inputs stay inside the proof. The proof is the “final boss” it has to enforce everything without leaking secrets. Connor pointed to his blog “Demystifying Formal ZK Snark Jargon” for the formal ZK vocabulary. STARK-style designs can avoid elliptic-curve Pedersen machinery (SHA/Blake only) different tradeoffs; Orchard chose Pedersen for performance and ergonomics.
Quantum angle (not a “backdoor”): Pedersen machinery isn’t the long-term quantum story for privacy guarantees; that’s a future migration concern, not “someone has a secret key today.”
My takeaway from the call
- Backdoor FUD ≠ soundness bug. May 26 was the right response to “prove you’re not watching my notes.” May 29 was “the circuit math had a hole that could mint fake coins.” Both are serious; they’re not the same accusation.
- Orchard is still the future — unified shielded path, Halo 2, no ceremony — but formal verification + open review (Tachyon, Ironwood, ironwood Lean work) isn’t optional anymore.
- As a Nozy builder on Zebrad, I touch this stack every day — RPC
getblock, action parsing, trial-decrypt, tx build. Every field Connor named flows through our dependencies.
- Community obstacle we share: when CT conflates “backdoor” and “bug,” holders panic and builders get drowned out. Sessions like this + honest post-disclosure threads are how we earn trust work, not vibes.
This timeline doesn’t show that it’s an backdoor which is great.
Dynamic fees (wallet pilot wave)
Dynamic Fees, Now! — UX-first, not a rushed consensus ZIP. Pilots wallets can try today:
- Priority delivery (~4× standard fee)
- Short expiry on pending txs
- Speed-up (rebuild a new tx — Zcash doesn’t do Bitcoin-style RBF)
Several wallets are experimenting. Nozy is in that conversation. Nozywallet was mentioned in arborist call for implementing the Dynamic fee.
NozyWallet — what we shipped (May–June 2026)
For anyone new: Nozy is Leonine DAO’s Orchard-first wallet built for Zebrad (+ optional lightwalletd / compact cache via Zeaking). CLI is what we call production-ready today; desktop, extension, API companion, and mobile are active development.
Recent merges on Nozy-wallet:
- #34 — Zeaking Phase 2 (
sync-to-tip, companion ergonomics)
- #35 — Dynamic-fee pilot A1 (ZIP-317, opt-in priority ×4, short expiry on CLI + api-server + desktop)
- #36 — Desktop History transaction status in API/UI
- #58–60 — Thanks @aphelionz (Mark / Shielded Labs) — librustzcash NU6.2 deps, expiry delta 2→5 blocks, Orchard action fee counting fix
- #75 — Sync persistence (repeat
/api/sync no longer zeroes balance); tx expiry detection; POST /api/transaction/speed-up
- #76 — Speed-up UI — desktop History button + extension WASM path
- #77 — Structured
/api/sync errors (phase, block_height, scan range, code) — not opaque HTTP 500
- #78 — Retry transient Zebrad
getblock body decode failures (tester feedback)
Lowo88⚡️🛡️🌑 on X: "New patch release for Nozywallet just went live. $ZEC #Nozywallet https://t.co/szMXTDlKfa" / X GitHub releases stay CLI-focused until desktop/extension/API are ready to promote broadly.
School — CS141, Unit 5, Android Studio, and the path to Nozy mobile
Still full-time Computer Science at Colorado Technical University about 9 months left before the degree catches up to what I’m already building in the wild. School and Nozy keep feeding each other. This month two things lined up: a processor architecture paper tied to real Zcash node work, and Android Studio where I plan to land NozyWallet mobile.
My assignment (for anyone who wants to read it):
Teranji Terrell Unit 5 Assignment.docx
Unit 5 — what the paper is about
Course: CS141 — Fundamentals of Computer Organization and Architecture
Assignment: Unit 5 — Processor Architectures and Their Suitability for Real-World Applications (with focus on Zcash node operations)
Instructor: Curtis Shull
Submitted: June 5, 2026
Name on the paper: Teranji Terrell
The paper compares four processor architectures and asks which real-world workloads fit each one — not in the abstract, but framed around running and maintaining a Zcash node (zcashd / Zebrad): chain sync, transaction validation (including zk-SNARK work), mempool handling, mining context (Equihash), analytics, and explorer-style query load.
The four architectures:
| Architecture |
Core idea |
Best-fit workloads (in the paper) |
| GPU |
Thousands of threads; massive data-parallel math |
3D visualization of structures (e.g. Merkle trees); big data — batch zk-SNARK verification, network analytics, Equihash-style parallel hashing. Weak at strict ordering and heavy I/O. |
| Superscalar |
Instruction-level parallelism — multiple pipelines, reorder buffers |
Simulation modeling (network propagation, consensus scenarios); database-style transaction processing — validation, mempool, block processing with branching control flow. |
| Multicore |
Thread-level parallelism across independent CPU cores |
Database / node DB work — sync, concurrent validation, UTXO/set management, wallet ops; explorer / search — high-volume concurrent lookups (txid, address, height). |
| Heterogeneous multicore |
CPU + GPU on one chip — serial orchestration + parallel crunch |
Big data analytics engine for a full node: CPU for I/O and sequencing, GPU for parallel proof verification and mining-adjacent work; “real-time interactive” analog (dashboards, monitoring). Most complete platform for a production-grade node stack. |
Conclusion of the paper (short): no single architecture wins everything — heterogeneous multicore is the most versatile for a node that does sync, validation, analytics, and interactive services at once. That matches what I see running Zebrad at home: lots of multicore general work (RPC, sync, peer networking) with bursts of parallel-friendly crypto when the workload allows it.
Why my instructor was impressed
I turned it in as Teranji Terrell (legal name on the assignment). Professor Shull said he was impressed with how I connected the textbook architecture types to actual Zcash infrastructure — not generic “video editing uses GPU” examples, but Merkle trees, shielded validation, mempool, explorer queries, and node sync as the workload lens.
What helped, I think:
I’m not writing about Zebrad from a blog summary — I run nodes, broke sync more than once (delete_old_database = true era — never forget), and I’m building Nozy on top of JSON-RPC getblock and Orchard scan paths.
My 4.0 GPA is proof tying homework to something you actually operate is worth the extra hour.
Android Studio — building toward Nozy mobile
Separate from CS141 but same semester energy: we’re learning to build apps in Android Studio — layouts, activities/fragments, Gradle, emulator testing, the Android lifecycle.
Plan: take what I learn there and apply it to the NozyWallet mobile path Leonine DAO already started (mobile/ Expo shell today; longer term native pieces via zeaking-ffi).
Rough split I have in mind:
- Power users / operators — CLI + Zebrad + nozywallet-api companion (what Nozy is strongest at now).
- Everyday users — mobile send/receive, balance, simple flows; Android Studio skills for the Android side of that story (and the same CS141 lesson applies: pick the right architecture — phone SoC is heterogeneous multicore out of the box).
- After Crosslink — lighter clients for voters/stakers; operators keep the full stack.
CS141 says heterogeneous SoCs win combined workloads; a phone running a wallet companion talking to your home node (or Crosslink later) is literally that model in your pocket.
How this ties back to Nozy (and Gilmore’s sync bug)
The paper’s multicore section (explorer search, concurrent validation) and GPU section (parallel zk work) rhyme with Nozy’s design choices:
- Parallel block scan — multiple
getblock calls in flight (multicore + async I/O).
- Serial confirmation checks — one pending tx at a time where order matters.
- Gilmore’s
/api/sync issue — parallel fetch stressed Zebrad; transient decode failure, not bad block data — classic “parallelism needs retry and fault tolerance” (we shipped #78).
School theory → forum post → GitHub PR. That loop is why I keep writing here and help me learn better, I say this makes me a better ZEC member.
ZECHUB — Builder Series and space to tell the Nozy story
I’ve said before I’m a ZECHUB member not as a badge, but as someone who actually shows up. ZECHUB has been doing the unglamorous work that grows a chain: developer education, curated resources, onboarding paths, and room for builders who aren’t already inside ECC or Shielded Labs to learn and contribute. The developer hub is a real “by builders, for builders” manual install, config, tutorials, links into deeper Zcash docs. That matters when you’re a solo founder trying to ship an Orchard-on-Zebrad wallet from Atlanta with a CS homework load.
The bigger step this month: ZECHUB gave me a stage to explain Nozy properly. 
@thedrekal (TheBigDre) announced a Zcash Developer Workshop — Builder Series session with me as guest:
Builder Series: Nozy Wallet
Announcement: X post — Jun 12, 2026
His line stuck with me: “Building is one thing. Shipping a product that users can actually use is another.” That’s the truth. You can fork repos all day; shipping CLI releases, api-server for integrators, Gilmore finding real /api/sync bugs, NU6.2 dependency bumps with Mark — is a different muscle.
What we planned to cover in the session:
- Why Nozy was built — Orchard-first, Zebrad + optional lightwalletd / Zeaking, privacy by default, own-your-stack
- Architecture —
nozy core crate, CLI, desktop (Tauri), extension + WASM, nozywallet-api companion, roadmap to mobile
- Challenges — privacy-first products aren’t “add encrypt()”; scan/sync RPC load, witness paths, emergency protocol months like Orchard/NU6.2, honest limits (we document what Zebrad can and can’t do)
- Lessons for aspiring builders — build in public, test with real node operators, structured errors beat opaque 500s, school + node + wallet can live in one life
The workshop program itself grew out of community conversation on the forum Zcash Developers training — structured 6–7 week virtual path: Zcash fundamentals, shielded txs, zebrad / zcashd, SDKs, then build real apps. I commented early that I wanted to help teach Zebrad + Nozy CLI — run a node, manage data, testnet, break things safely in a fully shielded terminal wallet. ZECHUB and Drekal turned that into guest space, not just a forum comment buried on page 4.
Good work I want to name explicitly:
- Curriculum + onboarding — lowers the wall for new Zcash devs
- Guest / Builder Series — real wallets, real tradeoffs, not only protocol slides
- Community bridges — ZECHUB, ZAC, forum, workshop Discord/streams
- Letting Nozy be a teaching example — even when we’re still pre–App Store mobile and CLI-first releases
Thank you to ZECHUB, @Dre_Nesthub @elzz-ux, and everyone behind the Zcash Developer Workshop for trusting me with a session on Nozy Wallet. Privacy is normal; education is how it scales. If you’re learning Zcash dev, start at zechub.wiki/developers and jump into the workshop threads then run Zebrad and break something on testnet on purpose
