NozyWallet Development Roadmap

Zcash Apps
1

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) 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

  • 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:

    • Tor proxy support (already implemented)
    • I2P integration (already implemented)
    • Privacy-focused network routing
    • Crosslink

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)

    • Core swap orchestration logic
    • Privacy validation system
    • Address generation and reuse prevention
    • Monero churning integration
    • ZK proof verification framework

  2. Swap Service Client (src/swap/service.rs)

    • Privacy network integration (Tor/I2P)
    • API client with rate monitoring
    • Swap initiation and tracking
    • Response caching system

  3. Swap Storage (src/bridge/swap_storage.rs)

    • Persistent swap history
    • Swap state management
    • Transaction tracking

  4. Privacy Infrastructure

    • Privacy validator (src/bridge/privacy_validator.rs)
    • Address tracker (src/bridge/address_tracker.rs)
    • Churn manager (src/bridge/churn.rs)
    • Monero ZK verifier integration

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)

    • LCD (Light Client Daemon) integration
    • Balance queries (SCRT native token)
    • Transaction queries
    • Block height queries
    • Privacy network proxy support (Tor/I2P)

  2. SNIP-20 Token Support (src/secret/snip20.rs)

    • SNIP-20 token interface
    • Token balance queries
    • Token info retrieval
    • Shade Protocol token support (SHD, SILK, etc.)
    • Encrypted balance viewing

  3. Secret Network Wallet (src/secret/wallet.rs)

    • High-level wallet interface
    • Balance management (SCRT + tokens)
    • Address validation
    • Transaction history tracking

  4. HD Wallet Key Derivation (src/secret_keys.rs)

    • BIP44 key derivation (coin type 529)
    • Secret Network address generation
    • Bech32 address encoding
    • HD wallet integration

  5. Transaction Management

    • Transaction history storage
    • Transaction status tracking
    • Encrypted transaction queries

What’s Getting Working On Now

  1. Private Smart Contract Interactions

    • Status: Query interface ready, enhancing execution
    • Goal: Full private smart contract interaction support
    • Features:
      • Encrypted contract queries
      • Private transaction execution
      • Viewing key management
      • Contract state encryption/decryption

  2. Shade Protocol Integration

    • Status: Token support implemented, enhancing DEX features
    • Goal: Full Shade Protocol DEX integration
    • Features:
      • Swap functionality (SHD, SILK, etc.)
      • Liquidity pool interactions
      • Yield farming integration
      • Governance participation

  3. Enhanced HD Wallet Integration

    • Status: Basic derivation working, enhancing features
    • Goal: Seamless multi-chain key management
    • Features:
      • Unified key derivation across chains
      • Address book integration
      • Multi-account support
      • Key export/import

  4. Transaction Building & Signing

    • Status: Framework in place, implementing signing
    • Goal: Complete transaction lifecycle
    • Features:
      • Transaction construction
      • Private key signing
      • Transaction broadcasting
      • Confirmation tracking

Technical Implementation

Secret Network Architecture:

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

    • Testing swap flows end-to-end
    • Secret Network contract interactions
    • Privacy network reliability

  2. Error Handling

    • Robust error recovery
    • User-friendly error messages
    • Transaction retry logic

  3. Performance Optimization

    • Rate caching efficiency
    • Query optimization
    • Network latency reduction

  4. User Experience

    • CLI interface improvements
    • Progress indicators
    • Status notifications

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

  • 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 :sweat_smile:

2

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

1 Like
3

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.

1 Like
4

Ok, Thanks for this feedback this all useful

Should I focus on this more??

5

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.

1 Like
6

Ok got it in my computer algorithms class I’m learning about inverted files/indexing good timing.

7

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.

8

More wallet options = healthier ecosystem :flexed_biceps: We faced similar sync tradeoffs building ZChat (shielded messenger). User needs vs node purity is real.

Keep shipping! :rocket:

1 Like
9

Let’s go! Good luck on your submission, I’ll adopt ZChat for Nozywallet pure community build.

10

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.

11

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<bool> (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.

1 Like
12

Love how you’re building in public, keep going :smiling_face_with_three_hearts: :clap: :student:

Wonderful :star_struck:

13

Thanks, I find it enjoyable. :grin:

14

Hello everyone,

Following up on the Phase 1 compact-sync post: Phase A1 of the dynamic-fee pilot is merged and tagged v2.3.0 (“Priority Lane”) — PR #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 and 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.

2 Likes
15

Zm

Here’s the lates release for Nozywallet.
Release v2.3.0 — Priority Lane (CLI dynamic-fee pilot) · LEONINE-DAO/Nozy-wallet

16

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.

17

: NozyWallet update — v2.3.3 “Teriyaki Hot” (NU6.2 mainnet + fee pilot fixes)

Hello everyone,

Following up on v2.3.0 “Priority Lane” 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 before the v2.3.3 tag.

PR #58 — NU6.2 librustzcash dependency bump

PR #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 → 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 → 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 (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 :white_check_mark: #58
Mainnet send expiry window :white_check_mark: 5 blocks #59
ZIP-317 fee math :white_check_mark: 10k standard / 40k priority #60
Spend detection :white_check_mark: #61
README / docs refresh :white_check_mark: NU6.2 stack, fee policy, WSL sync workflow

Repo: 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

18

@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
● ~_zingolib_target_release_zingo-cli • Untitled-1 - ctrs - Copy - Visual Studio Code 6_10_2026 3_26_24 PM2472×1401 231 KB

2 Likes
19

Let’s go! Hope everything works out good.

1 Like
20

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

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

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

Thank you and Happy Coding. :grin:

1 Like