# Hackmas: Zeeder

**URL:** <https://forum.zcashcommunity.com/t/hackmas-zeeder/54675>\
**Category:** Zcash Foundation\
**Created:** [February 12, 2026, 4:06pm UTC](https://forum.zcashcommunity.com/t/hackmas-zeeder/54675 "2026-02-12T16:06:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ZcashFoundation](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcashfoundation/32/21548_2.png) [@ZcashFoundation](https://forum.zcashcommunity.com/u/ZcashFoundation)\
**Post date:** [February 12, 2026, 4:06pm UTC](https://forum.zcashcommunity.com/t/hackmas-zeeder/54675/1 "2026-02-12T16:06:14Z")

</div>

_This post features work completed by_ @alchemydc.

For this year’s “Hackmas,” I developed [zeeder](https://zfnd.org/strengthening-the-zcash-network-announcing-a-native-rust-dns-seeder/), a modern, Rust-based DNS seeder for the Zcash network.

## What I Worked On

I built a high-performance DNS seeder designed to replace legacy C++ and Go implementations that have become difficult to maintain. The core of the project is its integration with our team’s `zebra-network` crate, allowing us to “dogfood” our own networking stack for peer discovery and management.

## Why It’s Useful

Legacy seeders are often siloed from our primary development efforts. By moving to a Rust-based architecture that consumes zebra-network, the seeder automatically benefits from any incremental improvements or protocol updates we make to the underlying crate. It also introduces modern features like:

- **Rate Limiting:** Per-IP rate limiting via the governor crate to prevent zeeder from being used to perpetrate UDP amplification attacks.
- **Observability:** Full Prometheus metrics integration for tracking eligible peer counts and query volume.
- **Performance:** An address cache behind a read-write lock that’s updated every five seconds, eliminating lock contention during high query loads. (thanks [@arya](https://github.com/arya2)!)

## Current Status

The project is currently in **Beta** and is considered **ready for production testing**.

## Discoveries and Conclusions

A key technical takeaway was the effectiveness of using` tokio::sync::watch` channels for the address cache. This design allows the DNS server to serve filtered, pre-shuffled peer lists with near-zero latency, even while the crawler task is busy updating the internal address book. Additionally, using zebra-network ensured immediate protocol compliance without having to recreate complex Zcash-specific handshaking logic.

## Community Feedback

We are looking for feedback from the community on **deployment and performance**. Specifically:

- Results from running the seeder in different geographical regions.
- Feedback on the current rate-limiting defaults (10 queries/second per IP).
- Any issues encountered when integrating the seeder into existing Zcash infrastructure.
- Please report any bugs found as Github issues.

## What’s Next

Our next priorities for the seeder will be:

- **Health Check:** the seeder should expose a health check to better integrate with cloud native deployments.
- **Helm Chart:** to make it easy to deploy into Kubernetes environments.
- **Advanced Filtering:** Refining the “eligible peer” criteria to include more granular health checks.