Hi everyone,
I’m submitting this proposal for community feedback and ZCG consideration. Tachyon-Lite is intended to make shielded Zcash wallet development easier by providing a Rust-first light-client SDK, a privacy-safe sync/proof server prototype, WASM/JavaScript bindings, and a reference web wallet.
The goal is to build practical developer infrastructure that works with current Zcash light-client patterns while keeping the architecture open to future Tachyon/Ragu-style proof-carrying sync.
How did you learn about Zcash Community Grants
Through Zcash ecosystem research and community discussions
Requested Grant Amount (USD)
40000
Category
Infrastructure
Project Lead
Name: Chris Frank
Role: Project Lead / Lead Engineer
Background:
Chris Frank is a software developer and open-source builder with public work available at github.com/zynorr. He will lead the technical design and implementation of Tachyon-Lite, focusing on privacy-preserving wallet infrastructure, light-client sync architecture, developer tooling, and the reference SDK/demo wallet.
Responsibilities:
Chris will be responsible for overall project execution, architecture, implementation of the Rust SDK and sync/proof server MVP, WASM/JS bindings, documentation, milestone delivery, testing, community updates, and communication with Zcash Community Grants.
Additional Team Members
Name: Dasai
Role: Software Engineer / SDK & Frontend Contributor
Background: Dasai is an open-source developer with public work available at github.com/NaDasai. They will support the implementation of Tachyon-Lite’s developer-facing components, including SDK integration, web wallet functionality, testing, and documentation.
Responsibilities: Dasai will assist with the WASM/JavaScript bindings, reference web wallet, API integration, developer examples, frontend testing, and documentation. he will also support milestone delivery by helping validate the SDK and server from an application developer’s perspective.
Project Summary
Tachyon-Lite is a Zcash light-client SDK and sync/proof server prototype that helps developers build fast, privacy-preserving shielded wallets without running a full node. The project will deliver a Rust SDK, WASM/JavaScript bindings, a privacy-safe compact sync server, and a reference web wallet as a foundation for future Tachyon/Ragu-style proof-carrying sync.
Project Description
Tachyon-Lite is a current-Zcash-compatible light-client SDK and sync/proof server prototype designed to make shielded Zcash easier to integrate into wallets, mobile apps, and web applications.
The project addresses a key developer adoption challenge: building a reliable shielded Zcash wallet today requires understanding compact blocks, client-side note detection, wallet state management, nullifier tracking, transaction construction, and sync infrastructure. Tachyon-Lite will package these responsibilities into a clean developer-facing stack consisting of a Rust SDK, WASM/JavaScript bindings, a privacy-safe sync server, and a reference web wallet.
The sync server will index public Zcash compact block data from a full node and serve block ranges, tree checkpoints, and proof metadata without receiving wallet viewing keys, note ownership data, balances, or decrypted note information. Wallets will perform note detection locally, preserving the privacy model expected from shielded Zcash.
The SDK will provide abstractions for wallet sync, local note storage, balance calculation, proof verification, and transaction-building interfaces. The first version will include a mock proof-carrying data layer to validate the architecture and API design, while leaving room for future integration with stronger proof systems and Tachyon/Ragu-style recursive proof infrastructure as those designs mature.
The grant will fund a focused MVP: technical architecture, Rust SDK core, sync/proof server prototype, WASM/JavaScript bindings, reference web wallet, documentation, and benchmark/reporting materials. The goal is to give Zcash developers a practical foundation for building faster, safer, and more user-friendly shielded applications.
Proposed Problem
Building shielded Zcash applications is still too difficult for most developers. A team that wants to add ZEC support to a wallet or app must understand Zcash-specific sync logic, compact blocks, note detection, nullifier tracking, wallet state management, transaction-building flows, and privacy risks around server queries.
This complexity slows adoption and makes it harder for developers to ship reliable shielded wallets, especially for web and mobile environments where full-node operation is unrealistic. Existing light-client infrastructure is useful, but developers still need clearer SDK abstractions, modern bindings, reference implementations, and better patterns for privacy-safe sync.
Tachyon-Lite addresses this by packaging the core pieces into a developer-friendly light-client stack: a Rust SDK, WASM/JavaScript bindings, sync/proof server prototype, and reference wallet that preserve the principle that keys, notes, balances, and ownership detection stay on the client.
Proposed Solution
Tachyon-Lite will solve this problem by providing a developer-ready light-client stack for shielded Zcash applications.
The project will deliver a Rust SDK that abstracts wallet sync, local note detection, balance calculation, nullifier tracking, proof verification interfaces, and transaction-building flows behind a clean API. This allows developers to integrate shielded Zcash functionality without rebuilding the full light-client stack from scratch.
Tachyon-Lite will also include a sync/proof server prototype that indexes public Zcash compact block data and serves privacy-safe sync ranges to clients. The server will not receive viewing keys, decrypted notes, wallet balances, or wallet-owned nullifiers. Wallets will perform ownership detection locally, preserving the privacy model expected from shielded Zcash.
To make the stack easier to adopt, the project will include WASM/JavaScript bindings and a reference web wallet showing how to sync, display shielded balance, verify proof metadata, and prepare shielded transaction flows. A mock proof-carrying data layer will validate the architecture now while keeping the system ready for future integration with stronger proof systems and Tachyon/Ragu-style recursive proofs.
Together, these components will reduce integration complexity, improve developer experience, and create a practical foundation for faster, privacy-preserving Zcash wallets and applications.
Solution Format
Deliverables:
Rust SDK core: wallet sync abstractions, local note detection interfaces, balance calculation, nullifier tracking, proof verification interfaces, and transaction-building scaffolding.
Sync/proof server prototype: a Rust server that indexes public Zcash compact block data, serves compact sync ranges, exposes proof metadata endpoints, and keeps wallet-private data off the server.
Mock proof-carrying data layer: an initial proof interface that validates the architecture and can later be replaced with stronger proof systems or Tachyon/Ragu-style recursive proofs.
WASM/JavaScript bindings: browser/app-facing bindings for developers who want to integrate Tachyon-Lite into web wallets or JavaScript applications.
Reference web wallet: a simple demo wallet showing sync, balance display, proof status, and basic shielded transaction flow.
Documentation: architecture overview, API reference, SDK usage examples, setup guide, privacy model, and milestone report.
Benchmark report: basic measurements comparing sync behavior, API response times, and developer integration flow against a baseline light-client setup.
Dependencies
Technical dependencies:
Rust toolchain for SDK and server development.
Existing Zcash Rust libraries where appropriate, including Zcash client/backend primitives for compact blocks, note detection, wallet state, and transaction-related functionality.
A Zcash full node or lightwalletd-compatible data source for development and testing.
SQLite for local wallet storage in the SDK/demo wallet.
PostgreSQL or RocksDB for the sync/proof server prototype, depending on final implementation choice.
WASM toolchain for JavaScript/browser bindings.
React or a similar frontend framework for the reference web wallet.
Mock proof layer for the MVP, with interfaces designed for future integration with stronger proof systems.
Resource dependencies:
Developer time from the project lead and contributor.
Testnet access for development and demo validation.
Hosting or cloud infrastructure for a demo sync/proof server.
Community feedback from Zcash developers and wallet builders.
Documentation, benchmarking, and testing time before final delivery.
Technical Approach
Tachyon-Lite will be built as a modular Rust-first light-client stack with clear separation between wallet logic, sync infrastructure, proof interfaces, and developer bindings.
The MVP will use current Zcash-compatible light-client patterns: the server will index public compact block data from a Zcash node or lightwalletd-compatible source, while the wallet SDK performs note detection, balance calculation, and nullifier tracking locally. This ensures the server does not receive viewing keys, decrypted notes, wallet balances, or wallet-owned note data.
The core components will be:
Rust SDK core: wallet state management, sync coordination, local note detection interfaces, proof verification interfaces, transaction-building scaffolding, and encrypted/local storage abstractions.
Sync/proof server: Rust API server using Axum or a similar framework, backed by PostgreSQL or RocksDB for indexed compact block data, tree checkpoints, nullifier records, and proof metadata.
Proof interface: mock proof-carrying data layer for the MVP, designed so future recursive proof systems or Tachyon/Ragu-style primitives can be integrated without redesigning the SDK.
WASM/JavaScript bindings: generated from the Rust SDK using WASM tooling so web developers can use the SDK from browser or JavaScript applications.
Reference wallet: React/TypeScript web wallet demonstrating sync, shielded balance display, proof status, and basic send-flow scaffolding.
Development tools will include Rust, Cargo, Tokio, Axum, Serde, SQLite, PostgreSQL/RocksDB, wasm-pack, TypeScript, React, and automated tests. The project will also include API documentation, SDK examples, benchmark scripts, and testnet-based validation.
The implementation will be milestone-driven: first architecture and protocol design, then SDK/server MVP, then WASM and demo wallet, followed by testing, documentation, and benchmarking.
Upstream Merge Opportunities
For the MVP, Tachyon-Lite does not require forking or modifying core Zcash consensus software. The project will primarily build on top of existing Zcash infrastructure through clean SDK/server integrations.
Upstream repositories we may interact with:
zcash/librustzcash: possible integration feedback, examples, documentation improvements, or small SDK-facing patches discovered while building the Rust client layer.
zcash/lightwalletd: compatibility testing, documentation notes, and potential API/protocol feedback around compact block sync behavior.
ZcashFoundation/zebra: future compatibility consideration for node/data-source integration as the ecosystem continues moving toward Rust-based node infrastructure.
zcash/zcash: no planned modifications for this MVP; only used as a reference/full-node data source where needed.
Planned changes:
Most Tachyon-Lite work will live in its own repository. If we identify reusable improvements while integrating with existing Zcash crates or light-client infrastructure, we may submit small upstream PRs such as documentation updates, examples, test fixtures, compatibility fixes, or developer-experience improvements.
Ecosystem benefit:
Any upstreamable work could help wallet developers by improving examples, clarifying light-client integration patterns, and documenting privacy-safe sync assumptions.
Coordination needed:
Before submitting non-trivial upstream changes, we would open issues or discussion threads with the relevant maintainers to confirm scope and avoid duplicating existing roadmap work.
Timeline:
Upstream merge opportunities would be evaluated after the MVP architecture and integration work are complete, likely during the final testing/documentation milestone. The main grant deliverable does not depend on upstream merges.
Hardware/Software Costs (USD)
3000
Hardware/Software Justification
Cloud hosting for demo sync/proof server: $1,200
Zcash node/lightwalletd-compatible testing infrastructure: $800
Domain, monitoring, logging, and basic deployment services: $400
Development/testing devices, storage, and backup resources: $600
Service Costs (USD)
2000
Service Costs Justification
Cloud infrastructure services for staging/demo deployment: $1,000
Monitoring/logging/error tracking services: $400
Domain/DNS/SSL and deployment support services: $200
CI/build minutes or artifact hosting as needed: $400
Compensation Costs (USD)
35000
Compensation Costs Justification
Project lead / lead engineer: $24,000
SDK/frontend contributor: $8,000
Documentation, testing, and release support: $3,000
Total Budget (USD)
40000
Previous Funding
No
Previous Funding Details
No response
Other Funding Sources
No
Other Funding Sources Details
No response
Implementation Risks
The main implementation risk is technical complexity around Zcash shielded wallet infrastructure. Correctly handling compact sync, local note detection, nullifier tracking, wallet state, and transaction-building requires careful integration with existing Zcash libraries and close attention to privacy assumptions.
A second risk is scope creep. Full Tachyon/Ragu-style proof-carrying synchronization is an ambitious long-term goal, but those primitives are not the core requirement for this MVP. To reduce this risk, the project will clearly separate the current-Zcash-compatible MVP from the experimental proof interface and use a mock proof layer for the first milestone.
There is also integration risk around upstream Zcash libraries and node/lightwalletd-compatible data sources. APIs, crate versions, or ecosystem infrastructure may change during development. We will manage this by using stable existing interfaces where possible, documenting assumptions, and keeping the SDK modular.
Performance and scalability are another risk. Sync servers can become bandwidth- or storage-heavy if block range APIs are not designed carefully. The MVP will include basic benchmarks, pagination/range limits, caching assumptions, and documentation for scaling the server.
Finally, there is security and privacy risk if API design accidentally leaks wallet-specific information. The project will mitigate this by avoiding server-side viewing keys, balances, decrypted notes, and direct wallet-owned nullifier queries in the normal sync flow. Privacy assumptions and limitations will be documented clearly.
Potential Side Effects
One potential side effect is that developers may overestimate the privacy guarantees of the MVP if the limitations are not communicated clearly. Tachyon-Lite will therefore document that the first version uses current Zcash-compatible compact sync patterns and a mock proof layer, not full Tachyon/Ragu-style oblivious synchronization.
Another possible negative impact is increased reliance on third-party sync servers. Even when wallet-owned notes are detected locally, servers can still observe metadata such as IP address, timing, requested block ranges, and transaction broadcasts. The project will address this by documenting the privacy model and recommending mitigations such as Tor, range padding, batching, and self-hosted server options.
There is also a risk that incomplete or experimental SDK code could be used in production before it is mature. To reduce this risk, the MVP will clearly label experimental components, include warnings where appropriate, and avoid presenting mock proofs as real cryptographic security.
Finally, if the server API is implemented incorrectly by downstream developers, it could introduce privacy leaks. Tachyon-Lite will provide a reference implementation and guidance so developers can follow privacy-safe patterns rather than inventing unsafe query flows.
Success Metrics
Delivery of an open-source Tachyon-Lite MVP repository with Rust SDK, sync/proof server prototype, WASM/JavaScript bindings, reference web wallet, and documentation.
Successful local/testnet demo showing wallet sync, local note detection flow, balance display, proof metadata verification, and transaction-building scaffolding.
Server API demonstrates privacy-safe sync behavior by avoiding viewing keys, decrypted notes, wallet balances, and direct wallet-owned note queries.
SDK exposes clear developer APIs for sync, balance, proof verification, and transaction-building interfaces.
Reference web wallet can connect to the server prototype and complete the expected demo flow.
Documentation includes architecture overview, API reference, SDK usage examples, setup instructions, privacy model, limitations, and future roadmap.
Benchmark report measures sync behavior, API response times, and developer integration flow for the MVP.
At least one public demo, community update, or forum post is shared with the Zcash community for feedback.
Any reusable improvements or findings for existing Zcash tooling are documented and, where appropriate, proposed upstream.
Startup Funding (USD)
10000
Startup Funding Justification
Startup funding is needed to begin the project before the first major implementation milestone is complete. It will cover the initial technical design, repository setup, development environment, infrastructure preparation, and early SDK/server scaffolding.
The funds will be used for project kickoff work, including finalizing the architecture, defining API boundaries, setting up the Rust workspace, creating the initial sync/proof server structure, preparing SDK interfaces, and configuring testing/deployment infrastructure. This upfront work is necessary to de-risk the implementation and ensure the remaining milestones can be delivered efficiently.
Milestone Details
- Milestone: 1
Amount (USD): 10,000
Expected Completion Date: 2026-06-30
User Stories:
- "As a Zcash developer, I want a clear technical architecture for Tachyon-Lite, so that I can understand how the SDK, sync server, proof layer, and demo wallet fit together."
- "As a grant reviewer, I want the project scope to be well-defined, so that progress can be measured against realistic MVP deliverables."
Deliverables:
- Final technical architecture document.
- Privacy model and limitations document.
- API specification for the sync/proof server.
- SDK module design and repository structure.
- Initial open-source repository scaffold.
Acceptance Criteria: The milestone is complete when the repository contains the architecture docs, API spec, privacy model, SDK/server module outline, and initial project scaffold.
- Milestone: 2
Amount (USD): 10,000
Expected Completion Date: 2026-08-15
User Stories:
- "As a wallet developer, I want a Rust SDK core with clean wallet sync abstractions, so that I can begin integrating shielded Zcash functionality without building everything from scratch."
- "As a developer, I want local note detection and wallet state interfaces, so that wallet-private data remains on the client."
Deliverables:
- Rust SDK core crate.
- Wallet, account, sync coordinator, note store, balance, and proof verification interfaces.
- Local storage abstraction for wallet state.
- Unit tests for SDK interfaces and sync flow.
- Example SDK usage code.
Acceptance Criteria: The milestone is complete when the SDK compiles, tests pass, and a developer can run an example showing wallet initialization, sync abstraction usage, and balance/state interface calls.
- Milestone: 3
Amount (USD): 12,500
Expected Completion Date: 2026-09-30
User Stories:
- "As a wallet developer, I want a sync/proof server prototype, so that clients can request compact sync data without exposing viewing keys or decrypted notes."
- "As an infrastructure operator, I want documented API endpoints, so that I can run and test the server."
Deliverables:
- Rust sync/proof server prototype.
- Endpoints for health, server info, compact block ranges, tree checkpoints, proof metadata, and transaction broadcast scaffolding.
- Mock proof-carrying data layer.
- Basic indexed data model for compact block and proof metadata.
- Integration tests for server endpoints.
Acceptance Criteria: The milestone is complete when the server runs locally, exposes documented endpoints, returns sample compact sync/proof data, and passes integration tests confirming that no viewing keys, balances, or decrypted note data are required by the server.
- Milestone: 4
Amount (USD): 7,500
Expected Completion Date: 2026-11-15
User Stories:
- "As a web developer, I want WASM/JavaScript bindings and a reference wallet, so that I can see how Tachyon-Lite can be used in a browser application."
- "As a Zcash community member, I want documentation and benchmarks, so that I can evaluate the usefulness and limitations of the MVP."
Deliverables:
- WASM/JavaScript bindings for the SDK.
- Reference web wallet demo.
- Demo flow for sync, balance display, proof status, and transaction-building scaffolding.
- Setup guide, API reference, SDK usage examples, and privacy notes.
- Basic benchmark report and final milestone report.
Acceptance Criteria: The milestone is complete when the demo wallet runs locally, connects to the server prototype, demonstrates the expected sync/proof-status flow, and the repository includes complete setup documentation, API docs, examples, and benchmark results.