### 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)
@safeguard @Jules0x
### Organization Name
Jules0x
### How did you learn about Zcash Community Grants
I am a member of the community and I start investigate about zcash because I was so interested in the privacity coins like monero and zcash obviously
### Requested Grant Amount (USD)
40000
### Category
Infrastructure
### Project Lead
```project-lead.yaml
Name: SafeGuard Labs Role: Developer Background: I am an enthusiastic developer who loves working on many different things. My career started at school creating designs and using Python to learn new topics. From there, I moved into video game development using Unity and Godot, and then started creating websites for local businesses and my community.
I also launched a YouTube channel to share tech and crypto content in Spanish. Later, I built software tools for companies, including AI Agents capable of controlling droplets and automating Google tasks like creating documents and answering forms.
Recently, I focused on the blockchain community. After taking many courses, I started developing wallets (designing for Algorand) and infrastructure tools. You can see one of my active tools at znodes.live. I also created a public repository for Namada documentation. Currently, I am working on getting my OSCP certification from OffSec to deepen my security skills.
Responsibilities: As a principal member of this project, I will develop the platform's core code and interface. My responsibilities include designing the infrastructure, implementing the platform architecture, and managing all necessary updates and changes.
```
### Additional Team Members
```team-members.yaml
Name: Jules0X
Role: Developer
Background:
Hello, I’m Jules. I’m a web designer and developer. I’m going to design the platform because, to me, one of the most important things when building a platform is making sure that the essential information is easy to access, and that the platform is smooth and simple to navigate.
I helped design part of the znodes platform, and I’ve been involved in several projects at SafeGuard, like building websites and other tech solutions. I’m passionate about design and I have a strong interest in blockchain. I like to explore and learn a lot about it.
I specialize in Python, TypeScript, CSS, HTML, and JavaScript. These skills let me work on both the design and the development side of things, and I’m always looking to improve and learn new tech.
Responsibilities:
In this project, I will be responsible for designing and developing the platform. I’ll focus on making sure it’s easy to use and looks great, while also working on the backend code to keep everything running smoothly.
```
### Project Summary
A production monitoring layer for Zcash with public APIs, real-time alerts, and lightwalletd health checks. After Nighthawk shut down, this gap became very clear. This project gives developers real network visibility so they can build and run reliable Zcash services.
### Project Description
Right now, the Zcash ecosystem is missing something very important: real monitoring infrastructure that developers can actually use. After Nighthawk shut down in May 2024, wallet developers lost lightwalletd tracking, node operators don’t have alerts when something breaks, and exchanges ask for network health APIs that simply don’t exist.
This project is about fixing that.
I already built ZNodes, a platform that shows Zebra nodes in real time, and the response from the community has been really good. But ZNodes is just the beginning — it’s going to become one part of a much bigger monitoring system for Zcash.
Main components of the project:
- Public Network API
REST and gRPC endpoints that expose node counts, network metrics like TPS and block time, and geographic distribution. Everything is OpenAPI documented so developers can integrate fast and without friction.
- Lightwalletd Monitoring
Continuous health checks for public lightwalletd endpoints like zec.rocks, including latency tracking across regions. This is critical, because more than 100,000 wallet users depend on these services working properly.
- Alert System
Webhooks, Discord alerts, and email notifications when node counts drop or when lightwalletd services fail. This includes Prometheus rules based on real problems, like the ones discussed in GitHub Issue #8830.
- Migration Dashboard
A real-time view of zcashd vs Zebra distribution, so the community can clearly see how the deprecation and migration process is going.
- Node Setup Guides
Clear, practical documentation to install Zebra nodes: server setup, security basics, firewall configuration, common errors, and how to fix them. A lot of people struggle running nodes, so this part is about making it easier for anyone to participate.
Everything is open-source and API-first. The idea is that other developers can build on top of this without limitations.
ZNodes stops being the main product and becomes one feature inside a larger monitoring platform built for the whole Zcash ecosystem.
### Proposed Problem
Zcash network operators are basically flying blind right now. There are three critical problems in the ecosystem:
**No API access to network health**
Exchanges, wallets, and researchers have no way to query the Zcash network programmatically. Bitcoin has dozens of public services for node counts and health metrics. Zcash has zero public APIs that show this kind of data.
**Lightwalletd with no monitoring**
Every major wallet — Zashi, Zingo, Ywallet — depends on lightwalletd servers, but there is no real health monitoring. When Nighthawk shut down, wallets had to rush into emergency migrations because there was no warning system in place.
**No visibility into the migration**
The network is moving from zcashd to Zebra, but nobody can really track it. Blockchair doesn’t show Zebra nodes, and the community has no clear way to see network health during this transition.
**This has real consequences**
The 51% hashrate pool issue was detected through manual warnings, not automated alerts. Node counts dropped from around 170 to 130 without clear, accessible data. This is not acceptable for a network that is securing real value.
### Proposed Solution
Building the production monitoring infrastructure the Zcash ecosystem actually needs, designed API-first so other developers can build on top of it.
### Network Operations API
- REST and gRPC endpoints for node discovery, network metrics, and lightwalletd status
- OpenAPI specification for automatic client generation
- Public access tier plus authenticated tier for production use
- Target performance: under 200ms response time, 99.5% uptime
### Lightwalletd Monitor
- Continuous health checks from 4+ regions (NA, SA, EU, AP)
- Latency tracking, uptime metrics, and version monitoring
- Failure detection in under 60 seconds
- Historical data available for analysis and debugging
### Alerting System
- Webhooks, Discord, email, and PagerDuty integrations
- Alerts for node count drops, sync delays, and hashrate issues
- Prometheus rulesets ready to deploy
- Directly addresses Zebra Issue #8830
### Migration Dashboard
- Real-time visibility into zcashd vs Zebra distribution
- Node version breakdown with historical trends
- Geographic visualization of the network
- Full programmatic access via API
### Node Documentation
- Step-by-step guides for installing Zebra nodes
- Security best practices and firewall configuration
- Common errors and how to fix them
- Wallet integration guides
- Makes running nodes accessible to more operators
### Solution Format
**infrastructure**
The infrastructure is built to be reliable and simple to use. The API server is designed for 99.5% uptime and everything is open-source on GitHub under an MIT license, so anyone can inspect it, use it, or build on top of it. There will be a public web dashboard for visibility, and official SDKs for JavaScript and Python, published on npm and PyPI, so developers can integrate without friction.
**Documentation**
Documentation is treated as a first-class feature, not an afterthought. The project includes full API documentation using an OpenAPI spec, clear integration guides for developers, and step-by-step instructions to install nodes from scratch. It also covers security best practices, firewall configuration, common troubleshooting scenarios, and a complete deployment runbook. A CONTRIBUTING.md is included to make it easy for others to help improve the project.
**Monitoring**
Monitoring is built for real-world operations. The platform ships with Prometheus alert rules, ready-to-use Grafana dashboards, and multi-region health checks to catch issues early. Alerts are properly routed so operators get the right signal at the right time, not just noise.
**Operator Guides**
For node operators, there are dedicated guides that walk through installation, security practices, and how to solve common errors. It also explains how to connect nodes with wallets, making it easier for more people to run infrastructure and support the network.
### Dependencies
**Technical**:
- DNS seeders from ZF (dnsseed.z.cash) for node discovery
- Public lightwalletd endpoints (zec.rocks, mainnet.lightwalletd.com) for monitoring
- Zebra/zcashd version info through P2P
- And the Ziggurate
### Technical Approach
**Architecture**
The backend is split by responsibility to keep things fast and reliable. The network crawler is built in Rust because it needs to handle 2,500+ concurrent connections, and Rust gives us the performance and safety for that. The API server is written in Go, which is great for building high-traffic APIs. For data storage, we use TimescaleDB for time-series metrics and PostgreSQL for node and network data.
**Crawler Implementation**
The crawler extends ideas from Ziggurat-style patterns, with improvements for better connection handling and stability. It reconnects every 60 seconds and uses multi-layer filtering to remove Flux nodes, testnet nodes, desynced nodes, and unknown agents. This keeps the data clean and focused on healthy nodes. Discovery is enhanced by integrating ZF DNS seeders.
**API Design**
The platform exposes a REST API with an OpenAPI 3.0 spec, so developers can auto-generate clients easily. For higher performance use cases, gRPC is also available. Authentication is handled with JWT for the production tier, and rate limits are in place: 100 requests/min for the public tier and 1,000 requests/min for authenticated users.
**Monitoring Stack**
Metrics and alerts are handled with Prometheus, combined with a custom alert dispatcher that routes notifications to webhooks, Discord, email, or PagerDuty. Health checks run from multiple regions (NA, SA, EU, AP) to get real latency and availability data. Everything is self-hosted to avoid unnecessary centralization.
**Frontend**
The dashboard is built with React and updates in real time. Geographic data is shown using Leaflet, metrics and trends are visualized with Recharts, and the entire UI is mobile-responsive, so it works well on desktop and phones.
### Upstream Merge Opportunities
This project doesn’t modify or fork Zcash repositories, so there won’t be direct merges with Zcash Core. That said, there are still opportunities for collaboration:
Ziggurat Network Crawler:
Improvements to node discovery could help the Ziggurat project. If I find better ways to handle connections or filtering, I can submit PRs to [github.com/runziggurat](https://github.com/runziggurat)
. The Shielded Labs maintainer has already encouraged this.
Zebra Monitoring:
The Prometheus alert rules and health-check patterns could be useful for Zebra operators.
Timeline:
There are no dependencies on upstream work, so the project can progress independently and integrate later. If useful patterns emerge, I’ll propose them upstream when ready.
### Hardware/Software Costs (USD)
0
### Hardware/Software Justification
We are going to use open-source software for everything so there are no licensing costs. Rust, Go, PostgreSQL, TimescaleDB, Prometheus, React are all open-source and free to use. Development tools like VS Code and Git are also free. This keeps costs down and aligns with the open-source philosophy of the Zcash ecosystem.
### Service Costs (USD)
8000
### Service Costs Justification
Primary Infrastructure (Year 1):
Bare metal VPS for API server and crawler: $150/month × 12 = $1,800
Secondary VPS for redundancy: $80/month × 12 = $960
Regional monitoring probes (4 locations for multi-region health checks): $40/month × 4 × 12 = $1,920
Managed TimescaleDB for time-series data: $200/month × 12 = $2,400
Domain registration and SSL certificates: $30/month × 12 = $360
CDN for API (Cloudflare Pro): included in domain costs
Contingency buffer: $560
These services are necessary because the API needs to be available 24/7 with good performance globally. The multi-region probes give us accurate latency data from different parts of the world which is important for the lightwalletd monitoring. Managed database reduces operational burden so I can focus on development instead of database administration.
### Compensation Costs (USD)
32000
### Compensation Costs Justification
Development Work Breakdown:
All development is going to be done by me as the sole developer on this project.
Milestone 1 (API Infrastructure): 120 hours × $100/hr = $12,000
Milestone 2 (Node Discovery + Migration Dashboard): 100 hours × $100/hr = $10,000
Milestone 3 (Alerting + Lightwalletd Monitoring): 120 hours × $100/hr = $12,000
Milestone 4 (Documentation + SDK): 80 hours × $100/hr = $8,000
Subtotal: $42,000
Requested: $32,000
I am absorbing $10,000 of the development cost as my contribution to the Zcash ecosystem because I really believe in this project and want to see it succeed. The rate of $100/hour is actually below market rate for blockchain infrastructure development which typically runs $150-200/hour. This shows my commitment to keeping costs reasonable while delivering quality work.
Time Allocation:
Total project duration is 16 weeks with approximately 25-30 hours per week of focused development work. This is realistic for a solo developer building production-grade infrastructure.
### Total Budget (USD)
38000
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
**Technical Risks:**
**Node Discovery Accuracy** - Risk that the crawler misses some nodes or misidentifies versions. Mitigation is to cross-reference with multiple DNS seeders and use multiple connection attempts. I am also going to compare results with existing tools like Ziggurat to validate accuracy.
**API Performance at Scale** - If the API gets really high traffic it might slow down. Mitigation is using Go which handles concurrency well, implementing proper caching, and having rate limiting from the start. The infrastructure is designed to scale horizontally if needed.
**Lightwalletd Endpoints Changing** - Public lightwalletd servers might change addresses or configurations. Mitigation is making the monitoring configuration flexible so new endpoints can be added easily and having alerts when endpoints disappear.
**Multi-Region Infrastructure Costs** - Running monitoring probes in 4+ regions might cost more than estimated. Mitigation is starting with 4 regions and having the architecture support adding or removing regions based on budget.
**Operational Risks:**
**Single Developer Risk** - If I get sick or have an emergency the project could be delayed. Mitigation is having clear documentation from the start and making everything open-source so the community can pick it up if needed. Also breaking work into small milestones so progress is visible.
**Dependency on External Services** - The project depends on DNS seeders and public lightwalletd servers continuing to operate. Mitigation is not really possible but the monitoring will actually help identify when these services have issues so the community can respond.
**Community Adoption** - Risk that developers dont use the APIs even though they are available. Mitigation is active outreach to wallet developers, good documentation, and SDKs in popular languages to reduce integration friction.
All of these risks are manageable and I have thought through mitigation strategies. The biggest risk is really just execution which is why I am committed to monthly updates and transparent progress tracking.
### Potential Side Effects
**Centralization Concern** - Having one monitoring service could create a single point of failure or trust. However the entire stack is open-source and documented for self-hosting so anyone can run their own instance. The code and data are transparent so the community can verify accuracy.
**Privacy Considerations** - The node crawler collects IP addresses and geographic locations. This is already public information available through P2P connections but aggregating it might raise privacy concerns. Mitigation is not storing personally identifiable information beyond what is necessary for network health monitoring and making the data retention policies clear.
**Resource Competition** - The crawler making 2,500+ connections might put some load on the network. However this is similar to what other monitoring tools do and the reconnection intervals are reasonable (60 seconds). The benefit of network visibility outweighs the minimal resource impact.
**Alert Fatigue** - If alerts are too sensitive operators might ignore them. Mitigation is having configurable thresholds, severity levels (critical/warning/info), and good documentation on recommended settings based on different use cases.
**Unintended Positive Effects:**
**Network Health Improvement** - Having visibility into node distribution and lightwalletd status will probably help the community respond faster to problems. This could actually improve overall network resilience.
Lower Barrier for Node Operators - The documentation and guides will make it easier for new people to run nodes which helps decentralization.
**Ecosystem Growth** - Public APIs enable developers to build services we havent even thought of yet. This could attract more developers to build on Zcash.
Overall the potential downsides are manageable and the benefits to ecosystem transparency and developer tooling outweigh the risks.
### Success Metrics
**API Adoption:**
1,000+ API calls/day by Month 3
3+ documented third-party integrations
100+ npm SDK downloads, 50+ PyPI downloads
**Infrastructure Reliability:**
99.5% API uptime
P95 response time <200ms
Data freshness: <15 min for node counts, <5 min for lightwalletd status
**Community Impact:**
- 10+ active alert subscriptions
- 50+ Prometheus ruleset downloads
- Migration dashboard referenced in community updates
**Network Coverage:**
- 95% node detection rate
- 100% of public lightwalletd endpoints monitored
- Health checks from 4+ regions
**Documentation Usage:**
- Guide views tracked via analytics
- 5+ users report successful node setup
- GitHub/forum posts showing documentation use
**Qualitative Metrics:**
- Positive developer feedback on API usefulness
- Community projects integrating data feeds
- Clean code, 80%+ test coverage, contributions from others
**Measurement:**
Metrics tracked monthly via server logs, monitoring, downloads, and user feedback
Final report at project completion summarizing results and lessons learned
### Startup Funding (USD)
10000
### Startup Funding Justification
The startup funding covers initial infrastructure setup and first month of development:
Infrastructure Setup ($3,000):
Primary VPS setup and first 3 months: $450
Database setup and first 3 months: $600
Domain and SSL: $90
Regional probe setup: $480
Testing and configuration: $1,380
Initial Development ($7,000):
First month of work on API architecture, database schema design, and basic crawler implementation. This gets the foundation in place so I can show concrete progress in the first milestone report.
Without startup funding I would have to delay infrastructure setup until the first milestone payment which would slow down the project timeline. The startup funding lets me hit the ground running and deliver Milestone 1 on schedule.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 12000
Expected Completion Date: 2025-05-15
User Stories:
- "As a wallet developer, I want to query network state via REST API so that I can integrate health checks into my application without running my own node"
- "As an exchange operator, I want to access network metrics like TPS and block time in JSON format so that I can automate my monitoring systems"
- "As a researcher, I want to download historical node distribution data so that I can analyze network decentralization trends"
Deliverables:
- RESTful API with endpoints: /nodes, /nodes/{id}, /metrics, /health, /lightwalletd/status
- OpenAPI 3.0 specification published and accessible
- Rate limiting and API key authentication system operational
- Technical documentation on GitHub with usage examples
- API deployed to production domain with SSL
Acceptance Criteria: API responds in under 200ms for 95% of requests. All endpoints documented with working examples. Integration tests passing with more than 80% coverage. Public demo showing API calls returning real data.
- Milestone: 2
Amount (USD): 10000
Expected Completion Date: 2025-06-15
User Stories:
- "As a community member, I want to see real-time stats of Zebra vs zcashd nodes so that I can track migration progress"
- "As a node operator, I want to verify my node appears correctly with its version so that I know it is contributing to the network"
- "As a Zebra developer, I want adoption metrics to report to Zcash Foundation about migration success"
Deliverables:
- Enhanced crawler with complete zcashd and Zebra detection
- Migration dashboard showing real-time distribution with charts
- API endpoint /migration/stats with historical data
- Integration with official DNS seeders
- Geographic visualization of node distribution
Acceptance Criteria: Crawler detects more than 95% of nodes compared to Ziggurat baseline. Correctly distinguishes Zebra vs zcashd vs unknown. Migration data updates every 15 minutes. Historical data available for 90 days. Dashboard accessible and functional on mobile and desktop.
- Milestone: 3
Amount (USD): 12000
Expected Completion Date: 2025-07-15
User Stories:
- "As a wallet developer, I want webhook alerts when lightwalletd endpoints fail so that my app can automatically failover to healthy servers"
- "As a node operator, I want Discord notifications if my node goes offline so that I can fix issues quickly"
- "As a ZCG committee member, I want a status dashboard showing ecosystem health so that I can see infrastructure problems at a glance"
Deliverables:
- Alert system with webhook, Discord, email integrations
- Monitoring of all known public lightwalletd endpoints
- Latency tracking from 4 geographic regions
- Prometheus alert rulesets ready for download
- Public status dashboard (status page style)
- Documentation for integrating alerts into services
Acceptance Criteria: Alerts sent within 60 seconds of problem detection. Lightwalletd monitoring shows uptime and latency from multiple regions. Alert rulesets tested with Zebra and zcashd. At least 3 wallet developers or operators confirm they can integrate the alerts successfully.
- Milestone: 4
Amount (USD): 6000
Expected Completion Date: 2025-08-15
User Stories:
- "As a new Zcash developer, I want npm and pip packages so that I can query network state without implementing the API manually"
- "As an open source contributor, I want clear documentation so that I can contribute improvements to the project"
- "As ZCG, I want usage metrics and adoption data so that I can evaluate if this infrastructure is valuable to the ecosystem"
Deliverables:
- JavaScript/TypeScript SDK published on npm
- Python SDK published on PyPI
- CONTRIBUTING.md and architecture documentation
- Node setup guide with security best practices
- Deployment runbook for self-hosting
- Final report with usage metrics and adoption data
- Presentation of results to community (forum post or ZecHub sync)
Acceptance Criteria: SDKs published and downloadable. More than 3 documented third-party integrations. Code 100% open-source with MIT license. Node setup guide tested by at least 3 community members. Final metrics report shows API usage and impact.
```
