Introduction

NozyWallet is a privacy-first Zcash wallet for shielded Orchard and Ironwood (NU6.3)—so every send and receive is private by default.

For the full picture—what Nozy is, why it exists, and how it’s designed—read the Nozy section chapter by chapter:

• What is Nozy? — One-sentence definition and why it exists
• Purpose — What Nozy is for (and not for)
• Identity — What Nozy is and isn’t
• Philosophy — Design principles
• Privacy model — How privacy works in practice
• Why Ironwood? — Taylor Hornby’s Orchard finding, supply soundness, and why Nozy migrates

Then head to Getting Started to install and create your first wallet.

What is Nozy?

NozyWallet is a privacy-first Zcash wallet for the Orchard and Ironwood (NU6.3) shielded pools. It focuses on making every transaction private by default and removing the choice—or the mistake—of using transparent addresses.

In one sentence

NozyWallet is a Zcash wallet designed around your own Zebrad node, with shielded-only transactions (Orchard today, Ironwood after NU6.3) and no transparent support—Monero-level privacy on the ledger, with a stack you can verify instead of a vendor you must trust.

Why it exists

Most Zcash wallets support both transparent and shielded transactions. That flexibility means users can accidentally leak information on the chain. Nozy removes that risk: you cannot send or receive on transparent addresses.

But ledger privacy and infrastructure privacy are not the same thing. Orchard and Ironwood hide sender, receiver, and amount from the public blockchain. A third-party node operator can still learn when you sync, when you broadcast, and often which IP asked—unless you control the node yourself. Nozy is built for people who want both: cryptographic privacy on-chain and minimal trust off-chain.

Two layers of privacy

Orchard and Ironwood give you the first layer. Running your own Zebrad node is how you take the second layer seriously.

Why running your own node matters

When you use someone else’s RPC—an exchange, a hosted wallet backend, a random public endpoint—they do not need your seed to learn a lot about you. They typically see:

• Your IP address (or VPN exit) when you connect
• When you sync and when you broadcast transactions
• Chain queries tied to your session (block ranges, treestate fetches, mempool traffic)

That is not the same as reading your Orchard notes—they usually cannot decrypt shielded amounts from the chain alone. It is metadata that can correlate your activity, throttle you, log you, or feed analytics. In the worst case, a malicious RPC could try to serve a wrong chain tip or censor your broadcasts.

Your own Zebrad node changes the trust model:

1. You verify the chain — You are not asking a company “what is the current history?” You run consensus software and validate blocks yourself.
2. You shrink the observer — Sync and broadcast metadata stay between your wallet and your machine (or your VPS), not a stranger’s logs.
3. You align with how Nozy spends — Orchard witnesses are derived locally from treestate your wallet obtains over RPC. With your node, that path does not depend on a hosted service’s honesty for spend readiness. See Zebra Node Setup and the Zebrad connectivity guide.

What your own node does not magically fix (so the statement stays true):

• Ledger privacy still comes from Orchard / Ironwood math, not from Zebrad alone.
• Network identity — Your node still talks to the P2P network; use Tor/VPN if you need IP-level hiding (Privacy Networks).
• lightwalletd — If you use a remote lightwalletd for compact sync, that service can see which block ranges you request. Prefer local lightwalletd paired with your Zebrad, or accept that trade-off.
• Recipients, exchanges, and OPSEC — KYC, address reuse, and device compromise are separate from node choice.

Nozy’s honest claim: self-hosted Zebrad is the recommended way to get full-stack privacy—not an optional power-user tweak.

The Cypherpunk idea

In 1993, Eric Hughes wrote the Cypherpunk Manifesto. It is not about aesthetics; it is about who must build privacy:

Privacy is necessary for an open society in the electronic age.
Privacy is the power to selectively reveal oneself to the world.
We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.
Cypherpunks write code. We know that someone has to write software to defend privacy…

Nozy sits in that tradition:

• Code, not permission — Shielded-by-default wallet logic instead of “please don’t log my transparent send.”
• Selective revelation — You choose who sees your balance (you); the chain does not broadcast amounts or addresses in the clear.
• Skepticism of benevolent intermediaries — Keys stay on your device; the node you run (or explicitly trust) replaces an opaque hosted backend.

We are not relics of the 1990s—Orchard, Ironwood, and Zebrad are modern—but the threat model is the same: if you want privacy in an open society, you build systems that do not require trusting strangers with your financial metadata.

More in Manifesto and Philosophy.

What you get

• Shielded-only — Every send and receive uses Orchard / Ironwood; no transparent t-addresses.
• Zebrad-first — Built for JSON-RPC to your full node; local shielded witness derivation (not “trust the server’s witness”).
• Ironwood-ready — NU6.3 migrate / split / broadcast tooling so Orchard notes move into the Ironwood pool after activation. Newcomers: Why Ironwood?.
• Self-custodial — Mnemonic and keys stay on your device; no custodian can move your funds.
• Verifiable stack — Open source wallet + open source node; you can audit what runs, not just what marketing claims.
• Multi-surface — Desktop (Tauri), CLI, api-server companion, and mobile FFI—one Rust core, same privacy stance.

Optional compact sync via lightwalletd (Zeaking) exists for extension and fast catch-up; Zebrad remains the trust anchor for tip, broadcast, and treestate.

Next: Purpose — what Nozy is for.

Purpose

The blockchain is transparent by default. Most wallets mirror that: they show balances, addresses, and history in the open and leave privacy as an option for nozy people.

Nozy does the opposite. It assumes privacy is the goal and enforces it.

What Nozy is for

Its purpose is to give you a Zcash wallet where:

• Privacy is default — You don’t have to “remember” to use shielded; it’s the only option.
• Mistakes are hard — You can’t accidentally send to a transparent address or expose amounts.
• Trust is minimal — You hold the keys. For ledger privacy, Orchard does the work. For infrastructure privacy, run your own Zebrad so sync and broadcast metadata are not logged by a stranger’s RPC.

Nozy is built for people who want Zcash to behave like a privacy coin: fast, cheap, SOV and private every time.

What it is not for

Nozy is not for:

• Transparent (t-address) sends or receives
• Exchanges or services that only support t-addresses
• Users who need transparent-first or pre-Orchard shielded-only tooling

For those cases, use a wallet that supports transparent or legacy flows. (e.g.; Zashi, Zkool, Zingo)

Next: Identity — what Nozy is and isn’t.

Identity

NozyWallet is a privacy-first Zcash wallet that shows you what you need: your balance, ZEC price, and your private transactions. Today it’s a wallet; over time it will add swaps and other features—all built on the same foundation: shielded-only, self-custodial ZEC.

What Nozy is

• A wallet — Create and restore wallets, manage Orchard addresses, send and receive ZEC.
• Privacy-first — Shielded-only; no transparent addresses, no optional privacy.
• Zebra-first — Designed to work with a Zebrad node you run or explicitly trust; local witness derivation for shielded spends.
• Self-custodial — Your seed and keys stay on your device; the API server does not see them.
• Price-aware — ZEC price is shown so you know the value of your holdings; trading features are planned.

It is built to sit next to your ZEC, keep it private, and let you move it—or later, trade it—when you decide, without leaking who you are, who you pay, or how much.

What Nozy is not

• Not a mixer — It doesn’t mix other people’s coins; it keeps your own activity shielded.
• Not a custodial service — You hold the keys; no one else can move your funds or see your balance.
• Not a social or signal product — No groups, no tips, no public profiles; focus stays on your private ZEC.

Everything about it is built for private, self-custodial ZEC—with price visibility today and more features to come.

Next: Philosophy — how Nozy is designed.

Philosophy

Nozy is built on a few principles that shape every feature and default.

Privacy is not optional

If the wallet can do something that leaks information, that path is removed. Transparent addresses are not supported. There is no “use shielded when you remember”—shielded is all the wallet does. The goal is to make the private path the only path.

The server should learn as little as possible

The wallet is designed so keys and decryption stay on your device. When you use a remote RPC or api-server, that operator can still see connection metadata—timestamps, IPs, broadcast timing—even if they cannot read your Orchard notes. Running your own Zebrad is how you align infrastructure with the same minimal-trust goal.

For chain data and broadcast, the remote party should not need your password, your keys, or your balance. The client does decryption, scanning, and proving; a dumb RPC only serves blocks and accepts signed transactions you choose to submit. That keeps the threat model small and keeps you in control.

See Privacy model for the full on-chain vs off-chain split.

Complexity should stay under the hood

Orchard, zero-knowledge proofs, and sync are complex. The interface should not be. Nozy aims for clear flows: create/restore wallet, see balance, send, receive, backup. Advanced options exist for those who need them, but the default path is simple.

Open and auditable

NozyWallet is open-source. You can see how it handles keys, how it talks to Zebra, and how it builds transactions. Documentation and code are there so you can verify what the wallet does instead of trusting a slogan.

Next: Privacy model — how privacy works in practice.

Privacy model

Nozy’s privacy has two parts: what the chain hides, and what your infrastructure might still leak.

What Orchard / Ironwood hide (on-chain)

• Sender — Your address and identity are not visible on the chain.
• Receiver — The recipient’s address is hidden.
• Amount — The value of the transaction is hidden.
• Linkability — Observers cannot tie transactions together from ledger data alone.

Zero-knowledge proofs let the network verify validity without learning who sent, who received, or how much. Ironwood (NU6.3) continues that model in a new shielded pool; Nozy migrates Orchard notes via turnstile Plan / Split / Migrate / Broadcast.

What a third-party node can still see (off-chain)

Even with perfect Orchard / Ironwood math, a remote RPC operator is not blind to you as a user. They may log:

That is why the privacy model treats your own Zebrad as part of the product—not an advanced appendix. Hosted RPC is a convenience trade-off, not maximum privacy.

How Nozy keeps ledger privacy strong

• Shielded-only — No transparent addresses; no accidental public sends.
• Orchard + Ironwood — Current and next shielded pools; no legacy transparent-first flows.
• Local cryptography — Decryption, scanning, and proving on your device; keys are not sent to a server for spending.
• Local witnesses — Shielded spend witnesses are derived on the wallet using treestate from RPC—not served as a trusted “witness API” by the node. Your node supplies facts about the chain; your wallet supplies secrets.

How you complete the model (operator checklist)

For the statement “I have true privacy” to hold in practice—not just on paper:

1. Run Zebrad you control (home, VPS, or WSL you operate). Point Nozy at it: Zebra Node Setup.
2. Verify connectivity — nozy test-zebra before sync or send.
3. Sync to tip before spending — stale witnesses block send and increase risk.
4. Prefer local lightwalletd if you use compact sync; avoid remote LWD you do not trust.
5. Network layer — Tor/VPN if hiding your IP from the P2P/RPC path matters (Privacy Networks).
6. Address hygiene — New receive addresses when linkability matters.
7. Backup mnemonic offline — Privacy is meaningless if you lose funds or leak the seed.

What Nozy does not promise

• Invisibility from nation-state adversaries without broader OPSEC.
• Privacy if you paste your seed into a website or use a compromised machine.
• Protection from a malicious recipient who knows you paid them.
• Anonymity if you voluntarily KYC at an exchange and withdraw to a known identity.

The model is: strong ledger privacy by design, plus infrastructure privacy when you run your own node and practice basic hygiene.

Cypherpunk framing

Privacy is selective revelation (Cypherpunk Manifesto). Orchard handles revelation to the network (minimal). You choose revelation to people (recipient). Your node choice controls revelation to operators. Nozy removes the “transparent by mistake” path; you remove the “someone else’s server watches me” path.

For more detail, see Absolute Privacy, Security best practices, and Zebrad connectivity.

Next: Manifesto — principles in brief — or Getting started.

NozyWallet Manifesto

NozyWallet is a privacy-first Zcash wallet: shielded Orchard only, self-custodial keys, and a stack meant to run against infrastructure you control—starting with your own Zebrad node.

Cypherpunks write code

The Cypherpunk Manifesto (Eric Hughes, 1993) argued that privacy in the electronic age will not be handed down by governments or corporations. It must be built:

• Privacy is the power to selectively reveal oneself to the world.
• We must defend our own privacy if we expect to have any.
• Cypherpunks write code.

NozyWallet is an attempt to live up to that—not as nostalgia, but as engineering:

“Cypherpunk” (with a y) is the movement for cryptography and privacy tools. It is not the same as the “cyberpunk” sci-fi aesthetic—though both distrust centralized control.

Freedom is privacy

On a transparent blockchain, the world sees your graph. On Orchard, the math hides the graph—but your RPC provider can still watch you use the wallet unless you run your own node.

Nozy’s stance:

1. On-chain: No transparent escape hatch. Shielded-only.
2. Off-chain: Zebrad-first. Learn to operate your node; verify with nozy test-zebra.
3. Culture: Read the manifesto. Understand what you’re defending. Then backup your seed.

If I say something, I want it heard only by those for whom I intend it.
— Cypherpunk Manifesto

Your transaction intent should not be a free feed for every RPC operator on the internet.

View the NozyWallet codebase on GitHub →

Next: Getting started — or What is Nozy? for the full node + privacy model.

Installation

NozyWallet can be installed in several ways depending on your needs and technical level.

Desktop Application (Recommended for Most Users)

The easiest way to use NozyWallet is through our desktop application, which provides a beautiful graphical interface.

Windows

1. Download the latest installer from GitHub Releases
2. Run the .exe installer
3. Follow the installation wizard
4. Launch NozyWallet from your Start menu

macOS

1. Download the latest .dmg file from GitHub Releases
2. Open the .dmg file
3. Drag NozyWallet to your Applications folder
4. Launch NozyWallet from Applications

Linux

1. Download the latest .AppImage or .deb package from GitHub Releases
2. For .deb packages: sudo dpkg -i nozywallet_*.deb
3. For .AppImage: Make it executable and run:

   chmod +x NozyWallet-*.AppImage
   ./NozyWallet-*.AppImage
   

Command-Line Interface (CLI)

For advanced users, developers, or automated systems, you can use the CLI version.

Prerequisites

• Rust 1.70+ - Install from rustup.rs
• Zebra-family RPC node — Zebrad or Zakura on http://127.0.0.1:8232 (or configure a custom URL). See Zebra Node Setup or Zakura Node Setup.

Build from Source

# Clone the repository
git clone https://github.com/LEONINE-DAO/Nozy-wallet.git
cd Nozy-wallet

# Build the release version
cargo build --release

# The binary will be in target/release/nozy (or nozy.exe on Windows)

Install with Cargo

# Install directly from GitHub
cargo install --git https://github.com/LEONINE-DAO/Nozy-wallet.git

# Or install from a local clone
cd Nozy-wallet
cargo install --path .

Setting Up Zebra Node

NozyWallet requires a connection to a Zebra RPC node to interact with the Zcash blockchain.

Option 1: Use Public Node (Easiest)

NozyWallet can connect to a public Zebra node. Configure the node URL in your wallet settings:

• Default: http://127.0.0.1:8232
• Public node: https://zec.leoninedao.org:443 (if available)

Option 2: Run Your Own Node (Most Private)

For maximum privacy, run your own Zebra node:

# Install Zebra (Zcash Foundation's node implementation)
# See: https://zebra.zfnd.org/user/install.html

# Run Zebra with RPC enabled
zebrad start --rpc-bind-addr 127.0.0.1:8232

Verifying Installation

After installation, verify everything works:

Desktop App

1. Launch NozyWallet
2. The setup wizard should appear
3. You're ready to create your first wallet!

CLI

# Check version
nozy --version

# Check if wallet exists
nozy status

# If no wallet, create one
nozy new

Next Steps

Once installed, proceed to Creating Your First Wallet to get started!

Creating Your First Wallet

This guide walks you through creating your first NozyWallet.

Desktop App (Recommended)

Step 1: Launch NozyWallet

After installation, launch NozyWallet from your applications menu.

Step 2: Setup Wizard

The setup wizard will guide you through:

1. Welcome screen - Introduction to NozyWallet
2. Create new wallet - Choose to create a new wallet
3. Password setup - Set a strong password (optional but recommended)
4. Address generation - Generate your first receiving address
5. Complete - You're ready to use NozyWallet!

Step 3: Backup Your Seed Phrase

CRITICAL: You will be shown your 24-word mnemonic phrase. This is the ONLY way to recover your wallet if you lose access.

⚠️ SECURITY WARNING:

• ✅ Write it down on paper (never digitally)
• ✅ Store in a secure location (fireproof safe, bank deposit box)
• ✅ Never share it with anyone
• ✅ Never take screenshots or photos
• ✅ Never store online (cloud, email, notes apps)
• ✅ Make multiple copies in different secure locations

Step 4: Generate Your First Address

After creating your wallet, generate your first receiving address:

• Click "Receive" in the desktop app
• Your Orchard address will be displayed
• You can copy it or show a QR code

CLI (Command Line)

Step 1: Create Wallet

nozy new

Step 2: Follow Prompts

You'll be asked:

1. Create new wallet? - Type y to confirm
2. Set password? - Type y to set a password (recommended)
3. Enter password - Type your password (hidden)
4. Confirm password - Type again to confirm

Step 3: Save Your Mnemonic

CRITICAL: Your 24-word mnemonic phrase will be displayed.

Example output:

Creating new wallet...
Wallet created successfully!

**CRITICAL SECURITY WARNING: MNEMONIC BACKUP**

Your mnemonic phrase is the ONLY way to recover your wallet.
If you lose it, you will PERMANENTLY lose access to all your funds.

Your 24-word mnemonic phrase:
abandon abandon abandon ... [24 words total - KEEP THIS SECURE!]

Set password protection? (y/n): y
Enter password: ********
Confirm password: ********
Password set successfully

Generated Orchard address:
u1testaddress1234567890abcdefghijklmnopqrstuvwxyz...

Step 4: Generate Addresses

# Generate a single address
nozy addresses

# Generate multiple addresses
nozy addresses --count 5

What Happens Next?

After creating your wallet:

1. ✅ Wallet file created - Stored securely on your device
2. ✅ First address generated - Ready to receive ZEC
3. ✅ Ready to use - You can now send and receive

Next Steps

• Send ZEC - Send your first transaction
• Receive ZEC - Learn about receiving
• Backup & Recovery - Secure your wallet

Troubleshooting

Wallet Already Exists

If you see "Wallet already exists" error:

• You already have a wallet created
• Use nozy status to check wallet info
• Use nozy restore to restore from seed phrase

Password Issues

• Forgot password: You can restore from seed phrase (password will be reset)
• Wrong password: Double-check your password
• Password too weak: Use a stronger password with mixed characters

Security Reminders

⚠️ Remember:

• Your mnemonic phrase is your wallet - protect it!
• Your password protects the wallet file - use a strong one
• Never share your mnemonic or password with anyone
• Store backups in secure, offline locations

Restoring from Seed Phrase

If you've lost access to your wallet or need to restore it on a new device, you can restore your wallet using your 24-word mnemonic phrase.

Before You Start

Required:

• ✅ Your 24-word mnemonic phrase (seed phrase)
• ✅ Secure location to restore the wallet

⚠️ CRITICAL SECURITY WARNING:

Your mnemonic phrase is the ONLY way to recover your wallet. Never:

• ❌ Share it with anyone
• ❌ Store it digitally (screenshots, cloud, email, notes apps)
• ❌ Enter it on any website
• ❌ Lose or destroy it

Desktop App

Step 1: Launch NozyWallet

Open the NozyWallet desktop application.

Step 2: Select Restore

In the setup wizard:

1. Click "Restore from Seed Phrase" or "Import Wallet"
2. You'll be prompted for your mnemonic phrase

Step 3: Enter Your Mnemonic

1. Enter all 24 words - Type each word carefully
2. Verify spelling - Each word must be spelled correctly
3. Check order - Words must be in the correct order
4. Use spaces - Separate words with spaces

Step 4: Set Password

After entering your mnemonic:

1. Set a new password (optional but recommended)
2. Confirm password
3. Click "Restore Wallet"

Step 5: Wait for Restoration

The wallet will:

• Generate all keys from your mnemonic
• Restore your wallet file
• Prepare addresses for use

CLI (Command Line)

Step 1: Run Restore Command

nozy restore

Step 2: Enter Mnemonic

You'll be prompted to enter your 24-word mnemonic phrase:

Enter your 24-word mnemonic: abandon abandon abandon ... [enter all 24 words]

Tips:

• Enter all 24 words on one line, separated by spaces
• Double-check spelling before pressing Enter
• Common mistakes: typos, missing words, wrong order

Step 3: Set Password

After entering your mnemonic:

Enter password to encrypt wallet: [enter password]
Confirm password: [enter again]

Step 4: Wait for Completion

Expected output:

Restore wallet from mnemonic...
✅ Wallet restored and saved.

Your wallet is now restored and ready to use!

Troubleshooting

"Invalid mnemonic" Error

Problem: The mnemonic phrase is invalid.

Solutions:

1. Check spelling - Verify each word is spelled correctly
2. Verify word count - Must be exactly 24 words
3. Check order - Words must be in the original order
4. Verify BIP39 words - All words must be from the BIP39 word list

Common mistakes:

• Missing words (23 words instead of 24)
• Extra words (25+ words)
• Typos (e.g., "abandn" instead of "abandon")
• Wrong order (words swapped)

"Wallet already exists" Error

Problem: A wallet already exists at the default location.

Solutions:

1. Backup existing wallet - Move it to a safe location first
2. Delete existing wallet - Only if you're sure it's not needed
3. Use different location - Specify a custom wallet path (if supported)

"Invalid checksum" Error

Problem: The mnemonic phrase has a checksum error, meaning one or more words are incorrect.

Solutions:

1. Double-check each word - Verify spelling and order
2. Use word list - Check against BIP39 word list if unsure
3. Re-verify source - Make sure you copied from the correct backup

After Restoration

Once your wallet is restored:

1. ✅ Verify addresses - Generate addresses and verify they match (if you had previous addresses)
2. ✅ Check balance - Sync wallet to see your balance
3. ✅ Backup again - Save your mnemonic phrase again in a new secure location
4. ✅ Update password - If needed, change to a new password

Security Best Practices

After Restoring

1. Verify the restoration worked - Check that you can see your balance
2. Test a small transaction - Send a small amount to verify functionality
3. Create new backups - Store your mnemonic in multiple secure locations
4. Destroy old backups - If restoring on a new device, securely delete old wallet files

Protecting Your Mnemonic

• ✅ Write on paper - Physical backup is most secure
• ✅ Store in safe - Fireproof safe or bank deposit box
• ✅ Multiple copies - Store in different secure locations
• ✅ Test recovery - Periodically verify you can restore from backup

Next Steps

After restoring your wallet:

• Sync Wallet - Sync to see your balance
• Send ZEC - Send transactions
• Receive ZEC - Generate receiving addresses
• Backup & Recovery - Learn about backup strategies

Quick Start Guide

Get up and running with NozyWallet in 5 minutes!

Overview

This quick start guide will help you:

1. Install NozyWallet
2. Create your first wallet
3. Generate a receiving address
4. Sync your wallet

Step 1: Installation (2 minutes)

Desktop App (Recommended)

1. Download from GitHub Releases
2. Install the .exe (Windows), .dmg (macOS), or .AppImage (Linux)
3. Launch NozyWallet

CLI (Alternative)

# Clone repository
git clone https://github.com/LEONINE-DAO/Nozy-wallet.git
cd Nozy-wallet

# Build
cargo build --release

# Binary will be in target/release/nozy (or nozy.exe on Windows)

Step 2: Create Wallet (1 minute)

Desktop App

1. Launch NozyWallet
2. Click "Create New Wallet"
3. Save your 24-word mnemonic phrase - Write it down on paper!
4. Set a password (optional but recommended)
5. Click "Create"

CLI

nozy new

Follow the prompts to create your wallet and save your mnemonic phrase.

⚠️ CRITICAL: Your mnemonic phrase is the ONLY way to recover your wallet. Store it securely offline!

Step 3: Generate Address (30 seconds)

Desktop App

1. Click "Receive" tab
2. Your Orchard address will be displayed
3. Copy the address or show QR code

CLI

nozy addresses

Example output:

Generating Orchard address...

Address 0: u1testaddress1234567890abcdefghijklmnopqrstuvwxyz...

Copy this address - You'll use it to receive ZEC.

Step 4: Sync Wallet (1-2 minutes)

Desktop App

1. Click "Sync" button
2. Wait for sync to complete
3. Your balance will appear

CLI

# Sync from recent blocks (faster)
nozy sync

# Or sync from specific height
nozy sync --start-height 3000000

First sync may take time - The wallet needs to scan the blockchain for your notes.

What's Next?

Send Your First Transaction

1. Get ZEC - Receive ZEC to your address
2. Wait for confirmations - Usually 1-2 blocks (~75 seconds each)
3. Sync wallet - Run sync to see incoming funds
4. Send ZEC - Use "Send" to create a transaction

See Sending ZEC for detailed instructions.

Learn More

• Creating Your First Wallet - Detailed wallet creation guide
• Restoring from Seed Phrase - How to restore a wallet
• Wallet Management - Advanced wallet operations
• Security Best Practices - Keep your wallet secure

Common Questions

Q: Do I need my own Zebra node?
A: No! You can use a public Zebra node. Configure the node URL in settings if needed.

Q: How long does first sync take?
A: Depends on blockchain height. Recent blocks (last 1000) take ~1-2 minutes. Full sync takes longer.

Q: Can I use transparent addresses?
A: No. NozyWallet only supports shielded (Orchard / Ironwood) addresses for complete privacy. For why Ironwood exists, see Why Ironwood?.

Q: What if I lose my mnemonic?
A: Without your mnemonic phrase, you cannot recover your wallet. Always backup your mnemonic securely!

Q: Is my wallet safe?
A: Yes! Your wallet file is encrypted with your password, and your private keys never leave your device.

Getting Help

• Documentation: Browse the full documentation
• Troubleshooting: Check Common Issues
• GitHub Issues: Report bugs or ask questions
• Community: Join our Discord (if available)

Ready to Use!

You're now ready to use NozyWallet! Remember:

1. ✅ Backup your mnemonic - Store it securely offline
2. ✅ Use strong password - Protect your wallet file
3. ✅ Verify addresses - Double-check addresses before sending
4. ✅ Start small - Test with small amounts first
5. ✅ Stay private - All transactions are automatically private!

Happy private transacting! 🦋

Absolute Privacy

NozyWallet enforces complete privacy by default. This means every transaction is automatically private - you cannot accidentally send a transparent transaction that would reveal your financial information.

How Privacy Works

Shielded Transactions Only

Unlike other Zcash wallets that support both transparent and shielded transactions, NozyWallet only supports shielded transactions. This ensures:

• No transparent addresses - You cannot receive or send from transparent addresses
• All transactions are private - Every transaction uses zero-knowledge proofs
• No privacy mistakes - You cannot accidentally compromise your privacy

Zero-Knowledge Proofs

All NozyWallet transactions use Zcash's Orchard protocol, which provides:

• Sender privacy: Your address is hidden
• Receiver privacy: Recipient address is hidden
• Amount privacy: Transaction amounts are hidden
• Cryptographic proofs: Privacy is mathematically guaranteed, not just obfuscated

Untraceable Transactions

Every transaction is completely untraceable:

• No transaction graph - Cannot link transactions together
• No address reuse - New addresses for every transaction
• No metadata leakage - No information exposed on blockchain

Comparison with Other Wallets

vs. Standard Zcash Wallets

vs. Monero

Privacy Guarantees

When you use NozyWallet, you get these guarantees:

1. Sender Privacy

• Your address is never revealed on the blockchain
• Cannot determine who sent a transaction
• Cannot link your address to transactions

2. Receiver Privacy

• Recipient address is hidden
• Cannot determine who received funds
• Only the recipient can see incoming transactions

3. Amount Privacy

• Transaction amounts are encrypted
• Only sender and receiver know the amount
• Cannot determine value from blockchain

4. Fungibility

• All coins are identical
• No coin history tracking
• No blacklisted or tainted coins
• Every coin is as good as any other

Best Practices

To maintain maximum privacy:

1. Use unique addresses - Generate a new address for each transaction
2. Don't reuse addresses - Address reuse can reduce privacy
3. Run your own node - Use your own Zebra node for maximum privacy
4. Keep software updated - Security updates protect your privacy
5. Backup securely - Protect your mnemonic phrase offline

Technical Details

Orchard Protocol

NozyWallet uses Zcash's Orchard shielded pool, which provides:

• Better performance - Faster proofs than earlier shielded pools
• Better scalability - More efficient than previous pools
• Future-proof - Active development and improvements
• NU 6.1 support - Latest protocol features

Zero-Knowledge Proofs

Zero-knowledge proofs allow you to:

• Prove you have the right to spend funds without revealing your identity
• Prove transaction validity without revealing amounts
• Maintain privacy while ensuring security

Frequently Asked Questions

Q: Can I send transparent transactions?
A: No. NozyWallet only supports shielded transactions to ensure complete privacy.

Q: Is my privacy guaranteed?
A: Yes, as long as you follow best practices (unique addresses, secure backups, etc.).

Q: How does this compare to Monero?
A: Privacy levels are equivalent, but Zcash offers faster block times and lower fees.

Q: What if I need transparent transactions?
A: For transparent transactions, you would need to use a different wallet. However, transparent transactions compromise privacy.

Learn More

• Security Best Practices
• Network Configuration
• Privacy Network Options (if implemented)

Performance & Speed

NozyWallet is designed for speed and efficiency, providing fast transaction processing and low fees while maintaining complete privacy.

Fast Block Times

Zcash's network has a block time of approximately 75 seconds, which is faster than Monero's ~2 minutes. This means:

• Faster confirmations - Your transactions confirm in ~75 seconds
• Lower wait times - Less waiting for transaction finality
• Better user experience - Quick, responsive wallet operations

Transaction Efficiency

Compact Transactions

Orchard transactions are more efficient than Monero transactions:

• Smaller size - Orchard transactions are smaller on average
• Lower fees - Smaller transactions = lower fees
• Better scalability - Network can handle more transactions

Proof Generation

• Fast proving - Modern zero-knowledge proof systems are efficient
• GPU acceleration - Optional GPU acceleration for faster proofs
• Parameter caching - Proving parameters cached for speed

Network Performance

Low Latency

NozyWallet connects directly to Zebra nodes for minimal latency:

• Direct RPC connection - No intermediate servers
• Efficient protocol - Optimized JSON-RPC calls
• Connection pooling - Reuse connections for speed

Scalability

The Zcash network can handle:

• High transaction throughput - Thousands of transactions per block
• Efficient note scanning - Fast blockchain scanning
• Quick wallet sync - Rapid synchronization for new wallets

Performance Benchmarks

(Note: Actual performance may vary based on hardware and network conditions)

• Transaction building: < 1 second
• Proof generation: 1-5 seconds (depends on hardware)
• Blockchain scan: ~1000 blocks/second
• Address generation: < 100ms
• Wallet sync: Varies by blockchain height

Optimization Tips

For Faster Performance

1. Use SSD storage - Faster disk I/O for wallet operations
2. Run local node - Reduce network latency
3. Enable GPU acceleration - Faster proof generation (if supported)
4. Keep software updated - Performance improvements in updates
5. Adequate RAM - More RAM = better performance

For Lower Fees

• Wait for low-fee periods - Fees vary with network congestion
• Use standard transaction size - Smaller = lower fees
• Batch transactions - Group multiple operations when possible

Comparison with Other Wallets

Speed Comparison

Fee Comparison

Technical Details

Orchard Protocol Efficiency

The Orchard protocol provides:

• Compact proofs - Smaller proof sizes
• Batch processing - Multiple operations in one transaction
• Efficient scanning - Fast note commitment tree traversal

Network Optimization

NozyWallet optimizes network usage:

• Connection reuse - Persistent RPC connections
• Batch requests - Multiple RPC calls in single request
• Efficient queries - Minimal data transfer

Frequently Asked Questions

Q: How fast are transactions?
A: Transactions typically confirm in 1-2 blocks (~75-150 seconds).

Q: Are fees high?
A: No, Zcash fees are generally lower than Monero due to smaller transaction sizes.

Q: Does performance degrade over time?
A: No, performance remains consistent as the blockchain grows.

Q: Can I speed up transactions?
A: Transaction speed depends on block time, which is fixed. You cannot pay more for faster blocks.

Learn More

• Network Configuration
• Zebra Node Setup
• Proving Parameters

Security Features

NozyWallet treats wallet software as high-impact: keys, addresses, and transaction data must be handled carefully. Security is built into storage, defaults, and operational guidance—not optional hardening.

Self-custodial by design

• Your keys, your wallet — Nozy does not custody funds or hold recovery phrases on your behalf.
• Local wallet file — Encrypted on disk; unlocked only with your password (Argon2-based protection in the core library).
• No transparent fallback — Shielded-first flows reduce accidental address-type mistakes that leak metadata.

Password and storage

• Argon2 hashing for wallet encryption at rest.
• Zeroize patterns for sensitive buffers in Rust paths where applicable (see project security docs and AGENTS.md).
• Backup responsibility — You must secure your BIP39 mnemonic; loss of mnemonic and password means loss of funds.

Network and node security

• Your node, your trust model — Recommended stack: Zebrad + lightwalletd you control or explicitly trust.
• Companion API — nozywallet-api is intended for localhost; exposing it publicly requires TLS, API keys, and VPS hardening (VPS deploy guide).
• Privacy networks — Optional Tor/I2P configuration for RPC (see Privacy Networks chapters in this book).

Orchard and proving

• Standard Zcash crates — Orchard / librustzcash; no custom ciphers or hand-rolled proofs in the wallet core.
• Proving parameters — Orchard uses Halo 2; manage proving resources per installation docs (no legacy Sapling parameter download for Orchard-only paths).

Extension and web surfaces

• Browser extension — MV3 + WASM; compact sync via companion API (companion docs).
• Web app (in development) — Dashboard talks to nozywallet-api; seeds are not stored in the static launchpad site (web-app README).

Viewing keys and disclosure

• UFVK export (e.g. Keystone pairing) is read-only — can reveal shielded activity to whoever holds the viewing key; never equivalent to spending authority. Guide: Keystone Hardware Wallet.
• Planned business accountant disclosure flows are documented separately in project RFCs; treat UFVK sharing as irreversible for privacy against that party.

Open source and review

• Source: LEONINE-DAO/Nozy-wallet
• Report suspected vulnerabilities responsibly per CONTRIBUTING.md; do not file public issues for undisclosed exploits.

Best practices

For day-to-day habits (backups, device security, node hygiene), see Security Best Practices and Private Key Management.

Why Ironwood? (Orchard → NU6.3)

This page is for newcomers who see “Orchard” and “Ironwood” in NozyWallet and wonder what changed—and why the wallet cares.

Short version

1. Orchard was Zcash’s modern shielded pool. Nozy shipped as an Orchard-first, shielded-only wallet.
2. In 2026, Shielded Labs security researcher Taylor Hornby found a soundness bug in Orchard’s zero-knowledge circuit. In the worst case it could have allowed undetectable counterfeit ZEC inside the pool.
3. The circuit was patched in an emergency network upgrade. That stopped new abuse of the bug.
4. Because Orchard is private, nobody can prove from the public ledger alone that counterfeit notes were never minted while the bug was live. Supply soundness needed a stronger answer.
5. Ironwood (NU6.3) seals the old Orchard pool, opens a new shielded pool with the corrected circuit, and moves value through a turnstile so the circulating supply can be verified again.
6. Nozy follows the chain. After Ironwood activates, normal sends use Ironwood; Orchard balances migrate with Plan → Split → Migrate → Broadcast—not “Orchard forever.”

What Taylor found

Orchard transactions hide sender, receiver, and amount using a zk-SNARK proof. The network accepts a transaction if the proof verifies. That only works if proofs are sound: a dishonest prover must not be able to convince the network of a false statement (for example, that a transaction balances when it does not).

Taylor Hornby, doing security research funded by Shielded Labs, discovered a flaw in Orchard’s circuit—the math the proof is supposed to enforce. Under the right conditions, an attacker could produce a proof the network would accept even though the underlying notes did not balance correctly. That is a counterfeiting risk inside the shielded pool: from the outside, fake notes look like real ones.

Important context for newcomers:

• The bug lived in a highly reviewed system for years before it was found.
• Ecosystem teams coordinated an emergency fix so the vulnerable circuit path could no longer be used going forward.
• Public messaging has generally been that exploitation is believed unlikely—but belief is not the same as independent verification of historical supply inside a private pool.

For primary sources, start with Shielded Labs’ Ironwood overview and circulating-supply writeup, and the community forum thread Ironwood: Verifying the Soundness of Zcash’s Circulating Supply.

Why a patch alone was not enough

Patching the circuit stops new counterfeiting via that bug. It does not automatically restore the property users want next:

“Anyone running a node can verify that no more ZEC is circulating than should be.”

In a transparent ledger, supply is visible. In Orchard, amounts are hidden. If a soundness bug could have minted notes before the fix, those notes would not announce themselves on-chain. So the ecosystem’s answer is not only “fix the math,” but also:

• Seal the old Orchard pool (no new ordinary Orchard activity after activation).
• Stand up Ironwood—a new pool using the corrected circuit.
• Allow value to leave Orchard only through a turnstile that accounts for how much can exit versus how much legitimately entered.

That design restores verifiable supply soundness without requiring every user to wait for a full migration before the network can make strong claims again.

What Ironwood means for users

After NU6.3 / Ironwood activates (mainnet target height 3,428,143, 2026-07-28):

Migration is not the same as a normal private payment:

• Turnstile crossings expose amounts on the public chain (by design, for accounting).
• Broadcasting a migration over clearnet can link that amount to network identity (IP / session). Shielded Labs (Zooko Wilcox and Taylor Hornby) documented this in Security issues in migrating user funds from Orchard to Ironwood.

Nozy treats migration as a privacy operation: notify, warn, then Plan / Split / Migrate / Broadcast with safer network guidance—not a silent “upgrade balance” button. See also Privacy model.

Why NozyWallet changed

Nozy was built Orchard-first and shielded-only. That product stance does not go away—it moves forward with the active shielded pool.

If Nozy stayed Orchard-only after Ironwood:

• Users could not make normal payments once Orchard is sealed.
• Nozy would lag the network’s supply-integrity story.
• Holders of Orchard notes would have no first-class migrate path in the wallet they trust.

So Nozy’s change is deliberate:

1. Scan and hold both pools while migration is in progress.
2. Route new sends to Ironwood once the network (and wallet builder path) are active.
3. Ship migrate tooling in CLI Lite and Desktop (and companion API surfaces) so Orchard notes can move safely and explicitly.
4. Keep the old promise: no transparent t1 sends—privacy by default, still.

Operator and readiness detail lives in the repo: docs/reference/IRONWOOD_WALLET_READINESS.md and the Ironwood mainnet week runbook.

Timeline newcomers can remember

Orchard era     →  Taylor finds Orchard circuit soundness bug
                →  Emergency network upgrade patches the circuit
                →  Ironwood (NU6.3) proposed: seal Orchard, new pool, turnstile
                →  Wallets (including Nozy) add migrate + Ironwood send
Ironwood era    →  Post-activation: live value in Ironwood; Orchard exits via migrate

FAQ

Did Orchard “fail” as a privacy system?
No. The bug was about proof soundness / supply integrity, not “everyone can see your amounts.” Privacy of parties and amounts inside a healthy pool is a different question from “can someone mint fake notes the chain cannot detect?”

Was counterfeit ZEC definitely created?
Public ecosystem communication has generally said exploitation is unlikely. Ironwood exists so you do not have to take that on trust forever: the sealed pool + turnstile restore verifiable bounds.

Do I lose my Orchard funds?
They remain yours as notes in the old pool until you migrate. After activation, normal Orchard send is blocked; use Nozy’s Ironwood migrate flow (or equivalent) to move value into the new pool.

Is Ironwood a different coin?
No. It is still ZEC, in a new shielded pool with corrected circuit rules.

Further reading

• Shielded Labs — Ironwood
• Shielded Labs — Verifying the soundness of Zcash’s circulating supply
• Forum — Ironwood thread
• Project Tachyon — Auditing the Orchard pool’s supply
• Nozy — What is Nozy? · Privacy model

NU 6.1 Support

NozyWallet is fully compatible with Zcash Network Upgrade 6.1 (NU 6.1).

What is NU 6.1?

Network Upgrade 6.1 is the latest Zcash network upgrade that brings:

• Protocol Version 170140 - Latest protocol features
• Activation Height - Block 3,146,400 (November 23, 2025)
• New Features - ZIP 271, ZIP 1016 support
• Performance Improvements - Better efficiency and scalability

NozyWallet Compatibility

✅ Fully Compatible - NozyWallet is ready for NU 6.1:

• Protocol version 170140 support
• Latest libraries (zcash_protocol 0.6.2+, zcash_primitives 0.24.1+)
• All NU 6.1 features supported
• Automatic upgrade handling

Checking NU 6.1 Status

CLI

Check NU 6.1 status:

nozy nu61

Or check wallet status:

nozy status

Example output:

✅ NU 6.1 Support: Enabled
Protocol Version: 170140
Activation Height: 3,146,400
Current Height: 3,147,200
Status: Active

What Changed?

For Users

No action required - NozyWallet automatically:

• ✅ Uses latest protocol version
• ✅ Supports new features
• ✅ Handles upgrade seamlessly
• ✅ Maintains compatibility

Benefits:

• Better performance
• Improved privacy
• Enhanced features
• Future-proof wallet

For Developers

Technical changes:

• Updated protocol version
• New ZIP support
• Enhanced libraries
• Improved APIs

Upgrade Timeline

Before Activation (Block < 3,146,400)

• Wallet uses pre-NU 6.1 protocol
• All features work normally
• Upgrade preparation in place

After Activation (Block >= 3,146,400)

• Wallet automatically uses NU 6.1
• New features activated
• Full compatibility maintained

Current Status

Check current status:

nozy nu61

This shows:

• Current block height
• Activation status
• Protocol version in use

Features Enabled

ZIP 271 Support

ZIP 271 brings:

• Enhanced transaction formats
• Better compatibility
• Improved privacy features

ZIP 1016 Support

ZIP 1016 enables:

• New transaction types
• Enhanced functionality
• Better interoperability

Migration Guide

For Existing Wallets

No migration needed - Existing wallets work automatically:

• ✅ Old wallets compatible
• ✅ Automatic upgrade
• ✅ No manual steps required
• ✅ All features available

For New Wallets

Standard creation process - New wallets use NU 6.1 by default:

• ✅ Latest protocol from start
• ✅ All features enabled
• ✅ Future-proof setup

Troubleshooting

"Protocol version mismatch" Error

Problem: Wallet and node use different protocol versions.

Solutions:

1. Update NozyWallet - Ensure latest version
2. Update Zebra node - Ensure node supports NU 6.1
3. Check network - Verify mainnet/testnet matches
4. Sync wallet - Run sync to update

"NU 6.1 not active" Warning

Problem: Network upgrade hasn't activated yet.

Solutions:

• Wait for activation height (block 3,146,400)
• Check current block height
• Verify activation date (November 23, 2025)

Learn More

• Zcash NU 6.1 Documentation - Official Zcash documentation
• ZIP 271 - ZIP 271 specification
• ZIP 1016 - ZIP 1016 specification
• Network Upgrades - Zcash network upgrade guide

Wallet Management

Manage wallets and profiles in NozyWallet.

Single wallet vs profiles

• CLI traditionally uses one active data directory under the platform Nozy data path.
• Desktop supports multiple profiles — each with its own mnemonic, wallet.dat, notes, and sync state.

Profiles live under:

• Windows: %APPDATA%\nozy\nozy\data\profiles\{profile-id}\
• Manifest tracks active profile id

Desktop: switch profile

1. Lock the current wallet (or quit).
2. Welcome screen lists profiles with labels.
3. Select profile → Unlock with that profile’s password.

Creating a new wallet on Welcome adds a new profile without removing others.

Create additional wallet

Welcome → Create new wallet → new password + new mnemonic. Back up the new mnemonic separately.

Rename / organize

Use profile labels shown on Welcome (implementation may use profile name from manifest). Keep a personal map of which mnemonic belongs to which label.

Lock and password

• Lock clears session keys from memory; data on disk stays encrypted.
• Change password (Settings → Security) re-encrypts storage — ensure you have mnemonic backup first.

Delete a profile

No one-click delete in all builds — advanced users remove the profile folder under profiles/ while app is closed. Only if mnemonic is backed up.

CLI wallet path

Config and data paths: Backup & Recovery.

Related

• Creating Your First Wallet
• Backup Strategies

Sending ZEC

Send private shielded transactions with NozyWallet.

Prerequisites

Before sending ZEC, ensure:

• ✅ Wallet is created and unlocked
• ✅ You have ZEC in your wallet (balance > 0)
• ✅ Wallet is synced with the blockchain
• ✅ You have the recipient's address

Desktop App

Step 1: Open Send Screen

1. Launch NozyWallet
2. Click "Send" in the navigation menu
3. The send screen will open

Step 2: Enter Recipient Address

1. Enter recipient address in the "To" field

   • Must be a valid Orchard address (starts with u1... or orchard1...)
   • Double-check the address before sending
   • Use address book if saved

2. Verify address format - NozyWallet only supports shielded addresses

Step 3: Enter Amount

1. Enter amount in ZEC

   • Amount must be less than your balance (account for fees)
   • Minimum amount: 0.00001 ZEC (1 zatoshi)

2. Check balance - Verify you have sufficient funds

Step 4: Add Memo (Optional)

1. Enter memo - Add a note (up to 512 characters)
2. Memo is encrypted - Only the recipient can read it

Step 5: Review & Send

1. Review transaction details:

   • Recipient address
   • Amount
   • Memo (if included)
   • Estimated fee

2. Confirm transaction - Click "Send" button

3. Enter password - If wallet is password-protected

4. Wait for confirmation - Transaction will be built and broadcast

Sending with Keystone (mainnet)

For air-gapped hardware signing:

1. Settings → Keystone — export UFVK, pair on Keystone (Zcash mainnet), enable Keystone.
2. Send — enter u1… recipient and amount → Review & prepare.
3. Scan PCZT QR on Keystone → sign → paste signed PCZT back → Broadcast signed tx.

See Keystone Hardware Wallet for full setup and troubleshooting.

CLI (Command Line)

Basic Send Command

nozy send --to <address> --amount <amount>

Example:

nozy send --to u1testaddress1234567890abcdefghijklmnopqrstuvwxyz... --amount 0.1

With Memo

nozy send --to <address> --amount <amount> --memo "Payment for services"

Full Example

# Send 0.5 ZEC with a memo
nozy send \
  --to u1testaddress1234567890abcdefghijklmnopqrstuvwxyz... \
  --amount 0.5 \
  --memo "Payment for invoice #12345"

Transaction Details

What Happens When You Send

1. Note Selection - Wallet selects spendable notes to cover the amount
2. Transaction Building - Creates a shielded transaction
3. Proof Generation - Generates zero-knowledge proofs (may take a few seconds)
4. Broadcasting - Sends transaction to the Zcash network
5. Confirmation - Transaction is included in a block (~75 seconds)

Transaction Fees

• Fee is automatic - Calculated based on transaction size
• Typical fee - 0.00001-0.0001 ZEC (1-10 zatoshis)
• Fee deducted - Automatically deducted from your balance

Confirmation Time

• Block time - ~75 seconds per block
• First confirmation - Usually 1-2 blocks (~75-150 seconds)
• Recommended confirmations - 3-10 blocks for larger amounts

Verifying Transactions

Check Transaction Status

Desktop App:

• View transaction in "History" tab
• Status will show: Pending, Confirmed, or Failed

CLI:

# View transaction history
nozy history

# Check specific transaction
nozy transaction <txid>

Transaction ID (TxID)

After sending, you'll receive a transaction ID:

• Share with recipient - They can verify receipt using the txid
• Keep for records - Track your transactions
• Privacy note - TxID doesn't reveal amounts or addresses

Troubleshooting

"Insufficient funds" Error

Problem: Not enough ZEC to cover amount + fees.

Solutions:

1. Check balance - Verify your available balance
2. Account for fees - Leave room for transaction fees
3. Sync wallet - Ensure wallet is synced to see all notes
4. Check unspent notes - Some notes may not be spendable yet

"Invalid address" Error

Problem: Recipient address format is invalid.

Solutions:

1. Verify address - Check spelling and format
2. Use unified address - Must start with u1...
3. Check network - Ensure mainnet/testnet matches
4. Extract Orchard address - NozyWallet extracts Orchard from unified addresses

"Transaction build failed" Error

Problem: Unable to build the transaction.

Solutions:

1. Check proving parameters - Ensure parameters are downloaded
2. Verify balance - Ensure you have spendable notes
3. Sync wallet - Sync may be needed to see notes
4. Check Zebra connection - Verify connection to Zebra node

"Proof generation failed" Error

Problem: Unable to generate zero-knowledge proofs.

Solutions:

1. Download proving parameters - nozy proving --download
2. Check disk space - Parameters are large (~2GB)
3. Verify parameters - Check parameter file integrity
4. Re-download if needed - Parameters may be corrupted

Best Practices

Before Sending

1. ✅ Verify recipient address - Double-check address before sending
2. ✅ Test with small amount - Send small test first if unsure
3. ✅ Check balance - Ensure sufficient funds including fees
4. ✅ Sync wallet - Make sure wallet is up to date

Security

1. ✅ Keep private keys secure - Never share your mnemonic or password
2. ✅ Verify addresses - Always verify recipient addresses
3. ✅ Start small - Test with small amounts first
4. ✅ Double-check amounts - Verify amount before confirming

Privacy

1. ✅ Use memos carefully - Memos are encrypted but still be mindful
2. ✅ Avoid address reuse - Generate new addresses for each transaction
3. ✅ Consider churning - For maximum privacy, use multiple transactions
4. ✅ Keep transactions private - Don't publicly share transaction details

Advanced: Transaction Options

Custom Fee (if supported)

nozy send --to <address> --amount <amount> --fee <fee>

Spend from Specific Notes (if supported)

nozy send --to <address> --amount <amount> --from-note <note-id>

What Happens Next?

After sending:

1. Transaction broadcasts - Sent to Zcash network
2. Included in block - Mined into next block (~75 seconds)
3. Confirmations - Additional blocks add confirmations
4. Recipient receives - Funds appear in recipient's wallet after confirmations

Next Steps

• Receiving ZEC - Learn about receiving transactions
• Transaction History - View and track transactions
• Address Management - Manage your addresses
• Troubleshooting - Resolve issues

Receiving ZEC

Learn how to receive ZEC in your NozyWallet.

Generating Receiving Addresses

NozyWallet generates Orchard addresses that are private by default. Each address can be used to receive ZEC.

Desktop App

1. Open NozyWallet
2. Click "Receive" tab
3. Your address is displayed - Copy or show QR code
4. Generate new address - Click "New Address" for additional addresses

CLI

Generate a single address:

nozy addresses

Generate multiple addresses:

nozy addresses --count 5

Example output:

Generating 5 Orchard addresses...

Address 0: u1testaddress1234567890abcdefghijklmnopqrstuvwxyz...
Address 1: u1testaddress2345678901bcdefghijklmnopqrstuvwxyzab...
Address 2: u1testaddress3456789012cdefghijklmnopqrstuvwxyzabc...
Address 3: u1testaddress4567890123defghijklmnopqrstuvwxyzabcd...
Address 4: u1testaddress5678901234efghijklmnopqrstuvwxyzabcde...

Generated 5 addresses

Address Types

NozyWallet uses Orchard addresses exclusively:

• Unified Address format (starts with u1...)
• Orchard-only addresses (starts with orchard1...)
• Shielded by default - All transactions are private

Best Practices

Address Reuse

Avoid reusing addresses for maximum privacy:

• ✅ Generate a new address for each transaction
• ✅ Use different addresses for different purposes
• ✅ Don't reuse addresses that have received funds

Sharing Addresses

Safe ways to share:

• ✅ Copy address text
• ✅ Show QR code
• ✅ Share via secure messaging (encrypted channels)

Avoid:

• ❌ Sharing on public platforms
• ❌ Reusing addresses
• ❌ Using transparent addresses (not supported)

Checking Received Funds

Desktop App

1. Sync wallet - Click "Sync" button
2. View balance - Balance updates automatically
3. Check history - View incoming transactions

CLI

Sync wallet to see new funds:

nozy sync

Check balance:

nozy balance

View transaction history:

nozy history

Receiving Process

Step 1: Share Your Address

Share your receiving address with the sender:

• Copy address text
• Share QR code
• Send via secure channel

Step 2: Wait for Transaction

The sender will:

1. Create a transaction to your address
2. Broadcast to Zcash network
3. Transaction is mined into a block (~75 seconds)

Step 3: Sync Wallet

After the transaction is confirmed:

1. Sync your wallet - Run sync command
2. Scan for notes - Wallet automatically scans for incoming notes
3. Balance updates - Your balance reflects the received funds

Step 4: Verify Receipt

Check that you received the funds:

• View balance
• Check transaction history
• Verify transaction details

Transaction Confirmations

Confirmation Time

• First block - ~75 seconds
• Recommended - 3-10 confirmations for larger amounts
• Safe - 10+ confirmations for maximum security

Checking Confirmations

Desktop App:

• View transaction in history
• Confirmation count shown

CLI:

nozy transaction <txid>

Privacy Considerations

Receiving Privacy

• ✅ All transactions are private - Sender, receiver, amount hidden
• ✅ Address privacy - Your address doesn't reveal your identity
• ✅ Amount privacy - Transaction amounts are hidden
• ✅ Fungibility - All ZEC is identical

Best Practices

1. Generate new addresses - One address per transaction
2. Don't link addresses - Avoid patterns that could link addresses
3. Use memos carefully - Memos are encrypted but be mindful
4. Sync regularly - Keep wallet synced to see all funds

Troubleshooting

"No funds received" After Sharing Address

Possible reasons:

1. Transaction not confirmed - Wait for block confirmation
2. Wallet not synced - Run sync command
3. Wrong network - Ensure mainnet/testnet matches
4. Transaction failed - Check sender's transaction status

Solutions:

• Sync wallet: nozy sync
• Check balance: nozy balance
• Verify address: Confirm address matches what was shared

"Invalid address" Error When Sharing

Problem: Address format is incorrect.

Solutions:

• Verify address format (must start with u1... or orchard1...)
• Ensure address was copied completely
• Check for typos or missing characters

Next Steps

• Sending ZEC - Learn how to send transactions
• Transaction History - View your transactions
• Address Management - Manage your addresses
• Wallet Management - Advanced wallet operations

Transaction History

View sent and received shielded activity in NozyWallet.

Desktop

History tab shows:

• Sent and received transactions
• Block height and status
• Links to mainnet.zcashexplorer.app for TXIDs
• Refresh control in header

Home → Recent Activity shows the latest entries; full list on History.

Sorting is by block height (newest first), then timestamp, then txid.

CLI

nozy history

What appears in history

Very old receives may show Block N if broadcast timestamp was unavailable (epoch placeholder omitted in UI).

Confirmations

nozy check-confirmations -t <txid>

Or open explorer link from History.

Export

Export to CSV/file is roadmap item — copy TXIDs from History or use explorer for now.

Related

• Sending ZEC
• Receiving ZEC

Address Management

NozyWallet uses Orchard unified addresses for receiving. Transparent addresses are not supported.

Generate address

Desktop

Receive tab → copy u1… address.

CLI

nozy receive

Each wallet can derive multiple addresses (account / index) — default flow uses the primary receiving address.

Address book (Contacts)

Desktop Contacts tab:

1. Add name + shielded address (u1… or testnet equivalent).
2. Use Pick contact on Send tab to fill recipient.

CLI:

nozy address-book add --name Vendor --address u1…
nozy address-book list

Only shielded addresses are accepted — transparent t1 rejected.

Unified addresses

• Mainnet: starts with u1
• Testnet: starts with utest1

Always verify network matches your wallet configuration.

Labels and reuse

• Reusing one address is OK for privacy trade-offs; fresh addresses per receive improves unlinkability.
• Contacts are local metadata — not on-chain labels.

Related

• Receiving ZEC
• Sending ZEC

Backup & Recovery

Your wallet can be recovered from a 24-word mnemonic or from an encrypted backup file. Treat both like cash — anyone with the phrase or backup + password controls your funds.

What to back up

Mnemonic is required. File backup is optional but convenient for desktop users who use Export backup in Settings.

Mnemonic backup (recommended)

1. Write down the 24 words shown at wallet creation (or from Settings → Security → reveal seed, when implemented).
2. Store offline — paper or metal; never in cloud email or screenshots.
3. Verify: restore on a test profile or second device before relying on it.

# CLI restore
nozy restore
# Enter mnemonic and new password when prompted

Desktop: export and restore

Export

1. Unlock the wallet.
2. Settings → Backup (or Security).
3. Choose a path and export — creates an encrypted backup via export_backup.

Restore

1. Welcome screen → Restore from backup (or Settings).
2. Select the backup file path (restore_from_backup).
3. Unlock with the password used when the backup was created.

After restore you must unlock again before send or sync.

CLI and data paths

Multi-wallet profiles live under {data}/profiles/{id}/. Switching profiles in the desktop Welcome screen changes the active data directory.

Recovery checklist

1. Install NozyWallet (CLI or desktop).
2. Point Zebrad at a synced node (Zebra Node Setup).
3. Restore mnemonic or backup file.
4. Unlock with password.
5. Sync to tip (nozy sync --to-tip or desktop Sync).
6. Confirm balance and notes before sending.

What backup does not include

• Your Zebrad chain data (re-sync the node separately).
• lightwalletd compact DB (re-sync via LWD if you use compact cache).
• On-chain funds — recovery only restores keys; you still need chain sync to see balance.

See also: Backup Strategies, Backup tutorial.

Desktop Installation

Install the NozyWallet desktop app (Tauri + React) on your machine.

Prerequisites (build from source)

• Rust 1.70+
• Node.js 18+
• Platform Tauri deps — tauri.app/start/prerequisites

From source (developers)

git clone https://github.com/LEONINE-DAO/Nozy-wallet.git
cd NozyWallet/desktop-client
npm install
cargo tauri dev

Launch the NozyWallet window from the taskbar — not a browser tab at http://localhost:5173.

Production build

cd desktop-client
cargo tauri build

Artifacts under desktop-client/src-tauri/target/release/:

Pre-built installers

When available, download from GitHub Releases.

Also required for full function

• Zebrad with RPC — Zebra Node Setup
• Orchard proving params — downloaded on first send or via Settings
• lightwalletd (optional) — compact sync; default 127.0.0.1:9067

Related

• First-Time Setup
• Desktop README

First-Time Setup

Walkthrough from install to first synced wallet.

1. Install the app

See Installation. Start with cargo tauri dev or the release installer.

2. Connect Zebrad

Before creating a wallet, ensure your node works:

nozy test-zebra

Or after wallet exists: Settings → Network → set URL → Test Connection.

WSL on Windows: use WSL IP in URL (connectivity guide).

3. Create or restore

Welcome screen options:

Create

1. Choose a strong password.
2. Write down 24 words — only chance shown at creation.
3. Confirm mnemonic if prompted.
4. Land on Home.

Restore

1. Enter 24 words in order.
2. Set password.
3. Sync to tip.

4. Multi-wallet profiles

Welcome lists existing profiles if any. Select a profile before unlock. Each profile has separate keys and data.

Create additional profiles from Welcome (create/restore flow) without deleting others.

5. Initial sync

1. Home → Sync (header or layout).
2. Wait until block sync strip shows caught up.
3. Balance updates when notes are indexed.

CLI equivalent: nozy sync --to-tip.

6. Proving parameters

First shielded send may prompt or auto-download Orchard params. Settings → Proving, or:

nozy proving --download

7. Receive test (optional)

Receive tab → copy unified address (u1…) → fund from faucet or exchange (shielded withdrawal).

Checklist

• Zebrad RPC verified
• Mnemonic backed up offline
• Sync to tip complete
• Using desktop window (not browser dev URL)

Next: Using the GUI | Troubleshooting

Using the GUI

Overview of the NozyWallet desktop interface (Tauri app).

Navigation

Header: Sync button, wallet lock, profile context.

Home

• Balance — spendable shielded ZEC after sync.
• Recent Activity — latest txs; links to block explorer (mainnet.zcashexplorer.app).
• Block sync panel — blocks behind tip; detects stalled node if tip stops moving.

Background sync may run while unlocked (useWalletAutoSync).

Send

1. Open Send tab (not only Home shortcut — full form on Send page).
2. Enter recipient (u1… mainnet Orchard unified) or pick from Contacts.
3. Amount in ZEC; optional memo.
4. Confirm password if locked.
5. Wait for prove + broadcast — first send can take several minutes (toast explains).

Keystone (mainnet): When enabled under Settings → Keystone, Send uses PCZT signing — prepare transaction, scan QR on Keystone, paste signed PCZT, broadcast. See Keystone Hardware Wallet.

Send is blocked if witness lag too high or node unreachable — sync first.

Receive

Copy unified address. Only Orchard shielded receives are supported.

History

• Sticky header with refresh.
• Sent vs received counts.
• View on explorer per transaction.

Contacts

Add name + shielded address inline. Only u1 / zs1 style addresses accepted.

Settings

Sync behavior

Sync runs catch-up until scan gap closes. “Synced successfully” should align with tip — not merely one RPC ping. See sync helpers in app (syncWalletToTip, honest status messages).

Lock / unlock

Lock clears in-memory session. Unlock required for send, seed reveal, and some settings.

What not to do

• Don’t use browser tab at localhost:5173 for real funds.
• Don’t skip mnemonic backup at creation.
• Don’t send while node tip is behind wallet scan height (node still syncing).

Related

• Sending ZEC
• Keystone Hardware Wallet
• Troubleshooting
• Desktop README

Desktop App Troubleshooting

Cannot connect to node (NET_001)

The desktop app talks to Zebrad over JSON-RPC using zebra_url in your wallet config.

1. Confirm Zebrad is running (local machine, WSL, or remote VPS).
2. Settings → Network — check the URL and click Test Connection.
3. From a terminal: nozy test-zebra (same config the CLI uses).

If CLI succeeds but the browser tab at http://localhost:5173 fails, you opened the Vite dev server — use the NozyWallet taskbar window instead.

Full Zebrad ↔ NozyWallet guide (WSL, Windows ports, config paths): connectivity reference.

Sync says success but send is blocked

Scan height at tip does not guarantee witness freshness. Check the sync status on Home (blocks behind, witness lag). Run Sync again and wait until witness lag is within the send guard (≤ 50 blocks).

Sync / blocks not moving

• Verify the node tip is advancing: nozy test-zebra or raw getblockcount.
• WSL IP may change after reboot — update zebra_url if Zebrad runs in WSL.
• Run .\scripts\test-zebrad-nozywallet.ps1 from the repo for a consolidated check (Windows).

Getting help

• Common issues
• GitHub Issues
• Zebrad node setup (book)

Command Overview

The nozy CLI is the primary production surface for Orchard shielded ZEC on mainnet.

cargo build --release --bin nozy
./target/release/nozy --help

Global flags (common):

Config persists in platform config dir — see Zebra Node Setup.

Core commands

Extended commands

Optional feature builds:

cargo build --features secret-network   # adds `shade`

Typical workflow

nozy test-zebra
nozy sync --to-tip
nozy balance
nozy send -r u1… -a 0.0001

Chapters

• Wallet Commands
• Transaction Commands
• Advanced Commands

More: root COMMAND_HELP.md if present in your checkout.

Wallet Commands

nozy new

Create a new wallet and display a 24-word mnemonic. Store it offline immediately.

nozy new

nozy restore

Restore from mnemonic (interactive).

nozy restore

nozy receive

Generate a shielded Orchard unified address.

nozy receive

nozy info

Wallet addresses, network, and metadata.

nozy info

nozy balance

Current shielded balance (spendable notes).

nozy balance

If balance shows 0 incorrectly on v2 note index, see CLI balance reference and try list-notes.

nozy list-notes

List Orchard notes with amounts and heights.

nozy list-notes

nozy status

Sync checkpoint, chain tip, witness lag summary.

nozy status

Use before send to confirm catch-up.

nozy config

Configure network and node URL.

nozy config --set-zebra-url http://127.0.0.1:8232
nozy config --set-network mainnet
nozy config --use-local
nozy config --use-remote http://vps:8232

Environment override: ZEBRA_RPC_URL=http://host:8232.

nozy proving

Orchard Halo2 proving parameters (~large download, once per machine).

nozy proving --download
nozy proving --status

nozy address-book

Manage saved addresses from CLI.

nozy address-book list
nozy address-book add --name Alice --address u1…
nozy address-book remove --name Alice

Multi-wallet (desktop)

CLI historically used a single data dir; desktop supports profiles under %APPDATA%\nozy\nozy\data\profiles\. CLI profile switching follows wallet_profiles in core — check your build’s nozy --help for profile flags if available.

See Wallet Management.

Transaction Commands

nozy sync

Scan the chain for incoming notes and update witnesses.

# Incremental (default chunk)
nozy sync

# Full catch-up to chain tip
nozy sync --to-tip

# Height range
nozy sync --start-height 3380000 --end-height 3381000

# Override node for this run
nozy sync --to-tip --zebra-url http://host:8232

Before sending: run --to-tip and confirm nozy status shows acceptable witness lag.

nozy send

Shielded Orchard send to a unified address (u1…).

nozy send -r u1qr0zfsta9… -a 0.0001
nozy send -r u1… -a 0.0001 --memo "note text"
nozy send -r u1… -a 0.0001 --zebra-url http://host:8232

Expect minutes for first prove in a session. ZIP-317 fee policy applies automatically in current builds.

nozy history

Local transaction history (sent and detected receives where indexed).

nozy history

nozy check-confirmations

Look up confirmation depth for a TXID.

nozy check-confirmations -t <txid>

Send readiness guards

The wallet may reject send when:

• Witness lag > 50 blocks (MAX_SEND_WITNESS_LAG_BLOCKS)
• Insufficient spendable balance for amount + fee
• Node unreachable or tip stale vs expiry window

See Mainnet send evidence for timing and expiry behavior.

Fees

Orchard ZIP-317 conventional fee is computed in the transaction builder — no separate estimatefee RPC (Zebrad does not mirror zcashd fee estimation).

Desktop: estimate_fee Tauri command for UI preview.

Related

• Sending ZEC
• Transaction History

Advanced Commands

nozy test-zebra

Verify JSON-RPC to Zebrad, Zakura, or Crosslink (if configured). Detects node kind from getnetworkinfo and probes z_gettreestate at tip.

nozy test-zebra
nozy test-zebra --zebra-url http://172.x.x.x:8232

First diagnostic step for any sync/send issue.

nozy lwd

lightwalletd compact-block cache via Zeaking (shared with desktop and api-server).

nozy lwd --help
# Subcommands vary: info, sync, sync-to-tip, prune, etc.

Default gRPC: http://127.0.0.1:9067 or LIGHTWALLETD_GRPC.

Requires protoc at build time. See zeaking/README.md.

nozy zeaking

Local blockchain indexer utilities.

nozy zeaking --help

nozy analytics

Wallet statistics and usage summary.

nozy analytics

nozy privacy-network

Tor / I2P connection testing (experimental).

nozy privacy-network --help

Book: Privacy Networks (experimental).

nozy nu61

Display NU 6.1 / protocol information.

nozy nu61

nozy shade (feature secret-network)

Secret Network / Shade Protocol — build with:

cargo build --release --features secret-network --bin nozy
nozy shade balance

See Secret Network.

nozy swap / nozy monero

Cross-chain and Monero integrations — experimental; may not compile on default feature set.

Diagnostics

Reference: Zebrad connectivity.

api-server mirror

Many CLI operations have HTTP equivalents on localhost:3000 — API Server Setup.

Security Best Practices

Custody

• You control keys — no recovery if mnemonic is lost.
• Verify receive addresses on a second device before large deposits.

Mnemonic

• Write at creation; never store in cloud notes or email.
• Two offline copies in separate locations.
• Test restore once before mainnet funds.

Password

• Unique strong password for wallet encryption.
• Lock wallet when stepping away (desktop).

Node trust

• Prefer your own Zebrad or a VPS you operate.
• RPC provider sees broadcast timing and IP metadata.

Updates

• Build from tagged releases or verify release signatures when published.
• Run cargo audit if building from source.

Phishing

• NozyWallet will never ask for your seed in chat or email.
• Download only from official GitHub releases.

Shielded-only default

Orchard-only design avoids accidental transparent-address mistakes.

Hardware wallet (Keystone)

• Use mainnet on both NozyWallet and Keystone.
• Verify amount and recipient on the Keystone screen before signing.
• UFVK export is read-only but privacy-sensitive — pair only with your device.
• Guide: Keystone Hardware Wallet.

Related

• Private Key Management
• Keystone Hardware Wallet
• Backup Strategies
• Security Audits
• Security Features

Private Key Management

NozyWallet derives keys from a BIP39 mnemonic using standard Zcash Orchard HD paths.

What you hold

Private keys are not displayed in normal UI. Optional CLI/settings paths may expose viewing keys for advanced debugging — treat as sensitive.

Derivation

• HD wallet follows Bcash/Zcash conventions in hd_wallet / orchard integration.
• Optional Secret Network path shares mnemonic, different derivation — see Secret Network.

Storage

Encrypted at rest — see Wallet Storage.

• Argon2 / PBKDF-style password protection in core library
• zeroize for sensitive buffers where applicable

Operational rules

1. Never paste mnemonic into websites.
2. Never photograph seed on a networked phone.
3. Hardware wallet: Keystone on Zcash mainnet — Keystone Hardware Wallet. Seed stays on device; Nozy builds PCZT for air-gapped signing.
4. Compromised machine → move funds to new wallet on clean device with new seed.

Recovery

Only via mnemonic or encrypted backup — no “forgot password” server reset.

Related

• Backup Strategies
• Security Best Practices
• Keystone Hardware Wallet

Keystone Hardware Wallet

NozyWallet supports Keystone as an air-gapped hardware signer for Zcash mainnet Orchard sends. Keystone holds spend authority; NozyWallet builds proved transactions (PCZT), shows QR codes for signing, and broadcasts the signed result.

Network: Keystone integration is mainnet only. Testnet wallets cannot enable Keystone pairing or PCZT sends.

Where to find it in NozyWallet

What Keystone does (and does not do)

Prerequisites

1. Zcash mainnet wallet in NozyWallet (network: mainnet in config — default).
2. Zebrad + sync — wallet synced to tip before sending (Zebra Node Setup).
3. Keystone device set to Zcash mainnet with firmware that supports Zcash PCZT (zcash-pczt UR type).
4. Matching keys — Keystone must control the same Orchard account as NozyWallet (see setup paths below).

Setup (pairing)

Path A — Seed on Keystone (recommended)

1. Create or restore your Zcash wallet on Keystone (mainnet).
2. On Keystone, export the UFVK (unified full viewing key).
3. In NozyWallet, import or restore the same mnemonic so sync and PCZT building work locally.
   Alternatively, store only the UFVK in Nozy config for watch-only sync if your workflow uses Keystone as the sole signer — spending still requires the seed on Keystone.
4. Settings → Keystone → Export UFVK (or confirm stored UFVK matches Keystone). Mainnet UFVKs start with uview1.
5. Import that UFVK on Keystone if not already paired; confirm the same unified receive address (u1…) on both devices.
6. Enable Keystone.

Path B — Seed in NozyWallet first

1. Create or restore wallet in NozyWallet (mainnet).
2. Settings → Keystone → Export UFVK → import on Keystone.
3. Import the same mnemonic into Keystone so it can sign PCZTs.
4. Confirm matching u1… receive address.
5. Enable Keystone.

UFVK is read-only. It can reveal shielded activity to whoever holds it. It cannot spend funds. See Private Key Management.

Sending with Keystone (desktop)

1. Ensure Settings → Keystone shows Enabled and mainnet.
2. Open Send — you should see Keystone signing enabled (mainnet).
3. Enter recipient (u1…), amount, optional memo → Review & prepare.
4. Prepare for Keystone — proving may take several minutes on first send.
5. Scan the PCZT QR on Keystone (multiple UR frames if shown — scan all).
6. Sign on Keystone.
7. Paste signed PCZT hex or UR frames back into NozyWallet.
8. Broadcast signed tx — transaction is submitted via your Zebrad node.

Success shows a txid and a link to mainnet.zcashexplorer.app.

Sending with Keystone (mobile + API)

When using the mobile app with nozywallet-api:

1. Open Keystone from the dashboard.
2. Enable Keystone and export UFVK for pairing (same as desktop).
3. Prepare for Keystone → scan UR on device → paste signed data → Broadcast signed tx.

API calls mirror the desktop Tauri commands — useful for automation or custom frontends.

Receiving ZEC

• Into NozyWallet: Share your Nozy Receive address (u1…). Anyone (including Keystone) can send shielded ZEC to it.
• From Keystone to NozyWallet: Use Keystone’s send UI with your Nozy receive address, or use the PCZT flow above with Nozy as the builder/broadcaster.

If Keystone and Nozy share the same wallet, synced balance appears in Nozy after compact sync — no separate “receive from Keystone” step.

API endpoints

Local companion only (nozywallet-api, default http://127.0.0.1:3000):

See API Server Setup for running the companion.

Troubleshooting

More: Common Issues, Desktop Troubleshooting.

Security notes

• Treat UFVK export like sharing a read-only copy of your shielded history.
• Verify recipient and amount on Keystone’s screen before signing.
• Air-gapped signing reduces hot-wallet exposure; proving still runs on the Nozy machine.
• Back up your mnemonic — Keystone and/or Nozy depending on where the seed lives (Backup Strategies).

Related

• Security Best Practices
• Private Key Management
• Sending ZEC
• Using the GUI
• Security FAQ

Backup Strategies

NozyWallet is self-custodial. If you lose your mnemonic and have no backup, funds are unrecoverable.

Strategy 1 — Mnemonic only (minimum)

• Write the 24-word phrase at creation.
• Store in two physically separate safe locations (e.g. home safe + bank box).
• Never type it into websites, chat, or cloud notes.

Pros: Works everywhere (CLI, desktop, future mobile).
Cons: Single point of failure if one copy is lost or stolen.

Strategy 2 — Mnemonic + encrypted file backup

• Keep mnemonic as primary.
• Periodically export encrypted backup from desktop (or CLI backup commands when available).
• Store backup file on encrypted USB or offline media — not the same bag as the paper mnemonic.

Pros: Faster restore on same machine; includes local note index state.
Cons: File still needs your wallet password; less portable than mnemonic alone.

Strategy 3 — Test restore

Before holding meaningful funds:

1. Create a test wallet or profile.
2. Record mnemonic.
3. Delete profile or use a second machine.
4. Restore and sync.
5. Confirm addresses match.

Do this once per major version upgrade if you change backup tooling.

Operational rules

Multi-wallet profiles

Desktop supports multiple profiles under one install. Each profile has its own mnemonic and data folder. Back up each profile you use — switching profile does not merge backups.

Related

• Backup & Recovery
• Private Key Management
• Wallet Storage

Security Audits

NozyWallet handles keys, mnemonics, and shielded transaction data. Security review is ongoing; this page summarizes current status and how to verify dependencies locally.

Dependency auditing

Run from the repository root:

cargo audit
cargo fmt --all -- --check
cargo clippy -- -D warnings

CI enforces formatting on pushes and PRs. Use cargo audit after dependency changes.

Documented dependency fixes

Internal tracking (AUDIT_STATUS.md in the repo) records dependency updates including:

• curve25519-dalek, ed25519-dalek, tracing-subscriber — updated to patched versions (Dec 2025 cycle).

Verify with cargo audit; expect zero known vulnerabilities on supported builds or only unmaintained-crate warnings.

Scope of review

Responsible disclosure

Do not file public GitHub issues for undisclosed exploits. Follow CONTRIBUTING.md and contact maintainers privately for suspected vulnerabilities.

Self-audit guide

Contributors can use SELF_SECURITY_AUDIT_GUIDE.md for checklist-style review (address validation, RPC trust, storage encryption, etc.).

AI-assisted prep pack (2026-08)

In-repo Least Authority–style self-review (CLI + core + Desktop): docs/reference/security-audit/. Includes threat model, leads table, triaged findings, and an engagement SOW paste. This is not a Least Authority certificate.

Third-party audits

No independent third-party audit certificate is claimed in this book. For grant or production submissions, attach:

• cargo audit output
• Relevant BUG registry entries (docs/issues/BUG_REGISTRY.md)
• Mainnet evidence docs (docs/reference/MAINNET_SEND_READINESS_EVIDENCE.md, MAINNET_IRONWOOD_MIGRATION_EVIDENCE.md)
• Prep findings (with honest “self-triaged” label): docs/reference/security-audit/FINDINGS.md

Roadmap

Formal external audit before broad retail release is tracked on Enhancement Roadmap. Engagement brief: ENGAGE_LEAST_AUTHORITY.md.

Network Configuration

Configure which Zcash network and backend nodes NozyWallet uses.

Config file

Common fields:

{
  "zebra_url": "http://127.0.0.1:8232",
  "last_scan_height": 3395000,
  "privacy_network": "mainnet"
}

Environment overrides

CLI

nozy config --set-network mainnet
nozy config --set-network testnet
nozy config --set-zebra-url http://host:8232
nozy config --use-local
nozy config --use-remote http://vps:8232

Desktop

Settings → Network — edit URL, Test Connection.

Backend selection

Default: Zebrad or Zakura JSON-RPC (Zebra-fork compatible). Optional Crosslink backend via nozy config flags — see nozy config --help in your build.

UTF-8 BOM note

Editing config.json with PowerShell can add a BOM. Current releases strip BOM on load; prefer UTF-8 without BOM when hand-editing.

Trust

Configured zebra_url is trusted for broadcast and chain tip. Optional trusted_zebra_urls list in config for additional endpoints.

Related

• Zebra Node Setup
• Zakura Node Setup
• Zebrad connectivity reference
• Zakura connectivity reference

Zebra Node Setup

NozyWallet is an Orchard wallet — not a Zcash consensus node. For sync, broadcast, and treestate you need a running Zebrad or Zakura instance with JSON-RPC enabled.

For a full operator guide (lectures, papers, Windows + WSL checklists), see Zebrad ↔ NozyWallet connectivity in the repo docs. For Zakura, see Zakura ↔ NozyWallet connectivity and the Zakura book chapter.

Quick setup

1. Install and configure Zebrad

# ~/.config/zebrad.toml  (Linux/macOS)
# %LOCALAPPDATA%\zebrad.toml  (Windows — authoritative path)

[rpc]
listen_addr = "127.0.0.1:8232"

On Windows, if port 8232 is already in use, pick another port (e.g. 18232) and use that in the wallet config.

Start the node:

zebrad start

2. Point NozyWallet at RPC

CLI:

nozy config --set-zebra-url http://127.0.0.1:8232
nozy test-zebra

Desktop: Settings → Network → set node URL → Test Connection.

Config file locations:

Optional override for one session: ZEBRA_RPC_URL=http://host:port.

3. Zebrad in WSL, wallet on Windows

Zebrad often runs inside WSL while the desktop app runs on Windows. Localhost on Windows is not the same as localhost inside WSL unless you set up forwarding.

wsl hostname -I          # note the IP
nozy config --set-zebra-url http://<wsl-ip>:8232
nozy test-zebra

Or dot-source scripts/zebra-wsl-rpc.ps1 from the repo to set ZEBRA_RPC_URL automatically.

Verify connectivity

Pass: block height returned and increasing over time; last_scan_height catches up to tip after sync.

What Zebrad does not do

Orchard witnesses are derived in the wallet using treestate from RPC — Zebrad does not serve wallet witnesses. See ZEBRAD_SHIELDED_SEND_LIMIT.md.

Troubleshooting

Detailed RCA and Windows port notes: desktop pre-release debug session.

Zakura Node Setup

NozyWallet works with Zakura — a Zebra-fork full node — using the same config as Zebrad. You do not need Zakura’s zcashd compatibility mode.

Full operator guide: Zakura ↔ NozyWallet connectivity.

Quick setup

1. Configure Zakurad

# ~/.config/zakurad.toml

[rpc]
listen_addr = "127.0.0.1:8232"
enable_cookie_auth = false   # lightwalletd + local dev

zakurad start

2. lightwalletd

Point lightwalletd at Zakura RPC (127.0.0.1:8232). See Zakura’s lightwalletd book chapter.

3. Point NozyWallet

nozy config --set-zebra-url http://127.0.0.1:8232
nozy test-zebra    # detects Zakura + probes z_gettreestate
nozy sync --to-tip

Zebrad or Zakura?

Both use port 8232 (mainnet) and the same zebra_url setting.

Troubleshooting

See the connectivity guide and ZEBRAD_SHIELDED_SEND_LIMIT.md.

Proving Parameters

Orchard shielded spends require Halo2 proving parameters (large files, downloaded once per machine).

Download

nozy proving --download
nozy proving --status

Desktop: Settings → Proving or automatic download on first send.

Size and location

Parameters are cached on disk in the platform cache directory (see proving.rs / OS-specific paths). Expect hundreds of MB download.

First send latency

First prove in a session loads/builds proving keys — often 1–3+ minutes additional wall time. Warm subsequent sends are faster.

CLI and api-server may call warm_orchard_proving_key() at unlock/startup in some builds.

Offline / airgap

Download on a networked machine first, then copy cache directory per operator docs for your OS version.

Failure

Related

• Quick Send Tutorial
• Mainnet send timings

API Server Setup

The api-server exposes NozyWallet over HTTP for browser extensions and local dashboards.

Build and run

cd api-server
cargo build --release
cargo run
# listens on http://0.0.0.0:3000

Requires: protoc for zeaking gRPC codegen.

Use cases

• Chrome/Edge extension companion (browser-extension/COMPANION.md)
• Local React dashboard without Tauri
• Integration tests against HTTP

Not intended as a public internet wallet API without additional auth and TLS hardening.

Quick endpoint list

Full list: api-server/README.md.

Sync semantics

Default sync: incremental from last_scan_height + 1, up to 1000 blocks per call. Repeat until already_synced: true.

Rescan: pass start_height / end_height in POST body.

Shielded sends

Same Orchard path as CLI — local witness derivation. See ZEBRAD_SHIELDED_SEND_LIMIT.md.

Chapters

• API Overview
• Integrate with Frontend

Secret Network (ZEC + Secret from One Seed)

NozyWallet can optionally derive Secret Network (SCRT) keys from the same BIP39 mnemonic as your Zcash Orchard wallet — one backup, two shielded ecosystems.

Status: Optional CLI feature. Build with --features secret-network. Not enabled in default desktop release builds.

One seed, two chains

The mnemonic is identical; derivation paths differ per chain. One 24-word backup recovers both when the feature is enabled.

Build and enable

cargo build --release --features secret-network --bin nozy

Requires network access to Secret RPC endpoints configured in your environment (see repo research doc below).

CLI (nozy shade)

After building with the feature:

nozy shade balance      # SCRT / token balances
nozy shade receive      # Deposit address
nozy shade send         # Send SCRT or tokens (subcommands vary by build)
nozy shade history      # Transaction history

Run nozy shade --help for the exact subcommands in your version.

Desktop and mobile

• Desktop: ZEC-first; Secret UI is not the default shipping surface.
• Mobile / FFI: Shared nozy core patterns; Secret paths follow CLI feature flags.

Security notes

• Same rules as ZEC: never share mnemonic.
• Secret RPC endpoints are trust assumptions — use nodes you control or explicitly trust.
• Optional integration code may lag core ZEC paths; treat as experimental until listed in release notes.

Further reading

• Repository: SECRET_NETWORK_RESEARCH_AND_BUILD.md (implementation plan)
• Root README: Unified privacy wallet
• ZEC setup still required: Zebra Node Setup

API Overview

NozyWallet HTTP API is served by api-server on port 3000 by default.

Base URL

http://127.0.0.1:3000

Bind to localhost only in production companion setups.

Authentication

Wallet operations require unlock with password in POST body where the wallet is encrypted. No OAuth — local trust model.

See Authentication.

Response shape

JSON with success, message, and optional data / error code. Mirrors Tauri error patterns where possible.

Endpoint groups

Companion pattern

Chromium MV3 extensions should not run gRPC/SQLite in the service worker. Call this server from the extension with host_permissions for 127.0.0.1:3000.

Setup

API Server Setup

Source: api-server/README.md

Authentication

Model

• Localhost companion — api-server trusts whoever can reach the port.
• Encrypted wallet — sensitive routes require password in JSON body to unlock in-memory session for the request or session lifetime.

Unlock

POST /api/wallet/unlock
Content-Type: application/json

{ "password": "your-wallet-password" }

Create / restore

POST /api/wallet/create
POST /api/wallet/restore

Body includes password and optional mnemonic on restore.

Security guidance

• Bind to 127.0.0.1 only.
• Do not expose port 3000 to the internet without reverse proxy, TLS, and strong auth redesign.
• Extension: restrict to packaged extension origins via companion design.

Desktop contrast

Tauri uses OS process isolation + invoke IPC — no HTTP password on wire for normal desktop use.

Related

• Wallet Endpoints
• API Server Setup

Wallet Endpoints

Base: http://127.0.0.1:3000

GET /api/wallet/exists

Check if wallet file exists.

POST /api/wallet/create

Create wallet. Body: { "password": "…" }. Returns mnemonic in response — handle securely.

POST /api/wallet/restore

Body: { "mnemonic": "…", "password": "…" }.

POST /api/wallet/unlock

Body: { "password": "…" }.

Status

Some builds expose wallet lock state via additional routes — check OpenAPI or api-server/src handlers in repo.

CLI equivalents: nozy new, nozy restore.

See api-server/README.md.

Transaction Endpoints

POST /api/transaction/send

Shielded Orchard send.

Body (typical):

{
  "recipient": "u1…",
  "amount": 0.0001,
  "memo": "optional",
  "password": "…",
  "zebra_url": "optional override"
}

Response: { "success": true, "txid": "…" } or error with message/code.

Send guards

Same as CLI:

• Witness lag limit
• Sync-to-tip recommendations
• Insufficient funds
• Invalid unified address

Confirmations

Use Zebrad getrawtransaction or explorer; optional CLI check-confirmations.

History

Local sent tx list may be exposed in extended API builds — check handlers. Desktop uses Tauri get_transaction_history.

CLI: nozy history.

See Transaction Commands.

Address Endpoints

POST /api/address/generate

Generate new Orchard receiving address.

Body may include password if wallet locked.

Response: unified address string (u1…).

CLI equivalent: nozy receive.

Tauri: generate_address.

Validation

Recipients for send must be unified addresses with Orchard receiver. Transparent addresses rejected.

See Address Management.

Balance & Sync Endpoints

GET /api/balance

Returns shielded balance after wallet unlock / scan.

POST /api/sync

Scan blockchain for notes.

Default: incremental from last_scan_height + 1, max ~1000 blocks per request. Loop until caught up.

GET /api/config

Returns zebra_url, last_scan_height, network settings.

lightwalletd (Zeaking)

Query/body: optional lightwalletd_url, db_path.

Shared implementation with Tauri lwd_* commands and zeaking-ffi.

CLI equivalents

nozy balance
nozy sync --to-tip
nozy lwd …

Doc: docs/issues/api-sync-scan-height-response.md

Configuration Endpoints

GET /api/config

Read wallet configuration including:

• zebra_url
• last_scan_height
• Theme / network fields (build-dependent)

POST /api/config/zebra-url

Body: { "url": "http://host:8232" }

POST /api/config/theme

UI theme preference for companion frontends.

CLI equivalent

nozy config --set-zebra-url http://127.0.0.1:8232

File location

Same as Network Configuration — %APPDATA%\nozy\nozy\config\config.json on Windows.

No API to set last_scan_height while server running — use sync ranges or stop server and edit config for advanced rescans.

Proving Parameters Endpoints

Orchard spends require downloaded proving parameters.

Routes vary by api-server version — typical patterns:

• GET status — params present / missing
• POST download — trigger official parameter fetch

CLI:

nozy proving --status
nozy proving --download

Tauri: check_proving_status, download_proving_parameters.

See Proving Parameters.

Error Codes

API and desktop share user-facing codes where mapped.

Network

Wallet / auth

Send / sync

Backend

Full desktop map: desktop-client/src/utils/errors.ts.

Human guide: Error Messages.

Zebra connect codes: nozy::zebra_connect_api_code() in Rust backend.

Privacy Networks Overview

NozyWallet can route some traffic through privacy networks (Tor, I2P) for metadata resistance when connecting to nodes or services.

Status: Experimental. Production ZEC path today assumes direct or VPN-protected Zebrad RPC.

Why privacy networks

• Hide wallet IP from RPC provider
• Reduce network-level correlation

What they do not hide

• On-chain shielded cryptography (already private for amounts/parties in Orchard)
• Malicious RPC — use trusted nodes regardless of Tor

CLI entry

nozy privacy-network --help

Subcommands test connectivity and configure proxies per build.

Chapters

• Tor Integration
• I2P Integration
• Setup Guide

Related

• Network Configuration
• Security Features

Tor Integration

Route selected NozyWallet connections over Tor (experimental).

Requirements

• Tor daemon or Tor Browser SOCKS proxy running locally
• nozy privacy-network subcommands supported in your build

Typical SOCKS

Default Tor SOCKS: 127.0.0.1:9050

Configuration varies by platform — see CLI help output for current flags.

Zebrad over Tor

Running Zebrad as a hidden service or connecting to .onion RPC is an advanced operator setup. Document your onion URL in zebra_url if used:

nozy config --set-zebra-url http://youronion.onion:8232

Latency and sync time increase significantly.

Limitations

• Not all builds test Tor paths in CI
• lightwalletd gRPC over Tor may need additional proxy configuration

See Setup Guide.

I2P Integration

I2P support for privacy-network routing in NozyWallet is experimental.

CLI

nozy privacy-network --help

Look for I2P-related subcommands in your version.

Use case

Similar to Tor — hide client IP when talking to RPC or swap services. Requires I2P router running locally.

Status

Less tested than direct RPC and Tor paths. Treat as research / contributor feature until listed in release notes.

Related

• Privacy Networks Overview
• Setup Guide

Privacy Network Setup

Experimental checklist for Tor/I2P with NozyWallet.

1. Base wallet works without proxy

nozy test-zebra
nozy sync --to-tip

Fix Zebra connectivity first.

2. Start privacy network

Tor: system Tor service or Tor Browser with SOCKS on 9050.

I2P: I2P router with documented SOCKS/http tunnel ports.

3. Configure Nozy

nozy privacy-network --help

Apply flags or config per subcommand output — interfaces evolve between releases.

4. Verify

• RPC still reaches Zebrad (may be slower)
• Sync completes
• Send dust on testnet before mainnet

5. Operational notes

• Backup mnemonic before experimenting
• Expect higher latency and timeouts (adjust patience / NET_002)
• Document your RPC URL scheme for lectures

Related

• Tor Integration
• I2P Integration

Quick Send Tutorial

Send a small shielded ZEC transaction end-to-end.

Prerequisites

• Zebrad running — nozy test-zebra OK
• Wallet funded (shielded balance > 0)
• Recipient u1… address

CLI path

# 1. Verify node
nozy test-zebra

# 2. Sync
nozy sync --to-tip

# 3. Check balance
nozy balance

# 4. Send dust amount
nozy send -r u1RECIPIENT… -a 0.0001

# 5. Confirm
nozy check-confirmations -t <txid>

First send may take 2–4+ minutes for Orchard proving.

Desktop path

1. Sync until caught up (Home strip shows 0 blocks behind).
2. Send tab → recipient → amount → confirm.
3. Enter password if prompted.
4. Wait for success toast with TXID.
5. History → explorer link.

Self-send test

Send to your own Receive address — valid regression test on mainnet with dust.

If send fails

Evidence and timings: mainnet send reference.

Next: Set Up Your Own Node

Backup Your Wallet

Step-by-step: create a durable backup before holding funds on mainnet.

Before you start

• Wallet created and unlocked once (so you have seen the mnemonic).
• Pen and paper or offline storage ready.

Option A — Mnemonic (all surfaces)

Desktop

1. Create wallet on Welcome → Create new wallet.
2. Copy the 24 words to paper when shown.
3. Complete the confirmation step if prompted.
4. Store paper offline.

CLI

nozy new
# Save the printed mnemonic immediately

Option B — Encrypted file (desktop)

1. Unlock wallet.
2. Open Settings → backup / security section.
3. Choose Export backup and pick a folder (e.g. encrypted USB).
4. Note the output path from the success message.

The backup requires your wallet password to restore.

Verify the backup

Mnemonic test (recommended):

1. On a second profile or machine, choose Restore.
2. Enter the 24 words.
3. Sync to tip and confirm the same receiving address as the original wallet.

File test:

1. Use a test profile.
2. Restore from backup file.
3. Unlock and sync.

Checklist

• 24 words written and stored in two places
• Optional encrypted export on offline media
• Test restore completed
• Zebrad connectivity verified (own node tutorial)

Next: Restore from Backup | Backup & Recovery

Restore from Backup

Recover a wallet from a mnemonic or encrypted backup file.

Restore from mnemonic

Desktop

1. Launch NozyWallet (taskbar window, not browser tab).
2. Welcome → Restore wallet.
3. Enter all 24 words in order.
4. Set a new password (can match old password).
5. Unlock → Sync to tip.

CLI

nozy restore
# Paste mnemonic when prompted
nozy sync --to-tip
nozy balance

Restore from backup file (desktop)

1. Welcome or Settings → Restore from backup.
2. Select the .backup / wallet backup file path.
3. Enter password used when backup was created.
4. Unlock again (session cleared after restore).
5. Sync to tip before sending.

Restore on a new computer

1. Install NozyWallet (Installation).
2. Install or connect to Zebrad (Set Up Your Own Node).
3. Set zebra_url in config or Settings.
4. Restore mnemonic or file.
5. Run nozy test-zebra or Settings → Test Connection.
6. Sync until last_scan_height matches chain tip.

Multi-wallet profiles

If you used multiple profiles on the old machine:

• Each profile has its own mnemonic.
• Restore creates a new profile entry — name it to match your old label.
• Old profile IDs are not preserved; data paths are new UUIDs.

Troubleshooting

See Backup & Recovery.

Set Up Your Own Node

Run Zebrad so NozyWallet talks to infrastructure you control.

Full reference: Zebrad ↔ NozyWallet connectivity.

1. Install Zebrad

Follow Zebra Foundation docs. Build or install zebrad for your OS.

2. Enable RPC

# Linux: ~/.config/zebrad.toml
# Windows: %LOCALAPPDATA%\zebrad.toml

[rpc]
listen_addr = "127.0.0.1:8232"
enable_cookie_auth = false

Windows port 8232 conflict → use 18232 and match wallet config.

3. Start and wait for sync

zebrad start

Initial sync takes hours to days on mainnet depending on hardware.

4. Point NozyWallet

nozy config --set-zebra-url http://127.0.0.1:8232
nozy test-zebra

5. WSL + Windows wallet

Zebrad in WSL, desktop on Windows:

wsl hostname -I   # use first IP
nozy config --set-zebra-url http://<ip>:8232

Or: . .\scripts\zebra-wsl-rpc.ps1

6. Optional: lightwalletd

For compact sync (extension / LWD paths):

• Run lightwalletd against your Zebrad
• Default gRPC http://127.0.0.1:9067
• Set LIGHTWALLETD_GRPC if non-default

7. Verify stack

.\scripts\test-zebrad-nozywallet.ps1   # Windows smoke test

nozy sync --to-tip
nozy status

Checklist

• getblockcount increases over time
• nozy test-zebra passes from wallet host
• config.json URL matches live node
• Wallet sync completes to tip

See Zebra Node Setup | Network Configuration

Integrate with Frontend

NozyWallet exposes wallet logic through Tauri invoke (desktop), HTTP api-server (browser extension companion), and UniFFI (mobile). Pick the surface that matches your app.

Architecture

┌──────────────┐     invoke      ┌─────────────────┐
│ React / UI   │ ───────────────►│ Tauri commands  │──► nozy crate
└──────────────┘                 └─────────────────┘

┌──────────────┐     HTTP        ┌─────────────────┐
│ Extension /  │ ───────────────►│ api-server      │──► nozy + zeaking
│ web dashboard│   localhost:3000└─────────────────┘
└──────────────┘

Desktop (Tauri + React)

From desktop-client/src/lib/api.ts:

import { invoke } from "@tauri-apps/api/core";

const balance = await invoke<{ balance_zec: number }>("get_balance");
const tx = await invoke("send_transaction", {
  request: { recipient: "u1…", amount: 0.001, password: "…" },
});

Common commands: wallet_exists, create_wallet, unlock_wallet, get_balance, sync_wallet, send_transaction, get_sync_status, test_zebra_connection.

Full list: desktop-client/README.md.

Important: Run inside the Tauri webview, not a standalone browser at localhost:5173 — IPC is unavailable there.

HTTP api-server (extension companion)

Start locally:

cd api-server
cargo run
# http://127.0.0.1:3000

Example routes:

Browser extension setup: browser-extension/COMPANION.md.

Mobile (zeaking-ffi)

UniFFI bindings wrap the same sync and wallet primitives. Build from zeaking-ffi/ per that crate’s README.

Configuration shared by all surfaces

• Zebrad RPC — zebra_url in config or ZEBRA_RPC_URL
• lightwalletd — optional compact sync; default http://127.0.0.1:9067
• Proving params — download once per machine (nozy proving --download)

Error handling

Desktop maps Rust errors to codes (NET_001, SEND_001, …) in desktop-client/src/utils/errors.ts. HTTP API returns JSON { success, message, code? }.

Next steps

• API Overview
• Set Up Your Own Node
• Zebra Node Setup

Common Issues

Quick fixes for the problems operators hit most often. For Zebrad connectivity in depth, see Zebra Node Setup and the connectivity reference.

Cannot connect to node (NET_001)

Symptoms: Settings test fails; sync errors; nozy test-zebra fails.

Checks:

1. Zebrad running? Get-Process zebrad (Windows) or ps aux | grep zebrad (Linux).
2. RPC enabled in zebrad.toml — Windows: %LOCALAPPDATA%\zebrad.toml.
3. Correct URL in config — WSL users need WSL IP, not 127.0.0.1, unless forwarding is set up.
4. Port conflict — Windows may use 8232 for IP Helper; try 18232.

nozy test-zebra
nozy config   # show zebra_url

Desktop opened in browser instead of app

Symptoms: Every action fails; “use desktop window” style errors.

Fix: Close the browser tab at localhost:5173. Use the NozyWallet taskbar window from cargo tauri dev or the installed .exe.

Sync succeeds but send blocked

Symptoms: “Witness N blocks behind…” or “sync to tip before sending”.

Fix: Run sync to tip; wait for witness refresh. Scan height at tip ≠ witnesses fresh. Use desktop sync status or nozy status.

Balance shows zero (CLI)

Symptoms: nozy balance is 0 but notes exist.

Fix: Known v2 NoteIndex parser issue — see CLI balance reference. Try nozy list-notes or desktop balance; update to fixed build.

Send takes many minutes

Expected on first shielded send: Orchard proving (often 2–4 minutes on laptop-class CPU). Subsequent sends faster if proving key is warm.

Ensure witness lag ≤ 50 blocks before send — stale wallets spend time on witness catch-up.

Invalid recipient address

Unified Orchard addresses start with u1 (mainnet) or utest1 (testnet). Transparent t1 addresses are not supported.

Proving parameters missing

nozy proving --download
nozy proving --status

lightwalletd / compact sync timeout

Desktop send can hang on “Checking sync status…” if lightwalletd on 127.0.0.1:9067 is down. Start lightwalletd or wait for timeout; Zebrad RPC sync may still work via CLI.

Multi-wallet / wrong profile

Desktop Welcome lists profiles. Ensure the active profile matches the wallet you expect before send.

Keystone pairing or PCZT send fails

Symptoms: “Keystone requires mainnet”; UFVK export disabled; prepare/broadcast errors; Keystone rejects QR.

Checks:

1. Wallet config network must be mainnet (Keystone is not supported on testnet).
2. Keystone device set to Zcash mainnet — not testnet.
3. UFVK should start with uview1 on mainnet; re-export from Nozy Settings → Keystone.
4. Same mnemonic (or matching UFVK + seed on Keystone) — UFVK alone cannot sign.
5. Recipient must be u1… Orchard unified address.
6. Sync to tip before prepare; re-prepare if the signed PCZT expired.

Full guide: Keystone Hardware Wallet.

More: Error Messages | Desktop Troubleshooting | Getting Help

Error Messages

Desktop maps backend errors to short codes in desktop-client/src/utils/errors.ts. CLI often prints the raw Rust message.

Wallet & auth

Send

Network

Sync & proving

Backend

CLI-specific messages

Zebra RPC codes

nozy maps connect failures to structured codes via zebra_connect_api_code() for API clients. Use nozy test-zebra for a human-readable diagnosis first.

Fix guides: Common Issues | Zebra Node Setup

Getting Help

Before you ask

1. Common Issues — NET_001, sync, send stalls, Keystone pairing.
2. Keystone Hardware Wallet — PCZT signing with Keystone (mainnet).
3. Zebra Node Setup — verify nozy test-zebra.
4. Error Messages — match desktop codes.
5. Run diagnostics (Windows): .\scripts\test-zebrad-nozywallet.ps1 from repo root.

Gather this information

• OS (Windows / Linux / macOS) and Nozy surface (CLI, desktop, api-server).
• nozy test-zebra output (redact URLs if public).
• Whether Zebrad runs locally, WSL, or remote.
• Error code from UI (e.g. NET_001) — not your mnemonic or password.

Never share: 24-word seed, private keys, wallet password, or full wallet.dat.

Community & issues

• GitHub Issues — bugs and feature requests.
• GitHub Discussions — questions and setup help.

Search existing issues for NET_001, sync, witness lag, balance zero.

Maintainer docs (advanced)

Contributing fixes

See Contributing Guide and AGENTS.md for agent/human contributors.

General Questions

What is NozyWallet?

A shielded-first Zcash wallet built around Orchard, Ironwood (NU6.3), and Zebrad. See What is Nozy? and Why Ironwood?.

Does it support transparent ZEC?

No. Shielded Orchard / Ironwood only.

What is Ironwood and why did Nozy change?

Taylor Hornby (Shielded Labs) found a soundness bug in Orchard’s proof circuit. Ironwood seals the old pool and restores verifiable supply. Nozy migrates with the network. Full story: Why Ironwood?.

CLI vs desktop vs extension?

Which network?

Mainnet and testnet — configure via nozy config or Settings.

Do I need my own node?

Strongly recommended. Wallet needs a Zebra-family JSON-RPC node (Zebrad or Zakura); see Zebra Node Setup or Zakura Node Setup.

Where is data stored?

Platform app data dir — Backup & Recovery.

How do I get help?

Getting Help

Roadmap?

Contributing → Roadmap and ENHANCEMENT_ROADMAP.md.

How do I use a Keystone hardware wallet?

1. Open Settings → Keystone in the desktop app (or Keystone on mobile with the API companion).
2. Export your mainnet UFVK and import it on Keystone (device set to Zcash mainnet).
3. Enable Keystone — sends use Prepare → sign on device → broadcast.
4. Step-by-step: Keystone Hardware Wallet.

Privacy Questions

Are my transactions private?

Orchard and Ironwood shielded transactions hide amount, sender, and receiver on the public ledger. NozyWallet does not add transparent leakage by design. Migration (Orchard → Ironwood turnstile) is different: amounts are public by design — see Why Ironwood?.

Does NozyWallet phone home?

No telemetry that exfiltrates addresses, amounts, or seed by default project policy. Your RPC node still sees query/broadcast metadata.

Can I use a public RPC?

You can point zebra_url at a trusted VPS. Operator sees IP and timing — use Tor/VPN or own node for stronger metadata privacy.

Address reuse?

Reusing one unified address works but may reduce unlinkability. Generate fresh receive addresses when privacy matters.

Viewing keys?

Advanced / future documentation — default UI is spend/receive focused, not full viewing-key export.

Zcash vs Monero privacy model?

Nozy targets Monero-like default privacy using Zcash Orchard / Ironwood — see Privacy model.

Related

• Why Ironwood?
• Security Questions
• Absolute Privacy

Security Questions

Is NozyWallet custodial?

No. Keys and mnemonic stay on your device. Nozy does not hold funds or recovery phrases on your behalf.

What is encrypted on disk?

Wallet files (mnemonic-derived material, notes index) are encrypted with a password-derived key. See Wallet Storage.

Should I use a password?

Yes. Use a strong unique password for wallet unlock. It protects encrypted storage if someone copies your data directory.

How should I back up?

Primary: 24-word mnemonic on paper, offline.
Optional: encrypted export from desktop.
Details: Backup Strategies.

Does NozyWallet support transparent addresses?

No. Orchard shielded only — reduces accidental privacy leaks.

Is the desktop app safe to run from a browser tab?

No. Use the NozyWallet desktop window from the taskbar. Opening localhost:5173 in Chrome/Cursor has no wallet backend.

What RPC do I trust?

Your Zebrad (and optional lightwalletd) node sees broadcast metadata and sync queries. Run your own node or trust your VPS explicitly. See Zebra Node Setup.

Has the code been audited?

Dependency auditing is documented in Security Audits. No third-party audit certificate is claimed for all surfaces.

How do I report a vulnerability?

Private responsible disclosure — see Contributing Guide and root CONTRIBUTING.md. Do not post exploits publicly before coordination.

Are experimental features (Secret, Monero, swap) production-ready?

Treat optional CLI features as experimental unless listed in release notes. Default production path is Orchard ZEC via CLI and desktop.

Does NozyWallet support Keystone?

Yes — Zcash mainnet Orchard sends with air-gapped PCZT signing. Pair in Settings → Keystone (desktop) or the Keystone screen (mobile). Full guide: Keystone Hardware Wallet.

Is UFVK export safe?

UFVK is read-only — it reveals shielded activity to whoever holds it, but cannot spend. Use only for Keystone pairing or trusted watch-only setups. Never confuse UFVK with spending keys.

Can I use Keystone on testnet?

No. Keystone integration in NozyWallet is mainnet only. Use normal local signing on testnet if needed.

Technical Questions

Why Zebrad instead of zcashd?

JSON-RPC alignment with Zebra Foundation direction; wallet derives Orchard witnesses locally. See ZEBRAD_SHIELDED_SEND_LIMIT.md.

Why does send take minutes?

Orchard Halo2 proving + witness freshness. Timings: mainnet evidence.

What is witness lag?

Orchard spends need up-to-date witnesses. Scan height at tip ≠ witnesses fresh — check nozy status or desktop sync status.

What is lightwalletd for?

Compact block sync for extension/mobile paths via Zeaking — optional alongside Zebrad RPC scan.

Workspace crates?

nozy, zeaking, api-server, zeaking-ffi; desktop and WASM excluded from root workspace. Development Setup.

Feature flags?

secret-network enables nozy shade. Monero/swap/bridge may require additional flags — experimental.

NU 6.1 / 6.2 support?

See NU 6.1 Support and release CHANGELOG.

Build from source?

cargo build --release --bin nozy
cd desktop-client && cargo tauri build

Verify Zebrad connection?

nozy test-zebra

Guide: Zebrad connectivity.

How does Keystone PCZT signing work?

NozyWallet builds a proved PCZT (partial transaction), encodes it as zcash-pczt UR QR frames, Keystone signs offline, Nozy extracts and broadcasts. Mainnet Orchard only. Details: Keystone Hardware Wallet.

Glossary of Terms

A

Address

A string of characters used to receive cryptocurrency. In Zcash, addresses can be transparent (public) or shielded (private). NozyWallet only uses shielded Orchard addresses for complete privacy.

Argon2

A key derivation function used for password hashing in NozyWallet. Argon2 is designed to be memory-hard and resistant to both GPU and custom hardware attacks.

B

BIP39 (Bitcoin Improvement Proposal 39)

The standard for mnemonic seed phrases. NozyWallet uses 24-word BIP39 mnemonics to generate and recover wallets.

BIP32 (Bitcoin Improvement Proposal 32)

The standard for hierarchical deterministic (HD) wallets. Allows generating multiple keys from a single seed.

Block

A collection of transactions that have been validated and added to the blockchain. Zcash blocks are created approximately every 75 seconds.

Blockchain

A distributed ledger that records all transactions in blocks linked together cryptographically. Zcash uses a blockchain similar to Bitcoin but with privacy enhancements.

C

Commitment

A cryptographic commitment that hides the value and recipient of a transaction while still allowing verification. In Zcash, commitments are used in shielded transactions.

Confirmation

The process of a transaction being included in a block and added to the blockchain. Each subsequent block adds another confirmation.

D

Decryption

The process of converting encrypted data back into readable form. In Zcash, notes are encrypted and can only be decrypted by the recipient using their viewing key.

E

Encryption

The process of converting readable data into an unreadable format. In Zcash, transaction notes are encrypted so only the recipient can decrypt them.

F

Fungibility

The property of money where all units are interchangeable and indistinguishable. Shielded Zcash (ZEC) is fungible because transaction history is hidden.

G

Groth16

A zero-knowledge proof system used in Zcash. NozyWallet uses Groth16 proofs for transaction privacy.

H

HD Wallet (Hierarchical Deterministic Wallet)

A wallet that can generate multiple addresses from a single seed phrase. All addresses are derived deterministically, making backup and recovery easier.

I

I2P (Invisible Internet Project)

A privacy network that provides anonymous communication. NozyWallet can be configured to route transactions through I2P for additional privacy.

Ironwood

Zcash’s next shielded pool (network upgrade NU6.3). Built to restore verifiable circulating-supply soundness after the Orchard circuit issue: seal the old Orchard pool, use a corrected circuit in a new pool, and move value through a turnstile. NozyWallet supports Ironwood scan, migrate, and post-activation sends. See Why Ironwood?.

K

Keystone

Air-gapped hardware wallet supported by NozyWallet for Zcash mainnet Orchard signing. Nozy builds a PCZT; Keystone signs via QR; Nozy broadcasts. See Keystone Hardware Wallet.

Key Derivation

The process of generating cryptographic keys from a master seed or password. NozyWallet uses BIP32 for hierarchical key derivation.

M

MOE (Medium of Exchange)

One of the three primary functions of money. MOE refers to money's ability to be used as an intermediary in trade to avoid the inconveniences of a barter system. Zcash functions as a medium of exchange, allowing users to buy goods and services privately.

Mnemonic Phrase

A sequence of words (typically 12, 18, or 24 words) that can be used to recover a wallet. NozyWallet uses 24-word BIP39 mnemonic phrases.

Memo

An optional text field in Zcash transactions. Memos in shielded transactions are encrypted and can only be read by the recipient.

N

Note

A unit of value in Zcash's shielded pools. Notes contain encrypted information about the amount, recipient, and memo of a transaction.

Nullifier

A cryptographic value that proves a note has been spent without revealing which note was spent. Prevents double-spending while maintaining privacy.

NU 6.1 (Network Upgrade 6.1)

Zcash network upgrade activated at block 3,146,400 (November 23, 2025). Protocol version 170140.

NU 6.3 (Ironwood)

Network upgrade that activates Ironwood: seals the legacy Orchard pool and introduces the Ironwood shielded pool for verifiable supply soundness. Mainnet target height 3,428,143 (2026-07-28). See Why Ironwood?.

O

Orchard

Zcash’s Halo 2 shielded pool used before Ironwood (NU6.3). Orchard hides sender, receiver, and amount. In 2026 a circuit soundness bug was found (see Why Ironwood?); after Ironwood activates, ordinary Orchard activity is sealed and value migrates via turnstile into Ironwood.

P

PCZT (Partially Created Zcash Transaction)

A portable transaction format used for hardware-wallet and multi-step signing. NozyWallet builds and proves a PCZT locally, Keystone adds spend signatures, then Nozy extracts and broadcasts the final v5 transaction.

Privacy

The ability to keep financial information confidential. NozyWallet enforces privacy by default by only supporting shielded transactions.

Proving Parameters

Large parameter files needed to generate zero-knowledge proofs for Zcash transactions. NozyWallet manages the download and storage of these parameters automatically.

S

Shielded Transaction

A Zcash transaction that hides the sender, receiver, and amount using zero-knowledge proofs. All NozyWallet transactions are shielded.

SOV (Store of Value)

One of the three primary functions of money. SOV refers to money's ability to maintain its purchasing power over time. Zcash, like Bitcoin, can function as a store of value due to its fixed supply cap and scarcity. With privacy guarantees, Zcash may offer superior store of value properties as it cannot be "tainted" or blacklisted.

Seed Phrase

See "Mnemonic Phrase"

Spending Key

A private key that allows you to spend notes. Must be kept secret and secure.

T

Tor (The Onion Router)

A privacy network that routes internet traffic through multiple encrypted layers. NozyWallet can be configured to route transactions through Tor for additional anonymity.

Transaction

A transfer of value from one address to another. In Zcash, transactions can be transparent or shielded. NozyWallet only supports shielded transactions.

Transparent Transaction

A Zcash transaction where the sender, receiver, and amount are visible on the blockchain. NozyWallet does not support transparent transactions to ensure complete privacy.

U

UOA (Unit of Account)

One of the three primary functions of money. UOA refers to money's use as a standard measure for valuing goods, services, and assets. ZEC (Zcash) can function as a unit of account, with prices denominated in ZEC. This is particularly useful for private commerce where transactions are hidden but still need a standard valuation.

Unified Address

A Zcash address format that can contain multiple address types. NozyWallet extracts Orchard addresses from unified addresses.

V

Viewing Key

A key that allows viewing incoming transactions but not spending them. Useful for monitoring balances without the ability to send funds.

Z

ZEC

The ticker symbol for Zcash, the cryptocurrency. 1 ZEC = 100,000,000 zatoshis (the smallest unit).

Zcash

A privacy-focused cryptocurrency that uses zero-knowledge proofs to hide transaction details. NozyWallet is a wallet for Zcash.

Zero-Knowledge Proof

A cryptographic proof that allows you to prove you know something without revealing what it is. Zcash uses zero-knowledge proofs (specifically Groth16) to prove transactions are valid without revealing amounts or addresses.

Zatoshis

The smallest unit of Zcash. 1 ZEC = 100,000,000 zatoshis (10^8). Named after Zcash founder Zooko Wilcox-O'Hearn.

Economic Functions of Money

Money traditionally serves three primary functions, and Zcash (ZEC) can fulfill all three:

SOV (Store of Value)

Zcash maintains purchasing power over time. With a fixed supply cap and privacy guarantees that prevent blacklisting, ZEC serves as an effective store of value.

MOE (Medium of Exchange)

Zcash enables private transactions for goods and services. Shielded transactions make ZEC an ideal medium of exchange for privacy-conscious commerce.

UOA (Unit of Account)

Zcash can be used as a standard unit for pricing and valuing goods, services, and assets. Private transactions can still be denominated in ZEC as a standard measure.

Privacy-Specific Terms

Shielded Pool

A collection of notes that use the same privacy protocol within a given shielded pool. NozyWallet uses the Orchard and Ironwood pools (no transparent pool for user sends).

Note Commitment Tree

A Merkle tree structure that commits to all notes in a shielded pool. Allows verification without revealing specific notes.

Value Commitment

A cryptographic commitment that hides the amount in a transaction while allowing verification that amounts balance.

Development Setup

Set up a local environment to build and test NozyWallet.

Prerequisites

• Rust 1.70+ — rustup.rs
• Git
• Zebrad (for integration tests and manual sync) — Zebra Node Setup
• protoc — required for zeaking / lightwalletd gRPC builds (sudo apt install protobuf-compiler on Debian/Ubuntu)

Optional for desktop: Node.js 18+, Tauri prerequisites per Tauri docs.

Clone and build

git clone https://github.com/LEONINE-DAO/Nozy-wallet.git
cd NozyWallet
cargo build
cargo test
cargo fmt --all -- --check

Workspace layout

See AGENTS.md for where code belongs.

Desktop development

cd desktop-client
npm install
cargo tauri dev

Use the desktop window, not the browser tab on port 5173.

api-server

cd api-server
cargo run
# http://127.0.0.1:3000

Environment variables

Zebrad on Windows + WSL

. .\scripts\zebra-wsl-rpc.ps1   # sets ZEBRA_RPC_URL to WSL IP
cargo run --bin nozy -- test-zebra

Next steps

• Code Guidelines
• Contributing Guide
• Roadmap

Full detail: CONTRIBUTING.md.

Code Guidelines

NozyWallet follows Rust ecosystem conventions and librustzcash-style patterns.

Formatting and lint

cargo fmt --all
cargo fmt --all -- --check   # CI gate
cargo clippy -- -D warnings

All PRs must pass cargo fmt --all -- --check.

Style

• Types: PascalCase
• Functions / modules: snake_case
• Errors: NozyResult / NozyError — no panics on recoverable paths in library code
• Crypto: Use librustzcash / orchard — no custom ciphers or hand-rolled proofs
• Secrets: zeroize; never log mnemonics, seeds, or private keys

Diff discipline

• Minimal scope — no drive-by refactors in bugfix PRs.
• Match surrounding module layout and imports.
• Link GitHub issues for behavior-changing work.

Testing

cargo test

Add tests when they cover real behavior; avoid trivial assertions.

Security-sensitive areas

Treat as high impact:

• Key derivation and storage
• Transaction building and signing
• RPC URL handling and broadcast
• Witness derivation

For wallet/protocol/security changes, align with maintainers before large PRs (AGENTS.md).

AI-assisted contributions

Disclose AI tooling in PR descriptions. Human author remains responsible for correctness. Agents should read AGENTS.md first.

Pull requests

1. Fork / branch from master
2. Run fmt, build, test
3. PR description: what changed, how tested, AI disclosure if any
4. Link related issues

Full process: CONTRIBUTING.md.

Roadmap

NozyWallet is an Orchard + Ironwood, shielded-only Zcash wallet with multiple surfaces (CLI, extension, web app, mobile, desktop). This page summarizes direction; the canonical list is in the repository:

ENHANCEMENT_ROADMAP.md

Production today

• nozy CLI on mainnet (Orchard + Ironwood NU6.3 migrate / send, ZIP-317 fees)
• Zeaking compact sync via lightwalletd
• Launchpad at GitHub Pages

In active development

Web app starter doc: web-app/README.md

Planned (aligned issues / RFCs)

• Business / POS + ZNS — Issue #85
• Multichain privacy (Namada, Penumbra) — Multichain RFC

How to contribute

1. Read AGENTS.md and Contributing Guide.
2. Pick an item from the enhancement roadmap or open an issue for alignment.
3. See Development Setup for build and test commands.

Contributing Guide

Thank you for contributing to NozyWallet — an Orchard-first, shielded-only Zcash wallet.

Where to start

1. Read AGENTS.md (machine-readable policy for coding agents).
2. Read CONTRIBUTING.md (human contributor guide).
3. Set up the repo: Development Setup.
4. Pick work from Roadmap or GitHub Issues.

Contribution gate (important changes)

Before large or behavior-changing work (new pool, RPC surface, sync architecture, crypto):

1. Open or reference a GitHub issue describing intent.
2. Disclose AI assistance in the PR if tools helped write or review code.
3. Be ready to explain interaction with Zebrad JSON-RPC, lightwalletd, and witness/anchor flows.

See ZEBRAD_SHIELDED_SEND_LIMIT.md for node vs wallet responsibilities.

Code of conduct

• Respectful, technical discussion
• Security and privacy first
• Responsible disclosure for vulnerabilities (no public exploit issues)

What we need help with

• Desktop UI polish and release hardening
• Browser extension milestones
• Mobile via zeaking-ffi
• Documentation (this book!)
• Zebrad operator docs and test coverage

Pull request checklist

• cargo fmt --all and cargo test pass
• Scope matches issue / description
• No secrets in logs or commits
• AI disclosure in PR body if applicable

Repository map (quick)

Questions

GitHub Discussions or issue comments.