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.