# NozyWallet Development Roadmap **URL:** \ **Category:** Zcash Apps\ **Created:** [December 9, 2025, 6:53am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745 "2025-12-09T06:53:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [December 9, 2025, 6:53am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/1 "2025-12-09T06:53:23Z")
A Privacy-First Zcash Wallet Journey **Status:** Development in progress **The Beginning Of The Problem We Set Out to Solve** September 4 the day I realize the Zcash community was facing a critical privacy challenge: **transparent addresses (T-addresses) were exposing transaction patterns and compromising user privacy**. While Zcash shielded pools (Sapling, Orchard) offered strong privacy guarantees, many users were still using transparent addresses out of convenience or lack of awareness. Some would say why buy Zcash when Bitcoin just as good, the crazy part about it. They would be right. Due to the T-address it’s basically Bitcoin with the option of privacy and for a real Cypherpunk that’s not good enough. Nozy is the first wallet built on Zebrad rust base Node the Zcash community deserver a true privacy wallet with no T-add codebase for 100% trusted privacy. This process was ok since last year I been testing different algorithms to build a Zcash wallet even enter Near x Zcash hackathon last Near community zool zeeps. The Monroe community love to troll Zcash community about it T address no worries Nozy is here. **Community Concerns Identified:** - T-address transactions are fully visible on the blockchain - Transaction patterns can be analyzed and linked - Privacy-conscious users needed better tools - Existing wallets didn’t emphasize privacy-first design - Education gap about shielded vs transparent addresses **The Vision:** Create a wallet that makes **fully-shielded transactions the default** , not an option. A wallet that educates users about privacy while making it effortless to use. A few features that will be apart of Nozywallet once the frontend is done and ship. NozyWallet will have a page dedicated to educating the user’s on financial privacy. Phase 1: Foundation & Core Development ### September - December 2025 ### September 2025 - **Week 1-2:** Initial brainstorming and architecture design - Decision to build on Zebra (Zcash full node) - Focus on Orchard shielded transactions only - Privacy-first design principles established **Week 3-4:** Core wallet infrastructure - HD wallet implementation (BIP32/BIP39) - Encrypted storage system - Key management and derivation ### October 2025 - **Core Features Development:** - Orchard note scanning and decryption - Transaction building (fully-shielded) - Balance calculation and display - Transaction history tracking - Address book functionality - Wallet backup and restore **November 2025** In November was a quite time since, I submitted NozyWallet for a retroactive grant ([Nozy wallet Retroactive Grant](https://forum.zcashcommunity.com/t/nozy-wallet-retroactive-grant/52417)) funding was not a success. At the time of submission Nozy only had the wallet creation password and orchard implemented. My rejection last month was understandable getting my feet wet with grant proposal. Was a learning experience and a chance to get better at begin a valuable community member. **User Experience:** - CLI interface development - Progress indicators and feedback - Error messages and user guidance - Password protection and encryption - Multi-chain CLI commands (Monero, Secret Network) still in progress will be release in v0.3.0 **December 2025** Doing this time the frontend getting develop and improving Nozy code. Making sure everything is clean and smooth for frontend release. I have a domain space for Nozy already will be release soon. **NU 6.1 Constants** \*\* [Bump version to 0.2.0 for NU 6.1 support release · LEONINE-DAO/Nozy-wallet@e193864 · GitHub](https://github.com/LEONINE-DAO/Nozy-wallet/commit/e193864365b652dec05dd96c6c7579dd77629edf) - Activation height: 3,146,400 - Protocol version: 170140 - All constants verified _Compatibility Checking_ - `verify_nu6_1_compatibility()` function - `display_nu6_1_status()` function - CLI command `nozy nu61` _Status Integration_ - NU 6.1 status in `nozy status` command - Block height checking - Activation status display **Security Hardening:** \*\* - Comprehensive error handling (removed all `unwrap()` calls) - Mutex poisoning protection - Secure key storage - Input validation Advanced Features & Optimization ### Q1-Q2 2026 Zeaking Indexing System:\*\* - Local blockchain indexing for fast queries - Transaction history caching - Orchard action tracking - Performance optimization - **Privacy Network Integration:** **Q2 2026** We’re actively working on two major feature sets for Q2 2026: 1. **Cross-Chain Swap Functionality** (XMR ↔ ZEC) 2. **Secret Network / Shade Protocol Integration** (Enhanced) Both features have foundational frameworks in place and are being actively developed and refined. - **Cross-Chain Features:** - XMR ↔ ZEC swap functionality (framework in place) - Privacy-preserving swaps - Rate monitoring and caching 1. **Swap Engine Architecture** (`src/swap/engine.rs`) 2. **Swap Service Client** (`src/swap/service.rs`) 3. **Swap Storage** (`src/bridge/swap_storage.rs`) 4. **Privacy Infrastructure** **Privacy Features** - **No Address Reuse** : Automatic new address generation - **Privacy Network Routing** : All swap API calls through Tor/I2P - **Monero Churning** : Optional churning for enhanced privacy - **ZK Verification** : Monero ZK proof verification - **Rate Privacy** : Rate queries through privacy networks _ **Secret Network / Shade Protocol Integration:** _\* - Secret Network RPC client - SNIP-20 token support (Shade, Silk, etc.) - Shade Protocol integration - Private smart contract interactions - HD wallet key derivation for Secret Network Adding Zcash to Shade protocol will be a privacy power house long with Silk stable coin. Bitcoin is apart of Silk assets basket for this to be a privacy stable coin. I think Zcash would be a great addition to the asset basket and once ZSA come out who knows what the future holds. Below a breakdown on the Secret Implementation good thing I already had code ready and it went will with Nozy codebase. ### Current Status: **Core Features Implemented, Active Enhancement** ### What’s Working Now 1. **Secret Network RPC Client** (`src/secret/rpc_client.rs`) 2. **SNIP-20 Token Support** (`src/secret/snip20.rs`) 3. **Secret Network Wallet** (`src/secret/wallet.rs`) 4. **HD Wallet Key Derivation** (`src/secret_keys.rs`) 5. **Transaction Management** _What’s Getting Working On Now_ 1. **Private Smart Contract Interactions** 2. **Shade Protocol Integration** 3. **Enhanced HD Wallet Integration** 4. **Transaction Building & Signing** ### Technical Implementation **Secret Network Architecture:** ```auto HD Wallet → Key Derivation → Secret Key Pair → Address Generation ↓ RPC Client → LCD Queries → Encrypted Responses → Decryption ↓ SNIP-20 Interface → Token Operations → Private Contract Calls ``` **Key Components:** - `SecretRpcClient`: Low-level RPC communication - `SecretWallet`: High-level wallet interface - `Snip20Token`: SNIP-20 token operations - `SecretKeyDerivation`: HD wallet key derivation - `SecretTransactionStorage`: Transaction history ### Privacy Features - **Encrypted Queries** : All contract queries encrypted - **Viewing Keys** : Private balance viewing - **Privacy Network** : Tor/I2P proxy support - **Private Transactions** : Encrypted transaction data - **SNIP-20 Privacy** : Private token transfers * * * ## Development Approach ### Active Development Areas 1. **Integration Testing** 2. **Error Handling** 3. **Performance Optimization** 4. **User Experience** ### Code Organization **Swap System:** - `src/swap/` - Core swap functionality - `src/bridge/` - Cross-chain bridge components - `src/monero_zk_verifier/` - ZK proof verification **Secret Network:** - `src/secret/` - Secret Network integration - `src/secret_keys.rs` - Key derivation - `src/secret/` - Wallet and RPC clients _We’re actively working on these features and making steady progress toward Q2 2026 production release!_ Development Progression - Wallet creation - Address generation - Basic storage - Note scanning - Balance checking - Zebra integration - **Transaction sending added** - Transaction history - Address book - Multi-chain support - Enhanced features _Feature-Focused_ **Privacy-First Design** - All swap operations routed through privacy networks - No address reuse in swap transactions - Encrypted Secret Network queries - ZK proof verification for Monero ### Unified Architecture - Single HD wallet for all chains - Consistent API across features - Shared privacy infrastructure - Unified error handling ### Production-Ready Foundation - Comprehensive error handling - Persistent storage - Transaction tracking - Security best practices **Key Design Principles** 1. **Privacy First:** Fully-shielded transactions are the default 2. **User Education:** Help users understand privacy implications 3. **Security:** No compromises on security best practices 4. **Open Source:** Community-driven development 5. **Transparency:** Clear communication about features and limitations ### _Lessons Learned_ - Starting with a clear privacy vision - Building on Zebra for reliability - Focusing on core features first - Community feedback integration ### Challenges Overcome - Complex cryptographic implementations - Multi-chain integration complexity - Security hardening requirements - Dependency management * * * ## Acknowledgments - **Zcash Foundation** - For the amazing shielded pool technology - **Zebra Team** - For the excellent full node implementation - **ZCash Community** - For feedback, testing, and support - **Open Source Contributors** - For the incredible ecosystem * * * ## Get Involved - **GitHub:** [LEONINE-DAO/Nozy-wallet](https://github.com/LEONINE-DAO/Nozy-wallet) - **Issues:** Report bugs or request features - **Discussions:** Join the conversation - **Contributions:** Pull requests welcome! * * * ## The End - This roadmap reflects our journey from September 2025 to present - Dates are approximate and subject to change based on priorities - Community feedback shapes our development priorities - Grant funding may accelerate certain phases * * * **“Privacy is not an option. It’s a fundamental right.”** _NozyWallet - Making Zcash privacy accessible to everyone._ **“NozyWallet is a fully-featured Orchard wallet designed for Zebra, implementing the latest Zcash privacy protocols to ensure your transactions remain completely private and secure.”** “NozyWallet is the first fully-functional Orchard wallet built specifically for Zebra, representing the future of ZEC storage and the next evolution in cryptocurrency privacy.” Let me know what you think @ShieldOrder ZCG candidates I’m ready to get jump 😅 ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [December 9, 2025, 7:23am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/2 "2025-12-09T07:23:04Z")
**NozyWallet actively implements and supports Zcash ZIPs:** - **5 ZIPs Fully Implemented** : ZIP 32, 224, 225, 271, 1016 - **Standards Compliant** : Follows ZIP specifications precisely - **Production Ready** : Real-world tested implementations - **Privacy First** : Demonstrates privacy-focused ZIP usage - **Open Source** : Contributes to ZIP ecosystem ---
**Author:** ![ShieldOrder](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shieldorder/32/42014_2.png) [@ShieldOrder](https://forum.zcashcommunity.com/u/ShieldOrder)\ **Post date:** [December 9, 2025, 3:56pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/3 "2025-12-09T15:56:07Z")
Thank you for laying out the roadmap. I apply the same evaluation structure to every technical proposal, and your outline is clear enough to evaluate without interpretation. Impact The work anchored to core Zcash invariants carries the strongest weight. Orchard-only flows, NU6.1 compliance, removal of unsafe patterns, deterministic scanning, and Tor/I2P routing all move the privacy surface in the right direction. The indexing layer and deterministic behavior are the most load bearing elements here. Clarity You’ve broken the work into understandable modules. One improvement would be sharper boundaries between the Zcash-native components and the optional cross-chain or Secret Network layers. Reviewers need to see exactly what is protocol-coupled and what is discretionary. Alignment Everything tied to Orchard note handling, shielded-default UX, NU6.1 readiness, and privacy-first design fits squarely within ZCG’s mandate. The cross-chain elements are not misaligned, but they should remain clearly optional surfaces. The Zcash path needs to stay primary. Deliverability The Zcash components sit in tractable domains. For the heavier modules, the next milestone should be narrow and verifiable rather than broad: • deterministic Orchard note detection under NU6.1 • a minimal swap handshake with test vectors • an indexing correctness proof for a fixed range These keep progress inspectable. Verification Much of this roadmap is naturally testable. Deterministic builds, indexing behavior, Orchard action tracking, and NU6.1 validation can all be evidenced with small artifacts. For upcoming modules, early traces or sample interactions will anchor evaluation to evidence rather than interpretation. Predictable evaluation works best when applicants and reviewers operate from the same criteria, and your structure already supports that. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [December 9, 2025, 5:53pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/4 "2025-12-09T17:53:02Z")
Ok, Thanks for this feedback this all useful > [@ShieldOrder](#): > > The indexing layer and deterministic behavior are the most load bearing elements here. Should I focus on this more?? ---
**Author:** ![ShieldOrder](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shieldorder/32/42014_2.png) [@ShieldOrder](https://forum.zcashcommunity.com/u/ShieldOrder)\ **Post date:** [December 9, 2025, 6:08pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/5 "2025-12-09T18:08:52Z")
Yes, this layer warrants more focus because it defines the reliability surface for everything built on top of it. 1. It is the foundation the rest of the system inherits. If indexing, note detection, and local state reconstruction are deterministic and reproducible, every higher level feature stays on solid ground. 2. It is the part a reviewer can verify without interpretation. A bounded correctness check over a fixed block range, repeatable on another machine, is the clearest artifact you can produce. It anchors evaluation in evidence. You do not need to expand scope. You only need to make the expectations around this layer precise enough that the deliverable and the test are obvious. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [December 9, 2025, 6:52pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/6 "2025-12-09T18:52:30Z")
Ok got it in my computer algorithms class I’m learning about inverted files/indexing good timing. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [February 3, 2026, 8:33pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/7 "2026-02-03T20:33:43Z")
# NozyWallet — Community Update: Recent Development Summary **February 2025** This document summarizes the desktop app and UX work completed recently mobile app in the works as well. We’re sharing it so the Zcash community can see what’s new and what’s next. Some tasks like the tooltip haven’t yet been push to GitHub still cleaning up the code etc. * * * ## Transaction History (Desktop) **Real data and full-featured UI** - **Live history** — The History tab now loads real transaction data from the wallet backend instead of mock data. Loading and error states are handled. - **Filter and search** — You can filter by type (sent/received), status (confirmed/pending), and date range (last 7, 30, or 90 days). A search box filters by address, transaction ID, or memo. All filters and search run on the actual transaction list. - **Export** — An “Export CSV” button downloads the currently filtered list as a CSV file (date, type, amount, address, status, memo, transaction ID). File name includes the export date. - **Detail view** — Clicking a transaction opens a detail modal with transaction ID, type, amount, date, address, status, memo, and (when the backend provides them) confirmations, block height, fee, and broadcast time. - **Fiat equivalent** — In Settings → Display you can turn on “Show fiat equivalent” and choose USD or EUR. You can use a live price from CoinGecko (cached 5 minutes) or a custom rate. When enabled, History list and detail view show fiat amounts next to ZEC. * * * ## Address Book & Contacts **Backend API and full Contacts UX** - **API layer** — The desktop app now calls address book operations: list, add, remove, get by name, and search. Types and API shape are documented so the Tauri backend (when present) can implement the same commands. The existing HTTP api-server already exposes address book endpoints. - **Contacts page** — A dedicated Contacts screen (Profile → Contacts) lists all saved addresses with name, address, and notes. You can search, add contacts (name, shielded address, optional notes), remove contacts, and copy addresses. The page handles loading, errors, and empty state. - **Send flow** — On Send you can “Choose from contacts” to pick a saved address, and “Save to contacts” to add the current recipient (with name and optional notes). Both use the real address book API. - **History** — In the transaction detail modal, a “Save to contacts” button appears when the address is a shielded address (u1/zs1), so you can save recipients from past transactions. * * * ## Onboarding & First-Run UX **Security tips and first sync** - **Backup phrase** — The create-wallet flow still shows the recovery phrase and requires “I’ve saved my recovery phrase” before continuing. The wording stresses that no one should ever ask for the phrase. - **Security tips step** — After saving the recovery phrase (create) or after restoring a wallet, a short “A few security tips” step appears before entering the app. It covers: never sharing the recovery phrase, verifying addresses before sending, syncing the wallet to see balance and history, and keeping the app updated. A “Get started” button then enters the main app. - **First sync** — After first entering the app, a dismissible banner asks you to sync the wallet to see balance and history. “Sync now” runs a sync and then dismisses the banner; the close control dismisses without syncing. The choice is remembered so the banner does not show again. * * * ## Tooltips on Key Controls **Reusable tooltips and clearer UI** - **Tooltip component** — A shared Tooltip component shows a short label on hover/focus. It’s positioned above or below the control and rendered in a way that avoids clipping by scroll containers. It supports accessibility (e.g. `aria-describedby`). - **Where they appear** — Tooltips are used on: header Sync button (“Sync wallet with the network”), Home / History / Browser nav items, balance show/hide toggle, Receive and Send buttons, address copy area, Send form “Max” amount and Review button, and History Export CSV button. Copy is short and user-focused (e.g. “Copy address”, “Use maximum spendable amount (after fee)”). * * * ## Foundation Layer (Determinism & Reproducibility) **What it is** — The base layer that everything else relies on: indexing, note detection, and local state reconstruction. We keep it deterministic and reproducible so higher-level features stay on solid ground. **Key points** - **Indexing** — `NoteIndex` returns notes in deterministic order (by height, then insertion). See `src/note_index.rs`. - **Note detection** — `NoteScanner` processes blocks in ascending order and deduplicates by nullifier. Same chain + same range ⇒ same result. See `src/notes.rs`. - **Wallet restore** — Same mnemonic + same block range ⇒ identical balance and note set (local state reconstruction). - **Verification** — Bounded correctness check over a **fixed block range** (e.g. 3\_146\_400..3\_146\_450). Tests in `src/tests/deterministic_scanning_tests.rs`: same-wallet multiple scans, restore determinism, incremental vs full scan. Run with Zebra: `ZEBRA_URL=http://localhost:8137 cargo test --ignored`. * * * ## What’s Next Planned work (from our roadmap) includes: - **Structured error messages** — Clearer, user-friendly error copy and (where useful) error codes. - **Sync/proving progress** — A visible indicator when the wallet is syncing or when proving parameters are downloading. - **Further UX polish** — Onboarding refinements, more tooltips where helpful, and continued hardening for production. We’re also working toward a **third-party security audit** (planned Q1–Q4 2026), **mobile apps** (iOS/Android), and **hardware wallet support**. When the time come if the community know anyone who can help please reach out. ---
**Author:** ![decentrathai](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/decentrathai/32/43001_2.png) [@decentrathai](https://forum.zcashcommunity.com/u/decentrathai)\ **Post date:** [February 5, 2026, 1:42pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/8 "2026-02-05T13:42:45Z")
More wallet options = healthier ecosystem 💪 We faced similar sync tradeoffs building ZChat (shielded messenger). User needs vs node purity is real. Keep shipping! 🚀 ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [February 7, 2026, 3:27am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/9 "2026-02-07T03:27:05Z")
Let’s go! Good luck on your submission, I’ll adopt ZChat for Nozywallet pure community build. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [March 19, 2026, 8:11pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/10 "2026-03-19T20:11:56Z")
Hello everyone, March update is here since the previous post, we shipped a major browser-extension milestone focused on privacy-first Orchard transaction flow and end-to-end execution. The mission is to have Nozy in every browser similar to MetaMask as but with Privacy first in mind. NozyWallet is your main gateway to the world of decentralized apps and cryptocurrencies. So, you can start managing your crypto assets or exploring blockchain projects in a private way in just a few clicks. ### What we shipped - Browser extension transaction pipeline (MV3) is now live - Service worker + worker + popup are now wired for full transaction lifecycle handling. - Real Orchard witness integration - We replaced synthetic witness logic with real RPC-derived witness inputs (`anchor`, `position`, `auth_path`) for spend proving/building flow. - WASM Orchard v5 transaction build - Added WASM-side function to build real Orchard v5 tx bytes from spendable note + witness input. - Returns serialized raw tx hex + txid metadata for submission. - Broadcast flow integrated - Approved transaction requests are now broadcast via RPC (`sendrawtransaction`) from extension background flow. - Approval flow hardened - dApp/provider requests are now resolved after explicit wallet approval handling in the extension flow. - Confirmation polling added - After broadcast, the service worker polls transaction status for confirmation visibility. - Build artifacts and packaging - Updated WASM package artifacts and popup dist artifacts to keep extension packaging reproducible. - CI cleanup shipped - Regenerated Rust lockfiles, fixed rustfmt check issues, and resolved npm audit vulnerability lockfile updates so workflows pass. ### Why this matters This moves us from “proving/wiring prototype” into a practical extension execution path: approve → build → serialize → broadcast → confirmation check. ### Next priorities - Production fee policy + stronger coin/note selection - Better transaction state UX (pending/mempool/confirmed) - More robust recipient validation and error messaging - Continued hardening/testing toward production readiness Thanks again to everyone following and giving feedback. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [May 11, 2026, 6:15am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/11 "2026-05-11T06:15:26Z")
**Hello everyone** sharing a roadblock hit and how, I address it. With how NozyWallet was built, shielded sends were not reliable when the wallet depended only on Zebrad’s JSON-RPC for everything the prover needs (e.g. witness / Merkle-path style data). That stalled proving and was worrying until we mapped it to a concrete fix. We’re aligning the send path with the usual Zcash light-client stack: Zebrad + lightwalletd (gRPC compact blocks) + the wallet’s local Orchard witness / anchor checks against the node (as documented in our tree). I’ll post updates as the code lands. What’s Done: No reliance on Zebrad position/authpath RPCs for proving; spends use local incremental witnesses + treestate check + local prove; lightwalletd + Zeaking already back compact sync and related tooling. April was good the goal moving head start improving zeaking witness catch-up from **the same compact bytes Zeaking already persists** , so **shielded send** matches a **compact-first** story end-to-end: lightwalletd as the primary chain-data pipe into SQLite, Zebrad for treestate checks, broadcast, and other RPC that compact does not replace. **Sequencing:** We’ve **started** Zeaking-focused work so the compact layer is dependable at scale; **Phase 1** of the roadmap below is **done** in-tree. Next is **Phase 2** (ergonomics across surfaces), then performance/tests/DX as listed. **Wiring Nozy’s `OrchardWitnessProvider` to use `LwdCompactStore` for witness advancement** (instead of or as a fallback to `getblock` JSON) is **explicit planned core work** once we’re happy with the compact sync UX and semantics surfaced through Zeaking. ### Phase 1 — Reliability & clarity _(shipped)_ Phase 1 focused on **reliable compact sync** and **clearer errors at the boundaries** (Rust crate → HTTP companion → desktop → FFI → extension). **`zeaking` (crate)** - **`connect_lightwalletd`:** fixed a move-after-use bug by cloning the URI for the error path (`lwd/client.rs`). - **Streaming (`GetBlockRange`):** stream errors now go through **`map_grpc_status`** so callers get structured **gRPC `Status` (code / message)** instead of treating them like generic transport failures (`lwd/sync.rs`). - **Public API:** **`SyncCompactOptions`** , **`SyncCompactStats`** , **`sync_compact_range_with_options`** , and **`compact_sync_progress_height`** are re-exported from **`lwd/mod.rs`**. **Companion HTTP (`api-server`)** - **`POST /api/lwd/sync/compact`:** optional JSON body field **`resume`** (same semantics as **`SyncCompactOptions.resume_from_store`** ). - **Response:** **`range_start_requested`** , **`range_start_effective`** , **`range_end`** , **`blocks_written`** (replacing the old single **`range_start`** field). - **HTTP status mapping** (via **`zeaking_status`** ): **Grpc → 502** , **Storage → 500** , **InvalidOperation → 400**. **Desktop (Tauri)** - **`lwd_sync_compact`:** optional **`resume`** on the request struct. - **Response:** **`range_start_requested`** / **`range_start_effective`** / **`range_end`** (replacing **`range_start`** ). - **`zeaking_err`:** distinct codes **`LWD_GRPC`** , **`LWD_STORAGE`** , **`LWD_INVALID`** where applicable. **UniFFI (`zeaking-ffi`) — breaking for generated bindings** - **`lwd_sync_compact`:** new argument **`resume: Option`** (last parameter). - **`LwdSyncResultFfi`:** **`range_start`** replaced by **`range_start_requested`** and **`range_start_effective`**. **Regenerate Kotlin / Swift** after upgrading the dylib. **Browser extension** - Companion sync can pass **`resume: true`** from **`companion-api.js`** ; **`extensionApi.ts`** typings updated. - **Defaults stay safe:** **`resume`** is off unless explicitly set; **`sync_compact_range`** unchanged for callers that do not opt in. **How we validated** - `cargo build --workspace` - `cargo build` in `desktop-client/src-tauri` - `cargo test` - `cargo test -p zeaking --features lightwalletd` - `cargo fmt --all -- --check` ZecHub have an hackathon coming up Nozywallet will be a submission. Great time to show the community Nozy before submission in a retroactive grant, I still more work to do. ---
**Author:** ![dismad](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/dismad/32/18432_2.png) [@dismad](https://forum.zcashcommunity.com/u/dismad)\ **Post date:** [May 11, 2026, 2:28pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/12 "2026-05-11T14:28:44Z")
Love how you’re building in public, keep going 🥰 👏 🧑‍🎓 > [@Lowo88](#): > > ZecHub have an hackathon coming up Wonderful 🤩 ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [May 11, 2026, 5:13pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/13 "2026-05-11T17:13:42Z")
Thanks, I find it enjoyable. 😁 ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 4, 2026, 9:29am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/14 "2026-06-04T09:29:44Z")
Hello everyone, Following up on the [Phase 1 compact-sync post](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/11): Phase A1 of the dynamic-fee pilot is merged and tagged v2.3.0 (“Priority Lane”) — [PR #35](https://github.com/LEONINE-DAO/Nozy-wallet/pull/35) → `master` (main commit `0a4dea72`, merge `64b4b69c`). This is not mempool-driven fee markets yet. It is the Shielded Labs pilot shape implemented client-side: ZIP-317 conventional fees for Orchard sends, an opt-in priority multiplier, and a short expiry on built transactions. Zebrad still has no `estimatefee` RPC, so the old path effectively fell back to a flat 10,000 zat default — sends now use explicit ZIP-317 math instead. ### What shipped Core — `src/fee_policy.rs` - ZIP-317 marginal fee / grace-action math for typical Orchard-only sends - `PRIORITY_MULTIPLIER = 4` (opt-in; off by default) - `PILOT_EXPIRY_DELTA_BLOCKS = 2` (~2 minutes at current ~75s block times) - Fee policy lives in the nozy crate for now; moving shared logic into Zeaking is deferred until Shielded Labs gives the go-ahead Send path wired end-to-end (CLI, api-server, desktop) | Surface | Change | | --- | --- | | CLI | `nozy send --priority`; fee from `fee_policy`, not Zebrad `estimatefee` | | api-server | `priority` on send body; `GET /api/transaction/fee-estimate?priority=true | | Desktop (Tauri) | Send form priority toggle; Tauri passes `priority` + 2-block expiry into core build | | History | `SentTransactionRecord::new_pilot()` stores `priority` and `expiry_height` on sent txs | | Build | `transaction_builder` validates fee against ZIP-317 shape; `orchard_tx` sets `expiry_height = tip + expiry_delta` | Typical fee numbers (no memo, change output assumed) - Standard: 15,000 zats (3 logical actions × 5,000) - Priority (×4): 60,000 zats ### What this release does _not_ include yet Being explicit so expectations stay accurate: - Browser extension — still manual fee zats in the popup; no priority toggle or shared `fee_policy` wiring yet - Speed-up after expiry — rebuild at 4× fee is planned (Phase A), not in v2.3.0 - `Expired` tx status + balance release — history records expiry height, but automatic expired/unmined handling is next - Zeaking / compact-stream expiry detection — unchanged; pilot polling stays in nozy for now Details and remaining checklist: [`docs/rfcs/DYNAMIC_FEE_PHASE_A_IMPLEMENTATION.md`](https://github.com/LEONINE-DAO/Nozy-wallet/blob/master/docs/rfcs/DYNAMIC_FEE_PHASE_A_IMPLEMENTATION.md) and [`CHANGELOG.md`](https://github.com/LEONINE-DAO/Nozy-wallet/blob/master/CHANGELOG.md). ### How we validated - `cargo build --workspace` - `cargo test` (including `fee_policy` unit tests: grace minimum, 3-action send, priority ×4, memo logical actions) - Desktop Tauri build ### Where this fits in the roadmap - Phase 1 (compact sync / reliability) — shipped (previous post) - Phase A1 (fee pilot — core surfaces) — this release - Next: extension WASM alignment, expired-tx lifecycle + speed-up, then continued Zeaking witness work from the earlier roadmap ZecHub hackathon prep is a good forcing function — happy to demo Priority Lane on testnet before submission. Feedback welcome, especially on fee UX copy and whether the 2-block expiry feels right in practice. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 4, 2026, 4:43pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/15 "2026-06-04T16:43:50Z")
Zm Here’s the lates release for Nozywallet. [Release v2.3.0 — Priority Lane (CLI dynamic-fee pilot) · LEONINE-DAO/Nozy-wallet](https://github.com/LEONINE-DAO/Nozy-wallet/releases/tag/v2.3.0) ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 4, 2026, 6:32pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/16 "2026-06-04T18:32:47Z")
### Build in public — what we fixed recently We hit a real release-pipeline lesson: GitHub Actions releases created by the tag workflow **don’t automatically trigger** separate desktop/extension workflows. v2.3.0 initially went out with **CLI + API only** ; we fixed automation on `master` so future tags dispatch desktop + extension builds, and we backfilled **extension zips** on v2.3.0. Desktop installers may land on the same tag shortly — always check **Assets** on the release page rather than assuming `/releases/latest/download/...` URLs exist. If you’re packaging wallets or running CI yourself, happy to share what you learned. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 10, 2026, 9:41am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/17 "2026-06-10T09:41:15Z")
# : NozyWallet update — v2.3.3 “Teriyaki Hot” (NU6.2 mainnet + fee pilot fixes) Hello everyone, Following up on [v2.3.0 “Priority Lane”](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/11) and our first mainnet sends after NU6.2: we hit real issues in the field, fixed them, and shipped v2.3.3 “Teriyaki Hot” on `master`. Huge thanks to @aphelionz for the three community PRs below — all merged June 10 after mainnet testing. ### What we learned on mainnet (why these PRs exist) After Priority Lane landed, we ran real Orchard sends against a NU6.2 Zebrad node. Three problems showed up immediately: 1. Transactions rejected — wrong consensus branch ID (`-25 incorrect consensus branch id`) 2. Transactions expiring unmined — 2-block expiry was too tight for mainnet block times 3. Priority fee overpaying — ZIP-317 action count was wrong (billed 3 actions instead of 2) We also found a wallet-side spend-detection bug that could re-select already-spent notes on a second send — fixed in [#61](https://github.com/LEONINE-DAO/Nozy-wallet/pull/61) before the v2.3.3 tag. * * * ### PR #58 — NU6.2 librustzcash dependency bump [PR #58](https://github.com/LEONINE-DAO/Nozy-wallet/pull/58) → merge `29a86697` Problem: NU6.2 is active on mainnet, but our pinned `zcash_primitives` 0.26 / `zcash_protocol` 0.7 predate NU6.2. `BranchId::for_height()` returned the NU6.1 branch ID (`0x4dec4df0`), so Zebrad rejected every Orchard send with “incorrect consensus branch id” (RPC code `-25`). Fix: Bump to the NU6.2 release set: - `orchard` 0.14, `zcash_primitives` 0.28, `zcash_protocol` 0.9, `zcash_address` 0.12, `zcash_proofs` 0.28, `zcash_transparent` 0.8 - Add standalone `zip32` crate (`zcash_primitives` 0.28 dropped the re-export) Result: Shielded Orchard sends go from rejected → accepted and mined (branch ID `0x5437f330`). * * * ### PR #59 — Raise default tx expiry from 2 → 5 blocks [PR #59](https://github.com/LEONINE-DAO/Nozy-wallet/pull/59) → merge `e929c8e9` Problem: `PILOT_EXPIRY_DELTA_BLOCKS = 2` (~2.5 min) was too aggressive on mainnet. Sends that didn’t mine within ~2 blocks expired and were dropped unmined. Fix: Default expiry raised to 5 blocks (~6 min at ~75s/block). One-line change in `src/fee_policy.rs`. Result: Same send that expired at delta=2 mined successfully at delta=5. * * * ### PR #60 — Correct Orchard action counting for ZIP-317 fees [PR #60](https://github.com/LEONINE-DAO/Nozy-wallet/pull/60) → merge `3abc9aac` Problem: `fee_policy` counted Orchard actions as `spends + outputs` (additive). A typical 1-spend, 2-output send (recipient + change) is `max(1, 2) = 2` actions, not 3. Priority sends were overpaying: | | Bug (v2.3.0) | Correct (after #60) | | --- | --- | --- | | Logical actions | 3 | 2 | | Standard fee | 15,000 zats | 10,000 zats | | Priority fee (×4) | 60,000 zats | 40,000 zats | | Fee per action (priority) | 30,000 | 20,000 (true 4×) | Fix: Count `orchard_actions = max(spends, outputs)`. Updated unit tests to match. * * * ### Also in v2.3.3 — PR #61 spend detection [PR #61](https://github.com/LEONINE-DAO/Nozy-wallet/pull/61) (LEONINE-DAO) Compact-block discovery was storing action nullifiers that don’t match the real note nullifier, so `mark_note_spent` never matched and spent inputs could be re-selected on a second send. Fix: Derive canonical nullifiers at discovery via `note.nullifier(fvk)`, persist `rho`/`rseed` for recompute, mark spends when scanning on-chain action nullifiers, and record canonical nullifiers on broadcast. * * * ### Current state on `master` (v2.3.3) | Item | Status | | --- | --- | | NU6.2 consensus / proofs | ✅ [#58](https://github.com/LEONINE-DAO/Nozy-wallet/pull/58) | | Mainnet send expiry window | ✅ 5 blocks [#59](https://github.com/LEONINE-DAO/Nozy-wallet/pull/59) | | ZIP-317 fee math | ✅ 10k standard / 40k priority [#60](https://github.com/LEONINE-DAO/Nozy-wallet/pull/60) | | Spend detection | ✅ [#61](https://github.com/LEONINE-DAO/Nozy-wallet/pull/61) | | README / docs refresh | ✅ NU6.2 stack, fee policy, WSL sync workflow | Repo: [LEONINE-DAO/Nozy-wallet](https://github.com/LEONINE-DAO/Nozy-wallet) (`master`, `Cargo.toml` version 2.3.3) Typical Orchard send fees (1 spend + change, no memo): - Standard: 10,000 zats - Priority (opt-in ×4): 40,000 zats - Expiry: tip + 5 blocks * * * ### What’s still next (unchanged from roadmap) - Browser extension: priority toggle + shared `fee_policy` wiring - Speed-up after expiry (rebuild at 4× fee) — Phase A, not shipped yet - Automatic `Expired` tx status + balance release - Continued Zeaking witness / compact-sync work * * * ### Honest note on the fee pilot This is still client-side ZIP-317 with an opt-in 4× multiplier — not live mempool congestion pricing. The pilot shape from Shielded Labs is implemented; we’re now tuning it against real mainnet behavior (expiry window, action counting, NU6.2 compatibility). Feedback welcome — especially if you’re running Zebrad + Nozy on mainnet and seeing different expiry or fee behavior. — Lowo88 / LEONINE DAO ---
**Author:** ![gilmore](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/gilmore/32/45342_2.png) [@gilmore](https://forum.zcashcommunity.com/u/gilmore)\ **Post date:** [June 10, 2026, 2:35pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/18 "2026-06-10T14:35:56Z")
@Lowo88 Just got back from vacation and pulled the latest Nozy changes. Successfully built v2.3.3 on my end and I’m currently setting up my VPS to install Zebra and test Nozy Wallet against my own node. Appreciate all the work that’s gone into these fixes. ![● ~_zingolib_target_release_zingo-cli • Untitled-1 - ctrs - Copy - Visual Studio Code 6_10_2026 3_26_24 PM](https://global.discourse-cdn.com/zcash/original/3X/a/a/aa177cd4fff5b4fa3a17aa40b3408ba63df0839e.png) ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 10, 2026, 4:11pm UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/19 "2026-06-10T16:11:03Z")
Let’s go! Hope everything works out good. ---
**Author:** ![Lowo88](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lowo88/32/37996_2.png) [@Lowo88](https://forum.zcashcommunity.com/u/Lowo88)\ **Post date:** [June 11, 2026, 2:01am UTC](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745/20 "2026-06-11T02:01:24Z")
Hi everyone, Short follow-up on today work for Nozy to our NU6.2 / Shielded Lab update: we shipped NozyWallet v2.3.4 — Send Select and confirmed a mainnet shielded send from a multi-note wallet. Release: [Release v2.3.4 —Teriyaki Hot ( Send select ) · LEONINE-DAO/Nozy-wallet · GitHub](https://github.com/LEONINE-DAO/Nozy-wallet/releases/tag/v2.3.4) ## Context v2.3.3 merged the NU6.2 stack and related send fixes (#58–#61): - NU6.2 librustzcash bump (#58) - 5-block transaction expiry (#59) - ZIP-317 fee: `max(spends, outputs)` (#60) - Canonical nullifiers / spend detection (#61) After syncing to tip, sends got past branch ID and proving — but with multiple Orchard notes in the wallet, zebrad still rejected the transaction: > `IncorrectFee` — could not calculate the transaction fee (code `-25`) That pointed to a coin-selection bug, not NU6.2 or ZIP-317. ## What was wrong `build_single_spend` computed change using the total value of all spendable notes, but only spent the first note. With more than one note, inputs and outputs didn’t balance, so the node reported IncorrectFee. ## What v2.3.4 fixes Orchard single-note coin selection (`select_single_spend_note`): - Pick the smallest note that covers `amount + fee` - Compute change from that note only - Build the transaction so value balances correctly Codename: Send Select ## Verified on mainnet Local stack: zebrad + lightwalletd (WSL), Nozy CLI v2.3.4 (Windows). | Step | Outcome | | --- | --- | | `nozy sync --to-tip` | OK | | Multi-note wallet (3 notes) | OK | | Shielded send build + prove + sign | OK | | Broadcast to zebrad | OK | | Fee | 10,000 zats (ZIP-317) | So for Zebra/lightwalletd users on NU6.2 mainnet: NU6.2 dependency alignment (#58–#61) is necessary, but wallets with multiple Orchard notes also need correct single-note selection at spend time — otherwise `-25 IncorrectFee` can still show up after sync looks healthy. ## Upgrade - GitHub release assets (CLI / desktop / extension when CI finishes): [Release v2.3.4 —Teriyaki Hot ( Send select ) · LEONINE-DAO/Nozy-wallet · GitHub](https://github.com/LEONINE-DAO/Nozy-wallet/releases/tag/v2.3.4) - From source (repo root): `cargo build --release -p nozy` → `target/release/nozy` - Run `nozy sync --to-tip` before sending ## What’s next - More Shielded Lab pilot testing on mainnet - Continue aligning desktop + extension on the same stack - Clean up repo hygiene (e.g. broken submodule blocking `cargo install --git`) Feedback and reproduction reports welcome on GitHub. — LEONINE-DAO / NozyWallet contributors Links - Release: [Release v2.3.4 —Teriyaki Hot ( Send select ) · LEONINE-DAO/Nozy-wallet · GitHub](https://github.com/LEONINE-DAO/Nozy-wallet/releases/tag/v2.3.4) - Repo: [GitHub - LEONINE-DAO/Nozy-wallet: NozyWallet is a Orchard wallet built for Zebrad, delivering the highest level of Zcash privacy through fully-shielded transactions and cutting-edge cryptographic security. Built in Rust with support for Orchard shielded transactions, it provides complete financial privacy with secure key management and seamless integration with the Zcash ecosystem. · GitHub](https://github.com/LEONINE-DAO/Nozy-wallet) - Prior NU6.2 update: #58–#61 on `master` Thank you and Happy Coding. 😁 [Next page](https://forum.zcashcommunity.com/t/nozywallet-development-roadmap/53745.md?page=2)