### Terms and Conditions
- [x] I agree to the [Grant Agreement](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded
- [x] I agree to [Provide KYC information](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
- [x] I agree to disclose conflicts of interest
- [x] I agree to adhere to the [Code of Conduct](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and [Communication Guidelines](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
- [x] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
- [x] I agree that for any new open-source software, I will create a `CONTRIBUTING.md` file that reflects the high standards of Zcash development, using the [`librustzcash` style guides](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
- [x] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any [merge](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), [branch](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), [pull request](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and [commit](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the `librustzcash` repository.
- [x] I agree to post request details on the [Community Forum](https://forum.zcashcommunity.com/c/grants/33)
- [x] I understand it is my responsibility to post a link to this issue on the [Zcash Community Forums](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
### Application Owners (@Octocat, @Octocat1)
PeterRaf89
### Organization Name
QuBit
### How did you learn about Zcash Community Grants
learned about it from crypto community forums and privacy-focused groups.
### Requested Grant Amount (USD)
$45000
### Category
Infrastructure
### Project Lead
```project-lead.yaml
Name: Pedro Santos
Role: Project Lead, Developer & Marketing Lead
Background:
Independent builder focused on cryptography, wallet security, and post-quantum key management. Experienced in designing local-only encryption systems, multichain wallet architecture, and secure user flows. Also responsible for brand direction and communication strategy, ensuring the project reaches the right technical and community audience. Currently leading end-to-end development of QuBit Wallet.
Responsibilities:
Full ownership of architecture, development, security design, roadmap execution, user experience, and marketing. Managing all technical components (encryption engine, vault logic, multichain support) as well as community updates, positioning, and outreach. Ensures that QuBit Wallet progresses consistently while maintaining high security standards and clear communication.
```
### Additional Team Members
```team-members.yaml
None
```
### Project Summary
QuBit Wallet is a quantum-resistant, self-custodial wallet that performs all key generation and encryption locally, eliminating server-side attack surfaces. It provides a secure, future-proof vault for multichain assets with a design built to withstand both modern and post-quantum threats.
### Project Description
QuBit Wallet is a quantum-resistant, self-custodial wallet designed to provide the highest level of user security by eliminating all traditional attack surfaces. Unlike most wallets, QuBit performs all sensitive operations locally on the user’s device—key generation, encryption, decryption, signing, and vault handling are executed entirely offline with no backend servers, no cloud storage, and no external dependency that could leak or expose private keys.
The wallet is built around a 32-byte master seed that is locally derived, locally encrypted, and never leaves the device. From this, QuBit generates secure multichain keypairs (BTC, EVM, Solana, and in the future, Zcash). The underlying architecture ensures that the user’s keys remain fully isolated, cannot be intercepted by third parties, and are prepared for future post-quantum cryptographic standards.
The primary goals of QuBit Wallet are:
• Create a highly secure, quantum-resistant vault for managing digital assets without relying on centralized infrastructure.
• Provide a privacy-first alternative to traditional wallets, where no identifiable data, keys, or metadata ever leave the user’s device.
• Develop a modular signing engine capable of supporting multiple chains, including potential integration with Zcash’s privacy features.
• Prepare users for post-quantum security risks by experimenting with advanced key-management techniques and forward-secure cryptography.
• Offer open-source tooling that the broader Zcash and crypto communities can build on, fork, or audit.
• Improve the overall security posture of end users by removing the cloud/server risk vectors that cause the majority of wallet breaches.
QuBit aims to become a foundational privacy and security tool—an offline-first, quantum-aware wallet engine that gives users complete control over their keys while aligning with the values of decentralization, cryptographic integrity, and long-term privacy protection.
### Proposed Problem
Most wallets today rely on external infrastructure, cloud services, or metadata exposure that creates unnecessary attack surfaces and long-term privacy risks. As cryptographic systems age and quantum computing advances, traditional ECDSA-based key storage becomes increasingly vulnerable. Users have no reliable, offline-first way to generate and protect keys that remain isolated from servers, analytics systems, or centralized dependencies.
Additionally, self-custodial users lack tools that guarantee true local privacy, meaning their keys, usage patterns, and metadata can still be leaked through API calls or background network interactions. This gap is particularly critical for ecosystems like Zcash, where privacy and cryptographic integrity are foundational values.
QuBit aims to solve this by providing a fully local, quantum-resistant key vault that eliminates server-side trust, removes cloud exposure, and prepares users for the next era of cryptographic threats.
### Proposed Solution
QuBit Wallet solves this problem by implementing a fully local, quantum-resistant key-management architecture where all sensitive operations—key generation, encryption, signing, and vault handling—occur entirely on the user’s device. No servers, cloud endpoints, or external infrastructure ever interact with private keys, eliminating the attack vectors that compromise most wallets today.
At the core of the system is a locally derived master seed that is encrypted and stored only on the device. From this seed, QuBit generates chain-specific keypairs (including future Zcash support) without exposing metadata or relying on third-party infrastructure. The wallet’s design isolates all cryptographic operations, ensuring that even if external services fail or become compromised, the user’s keys and privacy remain intact.
By removing backend trust, minimizing metadata exposure, and preparing for post-quantum cryptographic standards, QuBit provides a hardened, privacy-first vault that directly addresses the long-term security challenges facing self-custodial users—and aligns naturally with Zcash’s mission of protecting privacy through strong, modern cryptography.
### Solution Format
Software Deliverable:
QuBit Wallet will be delivered as an open-source software project consisting of a fully local, quantum-resistant wallet application. The deliverables include the core encryption engine, local-only key vault, multichain key derivation logic, and an early user interface for secure wallet operations.
Documentation:
Technical documentation explaining the cryptographic model, local-only architecture, security assumptions, and integration pathways for Zcash.
Open-Source Repository:
A public GitHub repository containing source code, build instructions, and developer notes for auditing, testing, and community contributions.
### Dependencies
QuBit Wallet is designed to operate with minimal external dependencies in order to maintain maximum security and avoid reliance on third-party infrastructure. The project requires:
Technical Dependencies:
• Open-source cryptographic libraries for hashing, key derivation, and post-quantum–ready primitives.
• Access to Zcash full-node RPC or lightwalletd endpoints for network queries and broadcasting transactions.
• Standard development tools (TypeScript, Rust bindings, local build tools).
Resource Dependencies:
• Compute resources for local development, testing, and security validation.
• Occasional expert review from cryptography and wallet-security specialists to ensure correctness.
Collaborations (Optional but beneficial):
• Interaction with the Zcash developer community for protocol-specific guidance.
• Potential coordination with open-source maintainers of Zcash tooling (only if needed; no hard dependency).
### Technical Approach
The technical approach includes:
1. Master Seed Architecture
A single 32-byte master seed is generated locally using secure randomness. All Zcash addresses, viewing keys, and spending keys are deterministically derived from this seed using hardened key-derivation paths. The seed never leaves the user’s device.
2. Local-Only Encryption & Vault System
The master seed is encrypted client-side using a password-based key derived through Argon2id. Encrypted blobs are stored locally (browser/device storage) with no server involvement. This prevents remote compromise and allows full self-custody.
3. Zcash Integration
The wallet integrates Zcash protocol features through:
• Lightwalletd or full-node RPC for balance queries, memo retrieval, and transaction submission.
• Sapling and Orchard proof creation handled locally, ensuring privacy is preserved end-to-end.
• Shielded address derivation based on the encrypted master seed.
4. Transaction Engine
Transactions—including shielded transactions—are constructed locally and signed entirely offline. This ensures private keys remain isolated and never touch the network. Fee estimation, note selection, and proof generation follow Zcash consensus rules.
5. Post-Quantum Hardening
Where applicable, internal structures (password hashing, seed storage, encryption) are designed to remain resistant to foreseeable quantum threats. Future phases include optional migration paths to PQ-safe key types as these become standardized in Zcash.
6. Frontend / Application Layer
• Built using TypeScript + React for flexible cross-platform deployment.
• Modular crypto layer enables expansion to native mobile apps without redesign.
• Strict separation between UI logic and cryptographic operations for improved auditability.
7. Testing & Hardening
• Unit and integration tests for all cryptographic operations.
• Static analysis tools, dependency audits, and fuzz testing on transaction building.
• Planned third-party audits in later phases.
### Upstream Merge Opportunities
QuBit Wallet does not require forking or modifying core Zcash consensus code, but certain components of the project can naturally align with upstream Zcash repositories, particularly in the wallet and tooling layers. The primary upstream touchpoints are:
1. Zcash Light Client SDK / Lightwalletd
If deeper shielded functionality or additional client-side features are built (e.g., optimized fee estimation, improved note-selection logic, performance improvements in proof generation), these enhancements could be contributed back upstream.
Potential contributions:
• Performance optimizations for shielded transaction building.
• Improved light client syncing logic.
• Additional APIs for privacy-focused mobile or browser-based applications.
2. Zcash Wallet Libraries (Rust / Mobile SDKs)
QuBit integrates deterministic key derivation and encrypted vault structures. If improvements are made to key-handling utilities, encryption wrappers, or mobile-friendly Zcash toolkits, these could be upstreamed as reusable modules.
3. Developer Tooling & Documentation
As part of building a multi-platform Zcash wallet, new developer-first tooling or clearer integration examples may be produced. These can be pushed upstream to improve onboarding for future builders.
Upstream Benefits
Any optimizations around:
• faster shielded syncing
• more efficient proof creation
• standardized deterministic derivation processes
• security-hardening utilities
…would directly benefit the broader Zcash wallet ecosystem and future application developers.
Coordination With Maintainers
Coordination would mainly involve:
• lightwalletd maintainers
• Zcash Foundation wallet SDK maintainers
• ECC engineering teams (if relevant to Orchard/Sapling support)
Communication would occur via GitHub issues, PRs, and the Zcash community channels.
Timeline
Upstream contributions would be proposed after QuBit Wallet’s core implementation stabilizes—roughly mid-development of the wallet engine phase. Contributions would follow:
1. Internal testing →
2. Draft PR →
3. Maintainer feedback →
4. Final merge & documentation.
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
1. Cryptographic Complexity & Security Hardening
Implementing quantum-resistant and privacy-preserving key infrastructure requires careful engineering. Mistakes in encryption, seed handling, or ZK-compatible flows could create vulnerabilities. This risk is mitigated through staged development, external security review, and strict local-only key management.
2. Cross-Chain Integration Challenges
Supporting Zcash, Solana, EVM chains, and Bitcoin under a single master-seed architecture introduces compatibility challenges. Each chain uses different signing schemes, RPC behaviors, and fee models. These differences may slow implementation or require additional engineering time.
3. Limited Resources as a Solo Builder
With most development handled by one primary engineer, timelines may extend if unexpected technical issues arise. This risk is addressed through careful milestone planning and by using part of the grant to contract short-term specialists (security, QA).
4. Regulatory and Ecosystem Changes
Changing RPC policies, node availability, or privacy-related regulations may impact functionality, especially for Zcash shielded operations. Mitigation involves building modular RPC layers and avoiding reliance on any single provider.
5. Performance & Compatibility for Future Quantum Upgrades
Ensuring today’s architecture can support future PQC primitives may require refactoring. The design already anticipates this, but the cryptographic landscape evolves quickly, and additional adjustments may be needed.
6. User Education & UX Adoption
Privacy-enhanced wallets require user understanding of shielded vs. transparent interactions. Poor UX could limit adoption. This is mitigated through simplified flows, “explainers,” and strong defaults.
### Potential Side Effects
Potential Side Effects
1. Increased User Responsibility & Risk of Self-Custody Loss
Because QuBit Wallet enforces strict local-only key storage and zero backend access, users are fully responsible for safeguarding their password and recovery materials. Unlike custodial solutions, lost credentials cannot be recovered by the team, which may lead to permanent asset loss for careless users.
2. Higher Learning Curve for Privacy & Quantum Security Concepts
Implementing shielded Zcash flows, post-quantum protection, and local-vault security may introduce concepts that inexperienced users could find confusing. If misunderstood, users might make mistakes such as sending to the wrong address type or mismanaging backups.
3. Potential RPC or Network Load Increase on Privacy Nodes
If QuBit gains significant adoption, the increased volume of shielded transaction activity and wallet syncs could create additional load on Zcash-compatible infrastructure providers. This may require coordination with node operators to ensure stable performance.
4. Misuse by Bad Actors (General Privacy Tooling Risk)
Any privacy-enhancing wallet may be misused by malicious actors. Although QuBit is simply a self-custodial client (like existing privacy wallets), increased privacy can attract scrutiny or misinterpretation by regulators. Clear communication, transparent open-source development, and community engagement help mitigate this.
5. Cross-Chain Complexity Leading to User Mistakes
Managing Zcash, Solana, EVM networks, and Bitcoin under a single vault may cause confusion for new users—especially around fee models, address formats, and shielded vs. transparent transactions. UX design and contextual warnings aim to reduce missteps.
6. Early-Stage Quantum-Resistant Features May Evolve
As post-quantum cryptography continues to advance, some algorithms may need updating. Early adopters might have to migrate keys in the future, which can introduce operational friction or require additional tooling.
### Success Metrics
Success Metrics
1. Functional Completion Milestones
• Successful generation of a unified master seed compatible with Zcash, Bitcoin, Solana, and EVM chains.
• Fully operational local-only, quantum-resistant encryption engine.
• Stable shielded transaction support for Zcash (core requirement).
• Cross-chain send/receive flows passing internal QA tests.
2. Security & Reliability Benchmarks
• Zero critical vulnerabilities found after internal audits and contracted reviews.
• ≥ 99% successful transaction signing rate across supported networks.
• Full deterministic recovery: wallet must be restorable solely from encrypted vault + password.
• Verified PQ-upgrade path (demonstrated through test vectors or prototype implementation).
3. Performance Metrics
• Wallet load time under 2 seconds on modern mobile devices.
• Zcash sync (transparent + shielded) performing within accepted benchmarks.
• Transaction signing executed in under 200ms for all chains.
4. User Adoption Indicators
• Minimum 500 early testers using the wallet prototype within 60–90 days.
• Minimum 200 unique Zcash addresses created through QuBit.
• Documented feedback collected through surveys, GitHub issues, or community channels.
5. Ecosystem Alignment & Open-Source Impact
• Public release of code repositories with full documentation.
• At least 10 external contributors or community-driven PRs within the first 6 months.
• Integration of Zcash-specific improvements that are reusable by other developers.
• At least one collaboration or integration with another privacy-focused project.
6. Roadmap Delivery Metrics
• All Phase 1 & 2 features delivered within the planned timeline.
• demonstrable progress on Zcash-specific integrations (shielded flows, privacy UX).
• Monthly updates and publicly trackable progress via GitHub or Twitter/X.
### Milestone Details
```milestones.yaml
- Milestone: 1 — Core Architecture & Local Vault
Amount (USD): 10,000
Expected Completion Date: 2025-01-15
User Stories:
- "As a security-focused user, I want my keys stored only on my device so that no one can ever access my funds remotely."
- "As a privacy user, I want a single master seed for all chains so that I don’t have to manage multiple backups."
Deliverables:
- 32-byte master seed generator (deterministic, secure)
- Local-only encryption vault using AES-GCM + PBKDF2
- Password-based lock/unlock system
- Seed restoration workflow
- Internal documentation of cryptographic architecture
Acceptance Criteria:
- Vault can be created, locked, and unlocked successfully
- Master seed never leaves the device
- Deterministic test vectors validated
- Milestone: 2 — Zcash Integration (Core Grant Focus)
Amount (USD): 12,000
Expected Completion Date: 2025-02-15
User Stories:
- "As a Zcash user, I want to generate ZEC addresses so I can receive transparent and shielded funds."
- "As a privacy user, I want shielded support so that my transactions remain confidential."
Deliverables:
- Zcash key derivation from master seed
- Transparent + Shielded address support
- RPC integration for balance queries
- Basic ZEC send/receive (t→t)
- Sync logic + error handling
Acceptance Criteria:
- User can generate ZEC addresses
- Balances load correctly
- At least one successful testnet transaction
- Milestone: 3 — Multichain Engine (BTC, Solana, EVM)
Amount (USD): 8,000
Expected Completion Date: 2025-03-10
User Stories:
- "As a multi-chain user, I want one vault for all my assets so that I don't need multiple apps."
- "As a technical user, I want deterministic derivations to ensure stable addresses."
Deliverables:
- BTC Bech32 key derivation
- Solana key derivation + RPC integration
- EVM derivation + RPC integration
- Unified address panel
- Cross-chain error handling
Acceptance Criteria:
- Deterministic address generation on all chains
- Balances load consistently
- Stable multichain prototype
- Milestone: 4 — Privacy UX + Shielded Zcash Transactions
Amount (USD): 7,000
Expected Completion Date: 2025-04-05
User Stories:
- "As a Zcash privacy user, I want an easy interface for shielded transactions so that privacy doesn't require technical knowledge."
- "As a non-expert user, I want clear guidance so I don't confuse address types."
Deliverables:
- Shielded send/receive interface
- Address-type explanations
- Fee estimator + preview system
- Local transaction history
- Error recovery system
Acceptance Criteria:
- Successful z→z and t→z testnet transactions
- UX validated with early testers
- No blocking UX issues
- Milestone: 5 — Security & Performance Audit
Amount (USD): 5,000
Expected Completion Date: 2025-04-25
User Stories:
- "As a cautious user, I want proof the wallet is secure so I can trust it with real funds."
- "As a developer, I want assurance the system is future-proof for quantum upgrades."
Deliverables:
- Independent security review
- Threat model documentation
- PQ upgrade path outline
- Patch implementation
- Performance benchmarks
Acceptance Criteria:
- Zero critical vulnerabilities
- Audit patches implemented
- Benchmarks meet targets
- Milestone: 6 — Public Release Candidate
Amount (USD): 3,000
Expected Completion Date: 2025-05-20
User Stories:
- "As a crypto user, I want a polished wallet I can test and evaluate."
- "As a privacy advocate, I want reliable Zcash support in a self-custodial client."
Deliverables:
- Public release candidate (web/mobile-friendly)
- Website + documentation + onboarding
- Community test group deployment
- Feedback system
- Final optimization
Acceptance Criteria:
- Public prototype accessible
- 100+ users onboarded
- No major blocking bugs
```
total amount requested
### Supporting Documents
```files.yaml
QuBit Wallet Roadmap - https://drive.google.com/file/d/1GH14F2uobRZswl3AD-_7YGfs79z7Ghw0/view?usp=drivesdk
```