ZecDev Toolkit - Product Requirements Document

Executive Summary

Project Name: ZecDev Toolkit Target Bounty: Zcash Privacy Infrastructure & Developer Tools ($5,000) Estimated Timeline: 8-12 weeks Primary Goal: Create a comprehensive developer toolkit that dramatically reduces the barrier to entry for Zcash development and makes debugging shielded transactions intuitive and visual.

The One-Line Pitch: A modern, visual developer toolkit that makes Zcash development as easy as Ethereum development - combining local testnet orchestration, transaction visualization, and interactive debugging in one cohesive tool.

Why This Will Win

Addresses #1 Pain Point: "Setting up shielded support is more difficult than it should be for most developers" - ZecDev Toolkit solves this
No Competition: Nothing like this exists in the Zcash ecosystem
Broad Appeal: Every developer building on Zcash benefits (wallets, exchanges, DApps)
Visual Impact: Demo-able, sharable, impressive for judges
Immediate Value: Developers can use it Day 1 to accelerate their work

Problem Statement

Current Pain Points (Research-Backed)

Based on community research and developer feedback from the Zcash Community Forum:

Complex Setup: "Setting up shielded support using zcashd is more difficult than it should be for most developers"
Opaque Debugging: Zero-knowledge proofs are black boxes - when transactions fail, developers have no visibility into why
Slow Iteration: Testing requires full node sync, which is time-consuming and resource-intensive
Fragmented Tools: Existing tools (zcash-devtool, testnet-in-a-box, darksidewalletd) exist in isolation with no unified interface
High Cognitive Load: Developers must understand nullifiers, viewing keys, note commitments, Merkle trees before building anything
Poor Onboarding: Newcomers struggle identifying "what building blocks to grab to achieve their goals"

The Gap

Web3 developers are used to tools like Hardhat, Foundry, and Remix for Ethereum - comprehensive toolkits with:

One-command local network setup
Transaction visualization and debugging
Interactive testing environments
Clear documentation and examples

Zcash has no equivalent. This creates a massive barrier to adoption.

Target Users

Primary Users

Wallet Developers (e.g., ZecWallet, Zashi, Ywallet teams)
- Need to test shielded transactions before deploying
- Want to debug transaction failures quickly
- Require local testnet for integration testing
Exchange Integration Teams
- Must understand shielded transaction structure for integration
- Need reliable testing environment before mainnet deployment
- Want to validate address handling and memo field usage
DApp Developers (New to Zcash)
- Coming from Ethereum/Solana with different mental models
- Need visual tools to understand Zcash privacy primitives
- Want fast iteration cycles

Secondary Users

Educators & Content Creators
- Teaching Zcash privacy technology
- Creating tutorials and workshops
- Need visual aids to explain concepts
Protocol Researchers
- Experimenting with protocol modifications
- Benchmarking performance
- Testing edge cases

Product Vision & Goals

Vision Statement

"Make Zcash development as accessible as Ethereum development by providing a unified, visual, and intuitive toolkit that handles the complexity of privacy-preserving transactions."

Core Goals

Reduce Time-to-First-Transaction: From hours/days to <10 minutes
Make Privacy Primitives Visual: Transform opaque ZKPs into understandable diagrams
Unify Fragmented Tools: Single interface for testnet, testing, debugging
Lower Learning Curve: Enable developers to build before fully understanding cryptography
Accelerate Debugging: Visualize why transactions fail, not just that they failed

Success Metrics

Adoption: 100+ GitHub stars within 3 months of launch
Usage: 50+ developers actively using toolkit monthly
Time Savings: 70% reduction in setup time (measured via user surveys)
Community Endorsement: Featured in official Zcash developer resources
Secondary Impact: Used in at least 3 educational tutorials/workshops

Feature Requirements

Features organized by priority tiers for 2-3 month development timeline.

MUST-HAVE Features (MVP - Weeks 1-6)

These features are essential for a functional, valuable toolkit that solves core pain points.

1. Local Development Environment (`zecdev init`)

Description: One-command setup of a complete Zcash development environment.

Requirements:

Single CLI command initializes local Zcash testnet
Automatically configures and starts Zebra or zcashd node
Starts lightwalletd instance connected to local node
Pre-funds test addresses (both transparent and shielded)
Exposes standard RPC interface on localhost
Provides environment status dashboard (zecdev status)
Clean shutdown and cleanup (zecdev stop, zecdev clean)

Technical Details:

Use Docker Compose for orchestration
Support both Zebra and zcashd (user choice)
Include pre-generated test wallets with known seeds
Fast block generation mode for rapid testing
Persistent vs. ephemeral mode options

User Story:

"As a wallet developer, I want to spin up a local Zcash testnet in under 2 minutes so I can test shielded transactions without waiting for public testnet sync."

Acceptance Criteria:

Fresh install to running testnet in <5 minutes
Works on macOS, Linux, Windows (WSL2)
Includes 5+ pre-funded test accounts
Clear error messages if dependencies missing
Status command shows node health, block height, peer count

2. Transaction Inspector (Web UI)

Description: Visual, interactive tool for understanding shielded transaction structure.

Requirements:

Transaction Decoder: Paste transaction hex or hash, see full breakdown
Visual Representation: Diagram showing inputs, outputs, shielded pool interactions
Field Explorer: Expandable sections for:
- Transparent inputs/outputs
- Shielded spends and outputs
- Binding signature
- Zero-knowledge proofs (with metadata)
- Memo fields (decoded)
- Nullifiers
- Note commitments
Viewing Key Tester: Test if viewing key can decrypt transaction
Address Validator: Check address format, network, pool type
Export Options: JSON, plaintext, sharable link

Technical Details:

React + TypeScript web application
Server component for transaction parsing (Node.js/Rust)
Integration with Zcash transaction parsing libraries
Responsive design for desktop and mobile
Syntax highlighting for hex data
Copy-to-clipboard functionality

User Story:

"As a developer debugging a failed shielded transaction, I want to paste the transaction data and immediately see which field is malformed so I can fix my code."

Acceptance Criteria:

Parses all Zcash transaction types (v4, v5 with Orchard)
Displays human-readable labels for all fields
Visual diff mode to compare two transactions
Works offline (runs locally)
Loads in <2 seconds for typical transaction

3. CLI Transaction Builder (`zecdev tx`)

Description: Interactive CLI for constructing and broadcasting shielded transactions.

Requirements:

Guided transaction building with prompts
Support for transparent and shielded addresses
Memo field support with encoding helpers
Transaction simulation before broadcast
Save/load transaction templates
Batch transaction creation

Commands:

zecdev tx create          # Interactive transaction builder
zecdev tx send            # Build and broadcast transaction
zecdev tx simulate        # Test transaction without broadcasting
zecdev tx template save   # Save transaction as reusable template
zecdev tx template use    # Use saved template
zecdev tx decode <hash>   # Decode transaction

User Story:

"As a developer learning Zcash, I want an interactive way to create my first shielded transaction without writing any code."

Acceptance Criteria:

Creates valid shielded transactions
Clear validation errors before broadcast
Shows fee estimation
Supports all memo encodings (plaintext, JSON, etc.)
Confirmation prompts before broadcasting

4. Testing Harness Integration

Description: Integration with darksidewalletd for deterministic testing.

Requirements:

Connect to existing darksidewalletd instance
Helper commands for common test scenarios:
- Chain reorganizations
- Transaction confirmations
- Specific block heights
- Custom transaction injection
Test scenario templates (JSON-defined)
Snapshot and restore blockchain state

Commands:

zecdev test start            # Start test harness
zecdev test scenario <name>  # Run predefined scenario
zecdev test reorg <height>   # Trigger chain reorg
zecdev test mine <blocks>    # Mine N blocks
zecdev test snapshot         # Save current state
zecdev test restore          # Restore saved state

User Story:

"As a wallet developer, I want to test how my app handles chain reorganizations without manually orchestrating complex scenarios."

Acceptance Criteria:

Integrates with darksidewalletd seamlessly
10+ pre-built test scenarios included
Scenarios are customizable via JSON
State snapshots work reliably
Clear documentation for scenario creation

5. Developer Documentation Hub

Description: Comprehensive, searchable documentation with examples.

Requirements:

Getting Started guide (setup to first transaction in <30 mins)
Command reference for all CLI commands
Tutorial: Building a simple shielded wallet
Tutorial: Testing with the harness
Architecture overview
Troubleshooting guide
Video walkthrough (5-10 minutes)

Technical Details:

Static site (VitePress, Docusaurus, or similar)
Code examples in TypeScript, Python, Rust
Interactive code playground for simple examples
Searchable
Versioned docs
Dark mode support

Acceptance Criteria:

SHOULD-HAVE Features (Polish - Weeks 7-10)

These features significantly enhance the toolkit but aren't critical for initial launch.

6. Performance Profiler

Description: Measure and visualize ZKP generation and verification times.

Requirements:

Benchmark transaction creation time
Break down time by operation (proving, signing, etc.)
Compare across different transaction types
Historical performance tracking
Export benchmark data (CSV, JSON)

User Story:

"As a performance-conscious developer, I want to see exactly where transaction creation time is spent so I can optimize my implementation."

7. Network Monitor Dashboard

Description: Real-time view of local testnet activity.

Requirements:

Live transaction feed
Block production visualization
Mempool inspector
Shielded pool statistics (pool sizes, turnover)
Network graph (if multiple nodes)
Historical charts (24hr transaction volume, etc.)

User Story:

"As a developer running a local testnet, I want to see all network activity in real-time to understand how my transactions interact with the network."

8. Address Book Manager

Description: Manage test addresses and metadata.

Requirements:

Store labeled addresses (transparent and shielded)
Generate new addresses on demand
Export viewing/spending keys
Tag addresses by purpose (sender, receiver, exchange, etc.)
QR code generation for addresses
Import from common formats

9. Transaction History Explorer

Description: Visual explorer for all local testnet transactions.

Requirements:

List all transactions with filtering
Search by address, amount, memo content
Visual transaction graph (flow of funds)
Export transaction history
Privacy analysis (which outputs are linkable)

10. Plugin System

Description: Allow community extensions to the toolkit.

Requirements:

Plugin API for adding custom commands
Plugin registry (local and community)
Example plugins (e.g., address generator, vanity address finder)
Plugin installation via CLI (zecdev plugin install <name>)

User Story:

"As an advanced user, I want to extend the toolkit with custom functionality specific to my workflow."

NICE-TO-HAVE Features (Future Enhancements)

These features provide additional value but can be deferred to post-launch.

11. GUI Application (Desktop)

Convert CLI + Web UI into standalone Electron app with native installers.

12. Smart Contract Debugger

If Zcash adds programmability (future), debugger for private smart contracts.

13. Multi-Network Support

Switch between local, testnet, and mainnet with environment profiles.

14. Collaborative Features

Share transaction templates, test scenarios with team members.

15. AI-Powered Error Helper

Use LLM to explain transaction errors in plain English and suggest fixes.

16. Integration with Popular Wallets

Direct export to ZecWallet, Ywallet formats for seamless testing.

17. Fuzz Testing Module

Automated fuzz testing for transaction parsing and validation.

18. Privacy Leak Detector

Analyze transactions for potential privacy leaks (address reuse, amount correlation).

Technical Architecture

High-Level Components

┌─────────────────────────────────────────────────────────────┐
│                     ZecDev Toolkit                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│  │   CLI Tool   │  │   Web UI     │  │  Docs Site   │     │
│  │   (Rust)     │  │ (React/TS)   │  │ (VitePress)  │     │
│  └──────┬───────┘  └──────┬───────┘  └──────────────┘     │
│         │                  │                                │
│         └──────────┬───────┘                                │
│                    │                                        │
│         ┌──────────▼───────────┐                           │
│         │   Core Library       │                           │
│         │   (Rust + WASM)      │                           │
│         │                      │                           │
│         │  - Transaction Parser│                           │
│         │  - RPC Client        │                           │
│         │  - Crypto Utils      │                           │
│         │  - Test Harness      │                           │
│         └──────────┬───────────┘                           │
│                    │                                        │
└────────────────────┼────────────────────────────────────────┘
                     │
         ┌───────────▼───────────┐
         │   Docker Orchestration│
         │                       │
         │  ┌─────────────────┐  │
         │  │  Zebra/zcashd   │  │
         │  └─────────────────┘  │
         │  ┌─────────────────┐  │
         │  │  lightwalletd   │  │
         │  └─────────────────┘  │
         │  ┌─────────────────┐  │
         │  │ darksidewalletd │  │
         │  └─────────────────┘  │
         └───────────────────────┘

Technology Stack

CLI Tool

Language: Rust
Framework: Clap (CLI parsing), Tokio (async runtime)
Why: Performance, safety, great library ecosystem for blockchain tools

Core Library

Language: Rust with WASM bindings
Key Dependencies:
- zcash_client_backend - Wallet functionality
- zcash_primitives - Core protocol primitives
- zcash_proofs - ZKP verification
- orchard - Orchard pool support
- sapling-crypto - Sapling support
Why: Reuse official Zcash libraries, compile to WASM for web use

Web UI

Frontend: React 18+ with TypeScript
Styling: Tailwind CSS
State Management: Zustand or Jotai (lightweight)
Visualization: D3.js for transaction graphs, Recharts for performance charts
Build Tool: Vite
Why: Modern, fast, great developer experience

Backend API (for Web UI)

Language: TypeScript (Node.js) or Rust (Actix-web)
API Style: REST + WebSocket (for live updates)
Why: Bridge between WASM core library and React frontend

Docker Orchestration

Tool: Docker Compose
Containers:
- Zebra (or zcashd) - Full node
- lightwalletd - Light client server
- darksidewalletd - Testing server
Why: Platform-independent, reproducible environments

Documentation

Tool: VitePress or Docusaurus
Why: Fast, searchable, integrates with Vue/React

Data Flow

Transaction Inspection Flow

User pastes TX data → Web UI → API Server → WASM Core Library
                                             (parse_transaction)
                                                    ↓
                                            Structured TX data
                                                    ↓
                                            API Server → Web UI
                                                    ↓
                                            Visual Rendering

Local Testnet Flow

User: `zecdev init` → CLI reads config → Docker Compose up
                                                ↓
                                         Zebra + lightwalletd start
                                                ↓
                                         Genesis blocks mined
                                                ↓
                                         Test accounts funded
                                                ↓
                                         Status reported to user

Security Considerations

No Mainnet Access by Default: Toolkit defaults to testnet/local to prevent accidental mainnet transactions
Key Management: Private keys only stored in local environment, never transmitted
Input Validation: All user inputs sanitized before processing
Dependency Auditing: Regular security audits of dependencies
Clear Warnings: Prominent warnings when switching to mainnet mode (future)

Key Technical Decisions

Decision 1: Rust Core with WASM for Web

Options Considered:

Pure TypeScript (easier for web devs)
Rust core + WASM bindings (reuse Zcash libraries)
Python (rapid prototyping)

Decision: Rust core with WASM bindings

Rationale:

Zcash's official libraries are in Rust
WASM allows code reuse between CLI and Web UI
Performance is critical for transaction parsing
Type safety prevents bugs
Growing WASM ecosystem

Trade-offs:

Steeper learning curve for contributors
WASM bundle size (mitigated with code splitting)

Decision 2: Docker-Based Local Environment

Options Considered:

Native binary installation (complex setup)
Docker Compose (containerized)
Kubernetes (overkill for local dev)

Decision: Docker Compose

Rationale:

Cross-platform (Mac, Linux, Windows)
Isolated environment (doesn't conflict with existing Zcash installations)
Easy to reset and clean up
Familiar to most developers
Reproducible builds

Trade-offs:

Requires Docker installation
Resource overhead (acceptable for dev tools)

Decision 3: Separate Web UI Instead of Terminal UI

Options Considered:

Terminal UI only (faster to build)
Web UI only (more accessible)
Hybrid: CLI + Web UI

Decision: Hybrid approach (CLI for control, Web for visualization)

Rationale:

Different use cases: CLI for scripting/automation, Web for exploration
Web enables rich visualizations (transaction graphs, charts)
CLI appeals to power users
Both share same Rust core library

Trade-offs:

More code to maintain
Need to ensure feature parity

Decision 4: Support Both Zebra and zcashd

Options Considered:

Zebra only (modern, Rust-based)
zcashd only (mature, widely used)
Support both

Decision: Support both with Zebra as default

Rationale:

Zebra is the future (zcashd deprecating Q2 2025)
Some developers still use zcashd
Bounty judges may use either
Shows thorough understanding of ecosystem

Trade-offs:

Double testing effort
Configuration complexity

Decision 5: Open Source from Day 1

License: MIT or Apache 2.0

Rationale:

Aligns with Zcash's open-source ethos
Encourages community contributions
Increases likelihood of adoption
Judges value community benefit

User Stories

Story 1: First-Time Developer

Persona: Alex, a web developer new to Zcash

Scenario: Alex wants to integrate Zcash payments into their e-commerce app but has never worked with privacy coins.

User Flow:

Reads "Getting Started" guide (5 mins)
Installs ZecDev Toolkit via Homebrew/npm
Runs zecdev init → local testnet running in 3 minutes
Follows tutorial to create first shielded transaction via CLI
Opens Web UI to inspect the transaction structure
Uses transaction as template for their app integration
Tests app using local testnet
Deploys to testnet for beta testing

Success: Alex goes from zero to integrated in one afternoon instead of one week.

Story 2: Wallet Developer Debugging

Persona: Jordan, senior developer at a Zcash wallet company

Scenario: Users report that shielded transactions occasionally fail with cryptic error messages. Jordan needs to debug.

User Flow:

User provides failing transaction hash
Jordan pastes hash into Transaction Inspector
Inspector highlights invalid nullifier
Jordan compares with a working transaction using diff mode
Identifies bug in nullifier generation logic
Fixes code, tests locally with zecdev test harness
Validates fix before production deployment

Success: Bug found and fixed in hours instead of days.

Story 3: Exchange Integration

Persona: Sam, blockchain engineer at a crypto exchange

Scenario: Exchange wants to support shielded deposits/withdrawals. Sam needs to understand Zcash memo field encoding.

User Flow:

Reads tutorial on memo fields
Creates test transactions with various memo types using CLI
Inspects each in Web UI to see encoding
Uses address validator to ensure deposit addresses are correct
Runs integration tests using test harness scenarios
Simulates high volume with batch transaction creation

Success: Confident integration with thorough testing before mainnet launch.

Story 4: Educator Creating Content

Persona: Riley, blockchain educator and YouTuber

Scenario: Riley wants to create a video explaining how Zcash shielded transactions work.

User Flow:

Creates sample transactions using zecdev tx create
Opens transactions in Web UI
Screen-records visual breakdown for video
Uses exported diagrams in slides
Links to ZecDev Toolkit in video description for viewers to experiment

Success: High-quality educational content that makes Zcash privacy approachable.

Success Criteria

Technical Success

Passes all Zcash transaction validation tests
Successfully parses 100% of transaction types (v4, v5, all pools)
Local testnet setup completes in <5 minutes on standard hardware
Web UI loads and renders transactions in <2 seconds
CLI commands complete in <1 second for typical operations
Zero critical security vulnerabilities in audit
90%+ uptime for local testnet over 24-hour period

User Success

50+ active users within first month
100+ GitHub stars within 3 months
Featured in official Zcash developer documentation
Used in at least 3 community tutorials or workshops
Positive feedback from 80%+ of surveyed users
Average setup time reduced by 70% vs. manual setup

Bounty Success

Meets all bounty criteria for Privacy Infrastructure & Developer Tools
Demonstrates clear value to Zcash ecosystem
Shows technical depth and understanding of privacy primitives
Has strong demo video showcasing capabilities
Receives endorsements from Zcash core developers or community leaders

Out of Scope

The following are explicitly NOT included in this version to maintain focus:

Mainnet Support: Toolkit is for development/testing only initially
Production Wallet Functionality: Not a wallet, just development tools
Custom Blockchain Modifications: Works with standard Zcash protocol only
Mobile App: Web UI is responsive but no native mobile apps
Cloud Hosting: Local-first; no hosted/SaaS version
Extensive Custom Scripting: Covers common use cases, not a full programming environment
Historical Chain Analysis: No blockchain analytics/forensics features
Multi-Currency Support: Zcash only (no Bitcoin, Ethereum, etc.)
Graphical Transaction Builder: CLI and code-based only, no drag-and-drop UI
Production Monitoring/Alerting: Development tool, not ops tool

Dependencies & Prerequisites

Development Dependencies

Required:

Rust 1.70+ (for CLI and core library)
Node.js 18+ (for Web UI and build tooling)
Docker 20+ and Docker Compose (for local testnet)
Git

Recommended:

Rust-analyzer (IDE support)
VS Code or equivalent
16GB+ RAM (for running local testnet)
50GB+ disk space

External Dependencies

Zcash Software:

Zebra (consensus node) - https://github.com/ZcashFoundation/zebra
OR zcashd (alternative consensus node) - https://github.com/zcash/zcash
lightwalletd - https://github.com/zcash/lightwalletd
darksidewalletd (testing) - included with lightwalletd

Rust Crates:

zcash_client_backend
zcash_primitives
zcash_proofs
orchard
sapling-crypto
clap (CLI parsing)
tokio (async runtime)
serde (serialization)
wasm-bindgen (WASM bindings)

JavaScript Packages:

React 18+
TypeScript 5+
Vite
Tailwind CSS
D3.js
Recharts
VitePress (docs)

Infrastructure Requirements

For Users:

8GB+ RAM (16GB recommended)
20GB+ free disk space
Internet connection (initial Docker image downloads)
macOS 11+, Ubuntu 20.04+, or Windows 10+ with WSL2

Risks & Mitigation Strategies

Risk 1: Zcash Library Breaking Changes

Probability: Medium Impact: High Mitigation:

Pin specific versions of dependencies
Monitor Zcash GitHub for breaking changes
Maintain compatibility layer
Automated tests catch breaking changes early

Risk 2: Docker Complexity for Non-Technical Users

Probability: Medium Impact: Medium Mitigation:

Provide detailed troubleshooting guide
Create video walkthrough
Offer Docker Desktop recommendations
Consider standalone binary fallback for CLI

Risk 3: WASM Bundle Size

Probability: Low Impact: Medium Mitigation:

Code splitting and lazy loading
Optimize WASM build with wasm-opt
Compress bundles with Brotli
Monitor bundle size in CI

Risk 4: Testnet vs. Mainnet Confusion

Probability: Low Impact: High (if users lose real funds) Mitigation:

No mainnet support in v1
Prominent warnings in UI
Different color schemes for networks
Require explicit opt-in for mainnet (future)

Risk 5: Scope Creep

Probability: High Impact: Medium Mitigation:

Strict prioritization (Must/Should/Nice-to-Have)
Weekly progress reviews
Feature freeze after week 8
Launch MVP, iterate based on feedback

Risk 6: Community Adoption

Probability: Medium Impact: High (for bounty success) Mitigation:

Engage Zcash community early (feedback on design)
Create demo video and screenshots
Post on Zcash forums and social media
Reach out to wallet developers for beta testing
Present at Zcash community calls

Open Questions for Implementation

These questions should be resolved during development:

Technical Questions

Transaction Parsing:
- Which version of zcash_primitives provides the most complete transaction parsing?
- How to handle partially signed transactions?
WASM Performance:
- What's the actual bundle size after optimization?
- Are there performance bottlenecks in WASM that require native modules?
Docker Configuration:
- What's the optimal block production rate for local testnet? (fast for testing vs. realistic for integration)
- Should we support ARM architecture (Apple Silicon) with different images?
Web UI State Management:
- Should transaction history persist between sessions?
- Local storage vs. in-memory only?
RPC Interface:
- Which RPC methods are actually needed? (avoid exposing everything)
- Should we proxy RPC or use lightwalletd gRPC exclusively?

Product Questions

Onboarding:
- What's the minimal tutorial length? (balance thoroughness vs. time)
- Should there be an interactive CLI onboarding wizard?
Error Handling:
- How verbose should error messages be? (detailed for advanced users vs. simple for beginners)
- Should errors link to documentation?
Customization:
- How configurable should the local testnet be? (balance simplicity vs. power)
- Configuration file format: TOML, YAML, JSON?
Updates:
- Auto-update mechanism for Docker images?
- Notify users of new ZecDev Toolkit versions?
Community Feedback:
- When to release beta for feedback? (week 4? week 6?)
- Public roadmap or feature voting?

Development Phases

Phase 1: Foundation (Weeks 1-3) - MUST-HAVE Core

Goals: Basic infrastructure working end-to-end

Deliverables:

Docker Compose setup for Zebra + lightwalletd
Basic CLI with init, start, stop commands
Core library with transaction parsing (Sapling only initially)
Simple Web UI shell with transaction decoder
Basic documentation structure

Success Criteria:

Can spin up local testnet in one command
Can parse and display a Sapling shielded transaction

Phase 2: Core Features (Weeks 4-6) - MUST-HAVE Completion

Goals: All essential features functional

Deliverables:

Complete Transaction Inspector with all transaction types (v4, v5, Orchard)
CLI transaction builder (zecdev tx commands)
Testing harness integration (darksidewalletd)
Enhanced Web UI with visualizations
Getting Started guide and tutorials

Success Criteria:

Can create, inspect, and broadcast shielded transactions
Can run common test scenarios
Documentation covers all core workflows

Phase 3: Polish & Enhancement (Weeks 7-9) - SHOULD-HAVE Features

Goals: Production-ready quality, additional features

Deliverables:

Performance profiler
Network monitor dashboard
Address book manager
Transaction history explorer
Video walkthrough
Comprehensive troubleshooting guide

Success Criteria:

Beta users successfully complete workflows without assistance
Performance meets targets (<5min setup, <2sec UI load)
Documentation is searchable and comprehensive

Phase 4: Launch & Iteration (Weeks 10-12) - Community Release

Goals: Public release and initial adoption

Deliverables:

Public GitHub repository with MIT/Apache license
Official release (v1.0.0)
Published documentation site
Demo video and screenshots
Bounty submission
Social media announcements
Community feedback collection

Success Criteria:

Zero critical bugs in first week
Positive community reception
First external contributors or issues filed

Appendix: Example Commands

CLI Command Reference (Preview)

# Environment Management
zecdev init                          # Initialize local Zcash development environment
zecdev start                         # Start local testnet
zecdev stop                          # Stop local testnet
zecdev clean                         # Remove all local data
zecdev status                        # Show environment status
zecdev config                        # Edit configuration

# Transaction Operations
zecdev tx create                     # Interactive transaction builder
zecdev tx send --to <addr> --amount <ZEC>  # Quick send
zecdev tx decode <hash>              # Decode transaction
zecdev tx simulate <file>            # Simulate transaction
zecdev tx template save <name>       # Save transaction template
zecdev tx template list              # List templates
zecdev tx template use <name>        # Use template

# Address Management
zecdev addr generate                 # Generate new address
zecdev addr validate <addr>          # Validate address
zecdev addr balance <addr>           # Check balance
zecdev addr export-keys <addr>       # Export viewing/spending keys

# Testing Harness
zecdev test start                    # Start test harness
zecdev test stop                     # Stop test harness
zecdev test scenario <name>          # Run test scenario
zecdev test scenario list            # List available scenarios
zecdev test reorg <height>           # Trigger chain reorganization
zecdev test mine <n>                 # Mine N blocks
zecdev test snapshot <name>          # Save blockchain snapshot
zecdev test restore <name>           # Restore snapshot

# Monitoring
zecdev monitor                       # Open network monitor dashboard
zecdev logs                          # View node logs
zecdev logs --follow                 # Tail logs

# Web UI
zecdev ui                            # Open Web UI in browser
zecdev ui --port 3000                # Specify port

# Documentation
zecdev docs                          # Open documentation in browser
zecdev docs --search <query>         # Search docs

# Version & Updates
zecdev version                       # Show version
zecdev update                        # Check for updates

Appendix: Web UI Wireframes (Text Descriptions)

Transaction Inspector View

┌───────────────────────────────────────────────────────────────┐
│  ZecDev Toolkit - Transaction Inspector                      │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│  [Paste transaction hex or hash]  [Decode Transaction]       │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │ e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991...│ │
│  └─────────────────────────────────────────────────────────┘ │
│                                                               │
│  ┌─ Transaction Overview ────────────────────────────────┐   │
│  │  Type: v5 (Orchard)                                   │   │
│  │  Network: Testnet                                     │   │
│  │  Confirmations: 42                                    │   │
│  │  Fee: 0.0001 ZEC                                      │   │
│  │  Total In: 5.0 ZEC    Total Out: 4.9999 ZEC          │   │
│  └────────────────────────────────────────────────────────┘   │
│                                                               │
│  ┌─ Visual Flow ─────────────────────────────────────────┐   │
│  │                                                        │   │
│  │   [Shielded Input]  ──→  [Shielded Pool]  ──→  [Shielded│
│  │     5.0 ZEC                                      Output]│   │
│  │                                                  4.9999 ZEC│
│  │                            ↓                            │   │
│  │                          [Fee]                          │   │
│  │                         0.0001                          │   │
│  └────────────────────────────────────────────────────────┘   │
│                                                               │
│  ▼ Transparent Inputs (0)                                    │
│  ▼ Shielded Spends (1)                                       │
│    ├─ Nullifier: a3c8f9...                                   │
│    ├─ Anchor: 7f3e2d...                                      │
│    └─ Proof: [View Proof Data]                               │
│  ▼ Shielded Outputs (1)                                      │
│    ├─ Note Commitment: 8e4a1c...                             │
│    ├─ Ephemeral Key: 2b7f9e...                               │
│    ├─ Encrypted Note: [Decrypt with viewing key]             │
│    └─ Memo: [Encrypted]                                      │
│  ▼ Binding Signature                                         │
│    └─ Signature: 9c3f7a...                                   │
│                                                               │
│  [Export JSON] [Export Text] [Compare Transactions]          │
└───────────────────────────────────────────────────────────────┘

Network Monitor Dashboard

┌───────────────────────────────────────────────────────────────┐
│  ZecDev Toolkit - Network Monitor                            │
├───────────────────────────────────────────────────────────────┤
│  ┌─ Node Status ─────────┐  ┌─ Live Transaction Feed ─────┐  │
│  │  ● Connected           │  │                             │  │
│  │  Block Height: 1,425   │  │  [TX] Shielded → Shielded   │  │
│  │  Peers: 1              │  │  2.5 ZEC  |  1 min ago      │  │
│  │  Sync: 100%            │  │                             │  │
│  │  Mempool: 3 txs        │  │  [TX] Transparent → Shielded│  │
│  └────────────────────────┘  │  10.0 ZEC  |  3 min ago     │  │
│                              │                             │  │
│  ┌─ Shielded Pool Stats ──┐  │  [TX] Shielded → Transparent│  │
│  │  Sapling: 125.5 ZEC    │  │  0.5 ZEC  |  5 min ago      │  │
│  │  Orchard: 89.2 ZEC     │  │                             │  │
│  │  Total Shielded: 214.7 │  │  [Load More]                │  │
│  └────────────────────────┘  └─────────────────────────────┘  │
│                                                               │
│  ┌─ Transaction Volume (24h) ────────────────────────────┐   │
│  │  [Chart showing transactions over time]               │   │
│  │   ^                                                    │   │
│  │ 20│     ╭─╮                                            │   │
│  │ 15│   ╭─╯ ╰╮  ╭╮                                       │   │
│  │ 10│ ╭─╯    ╰──╯╰─╮                                     │   │
│  │  5│─╯           ╰──╮                                   │   │
│  │  0└────────────────┴─────────────────> Time            │   │
│  └────────────────────────────────────────────────────────┘   │
└───────────────────────────────────────────────────────────────┘

Final Notes for Implementation Team

Success Tips

Start Simple: Get basic testnet running first, then add features incrementally
User Testing Early: Release alpha to 3-5 developers for feedback by week 4
Document As You Go: Don't save documentation for last; write it alongside code
Engage Community: Post progress updates on Zcash forums; builds anticipation
Demo Video is Critical: Invest time in a polished 5-minute demo; judges will watch this

Common Pitfalls to Avoid

Over-Engineering: Resist urge to build every feature; ship MVP first
Poor Error Messages: Every error should clearly explain what's wrong and how to fix it
Inconsistent UX: CLI and Web UI should use same terminology and concepts
Ignoring Windows Users: Test on Windows/WSL2; many developers use it
No Metrics: Add basic analytics (opt-in) to understand usage patterns

Bounty Submission Checklist

Code published to GitHub with open-source license
README with clear setup instructions
Comprehensive documentation site live
5-10 minute demo video showing all features
Screenshots in bounty submission
Testimonials from beta testers (if possible)
Clear explanation of how it solves ecosystem problems
Roadmap for future development
Active engagement with bounty judges' questions

Good luck building ZecDev Toolkit! This has the potential to become essential infrastructure for the Zcash ecosystem.

FilesExpand file tree

prd.md

Latest commit

History

prd.md

File metadata and controls

ZecDev Toolkit - Product Requirements Document

Executive Summary

Why This Will Win

Problem Statement

Current Pain Points (Research-Backed)

The Gap

Target Users

Primary Users

Secondary Users

Product Vision & Goals

Vision Statement

Core Goals

Success Metrics

Feature Requirements

MUST-HAVE Features (MVP - Weeks 1-6)

1. Local Development Environment (zecdev init)

2. Transaction Inspector (Web UI)

3. CLI Transaction Builder (zecdev tx)

4. Testing Harness Integration

5. Developer Documentation Hub

SHOULD-HAVE Features (Polish - Weeks 7-10)

6. Performance Profiler

7. Network Monitor Dashboard

8. Address Book Manager

9. Transaction History Explorer

10. Plugin System

NICE-TO-HAVE Features (Future Enhancements)

11. GUI Application (Desktop)

12. Smart Contract Debugger

13. Multi-Network Support

14. Collaborative Features

15. AI-Powered Error Helper

16. Integration with Popular Wallets

17. Fuzz Testing Module

18. Privacy Leak Detector

Technical Architecture

High-Level Components

Technology Stack

CLI Tool

Core Library

Web UI

Backend API (for Web UI)

Docker Orchestration

Documentation

Data Flow

Transaction Inspection Flow

Local Testnet Flow

Security Considerations

Key Technical Decisions

Decision 1: Rust Core with WASM for Web

Decision 2: Docker-Based Local Environment

Decision 3: Separate Web UI Instead of Terminal UI

Decision 4: Support Both Zebra and zcashd

Decision 5: Open Source from Day 1

User Stories

Story 1: First-Time Developer

Story 2: Wallet Developer Debugging

Story 3: Exchange Integration

Story 4: Educator Creating Content

Success Criteria

Technical Success

User Success

Bounty Success

Out of Scope

Dependencies & Prerequisites

Development Dependencies

External Dependencies

Infrastructure Requirements

Risks & Mitigation Strategies

Risk 1: Zcash Library Breaking Changes

Risk 2: Docker Complexity for Non-Technical Users

Risk 3: WASM Bundle Size

Risk 4: Testnet vs. Mainnet Confusion

Risk 5: Scope Creep

1. Local Development Environment (`zecdev init`)

3. CLI Transaction Builder (`zecdev tx`)