# NoM Utilities
**URL:** http://forum.zenon.org/t/nom-utilities/2368
**Category:** ╰ Funding | Submissions
**Created:** [September 13, 2026, 11:44pm UTC](http://forum.zenon.org/t/nom-utilities/2368 "2026-09-13T23:44:00Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@sol](http://forum.zenon.org/u/sol)
#### Post date: [September 13, 2026, 11:44pm UTC](http://forum.zenon.org/t/nom-utilities/2368/1 "2026-09-13T23:44:01Z")
**Project Name:** NoM Utilities: Zenon Faucet, Address Generators, zts-airdrop, vanity-zts
**Description:** Five open-source utilities for Zenon users, token issuers and developers, all built and published:
| Tool | What it does |
| --- | --- |
| **Zenon Faucet** | Claim GLYPHS by locking PlasmaPoints in an HTLC, from a static page with no backend |
| **znn-address-generator-go** | Multi-threaded mnemonic and vanity `z1…` address generator |
| **znn-address-generator-cuda** | The same on an NVIDIA GPU, about 33× faster |
| **zts-airdrop** | Bulk ZTS airdrop to every address active in a range of momentums, resumable and reproducible |
| **vanity-zts** | Mine a token standard (`zts1…`) with a chosen pattern, offline, with no PoW |
**Why it matters for Zenon:** these are jobs token issuers and community members were doing by hand or couldn’t do at all:
- running a trustless faucet
- airdropping to active users without paying anyone twice
- choosing a recognizable token id
- generating vanity addresses at GPU speed
The faucet also serves as a working reference for HTLC flows through a browser wallet.
**URL:**
- [https://github.com/sol-znn/zenon-faucet](https://github.com/sol-znn/zenon-faucet)
- [https://zenoglyphs.zenon.foo](https://zenoglyphs.zenon.foo)
- [https://github.com/sol-znn/znn-address-generator-go](https://github.com/sol-znn/znn-address-generator-go)
- [https://github.com/sol-znn/znn-address-generator-cuda](https://github.com/sol-znn/znn-address-generator-cuda)
- [https://github.com/sol-znn/zts-airdrop](https://github.com/sol-znn/zts-airdrop)
- [https://github.com/sol-znn/vanity-zts](https://github.com/sol-znn/vanity-zts)
**Team:**
- **sol:** design, implementation, testing, documentation
* * *
**Phases**
**Phase 1: The five tools (delivered)**
High-level overview of main tasks:
- **Zenon Faucet**
- The user locks `N × 1000` PP through the Syrius extension. The page locks `N` GLYPH back under the same hashlock and settles both legs, since `htlc.Unlock` can be called by anyone and pays the address in the entry.
- It handles all three proxy-unlock states. If a user has denied proxy unlock, the page hands the identical block to Syrius for the user to sign.
- It includes a self-contained TypeScript Zenon client (ABI, block, signing, PoW, wallet) built only on the audited `@noble` / `@scure` primitives.
- Expiries are sized for the failure cases: 30 minutes on the user’s leg, 60 minutes on the page’s.
- GitHub Pages deployment, which refuses to build without a mnemonic.
- **znn-address-generator-go**
- A Go port of the original generator, using the same BIP-39 mnemonics and `m/44'/73404'/{account}'` path as `znn_sdk_dart`.
- Prefix and suffix search, and release binaries for Windows, Linux and macOS.
- **znn-address-generator-cuda**
- Every expensive step runs on the GPU: PBKDF2, SLIP-0010, ed25519, SHA3, and Bech32 encoding and matching.
- Per-launch entropy from the OS CSPRNG, expanded per thread with `SHA-512(key ‖ counter)`.
- **zts-airdrop**
- Recipients are addresses that authored a block. Embedded contracts are excluded by address type, receivers are opt-in, and a minimum-holding filter is available.
- Decimals are read from the chain, and over-precise amounts are refused rather than rounded.
- Dry run by default, with a journal that makes an interrupted run resume without paying twice.
- Scan logs with a SHA-256 digest, plus `-verify-scan` and `-replay` so the list that was approved is the list that gets paid.
- **vanity-zts**
- A ZTS is derived from the `IssueToken` block hash, whose nonce (when plasma covers the call) and acknowledged momentum are both free to choose. So the search runs offline, and only the winning block is signed and broadcast.
- Parameters are validated against go-zenon’s `checkToken` before mining.
Completion of Phase 1 will be measured by:
- ✅ All five repositories public, with release binaries for the Go tools
- ✅ Faucet `npm run smoke`: a complete claim against a live devnet, verified from the ledger, with HTLC ABI ids pinned against go-zenon. Last run 20/20
- ✅ CUDA generator benchmark: 55,962 mnemonics/s (279,809 addresses/s) on an RTX 3060, and bit-compatible with the Go tool’s derivation
- ✅ zts-airdrop and vanity-zts exercised against the go-zenon devnet
**Phase 2: Community-requested tools and features (open for suggestions)**
High-level overview of candidate tasks:
- **Faucet:** a configurable template any project can deploy for its own token pair
- **zts-airdrop:** holder snapshots at a height, CSV recipient lists, weighted amounts, and a web UI
- **New tools** requested in this thread
Completion of Phase 2 will be measured by:
- Deliverables agreed per item in this thread before any funding is requested
* * *
**Funding**
**Total Requested Funding** = 2,000 ZNN and 20,000 QSR (Phase 1). Phase 2 is filed separately.
**Project Duration** = 1 week
**How did you calculate your budget?**
- **Scope.** About 6,500 lines for the faucet, 4,300 for the CUDA generator, 3,000 for zts-airdrop, 1,000 for vanity-zts, and 800 for the Go generator, each verified against mainnet and test vectors.
**Project and Payment Milestones:**
**Phase 1**
Funding Request: 2,000 ZNN and 20,000 QSR
Duration: delivered
**Phase 2**
Funding Request: filed as a new project once scope is agreed. A project’s total can’t be raised after creation.
Duration: per item
* * *
**Other Information**
**Risks, Assumptions, Known Issues, Dependencies:**
- **The faucet page holds its own key.** It has to sign unattended, so the faucet wallet should hold only what the faucet is prepared to give away. The HTLCs make each leg atomic and refundable, but they don’t remove that trust. The README says so.
- **The CUDA generator needs an NVIDIA GPU** and the CUDA toolkit to build.
- **A vanity ZTS is found without PoW only when the issuing account has enough fused plasma.** Otherwise each candidate nonce must also meet the PoW difficulty, which slows the search.
- **zts-airdrop sends one block per recipient,** so large airdrops are bounded by plasma and mainnet’s per-momentum block limit.
**Have you previously submitted a proposal (either in Accelerator-Z or Incubator)?**
- [SYRIUS v0.0.6 Improvements](https://zenonhub.io/accelerator-z/project/ada02c3217c8270e891e0d5cbfe8a3726cccd9a5af449527caf77b9eb85df550)
- [P2P Swaps in Syrius](https://zenonhub.io/accelerator-z/project/047a15a6228a18117ed924ce9bb973e2ef6d5b9576977865433e97af9526e2a9)
- In progress (submitted alongside this one)
**On-chain filing:**
| Project name | Funds |
| --- | --- |
| `NoM Utilities` | 2,000 ZNN / 20,000 QSR, one phase |
---
### Author:  [@edgepillar](http://forum.zenon.org/u/edgepillar)
#### Post date: [September 15, 2026, 3:03pm UTC](http://forum.zenon.org/t/nom-utilities/2368/2 "2026-09-15T15:03:44Z")
This is the kind of ecosystem work that isn’t always flashy but ends up being genuinely useful.
These aren’t just ideas either — the five tools are already built, public and tested. The airdrop tooling in particular is a good example of how these utilities should be designed: dry-run by default, resumable execution, a scan digest and replay/verification so a large distribution can be reproduced instead of being a one-off script somebody has to trust.
The address generators and vanity-ZTS tooling also fill practical gaps that community members would otherwise solve with private scripts of very different quality.
For a future phase, holder snapshots at an exact momentum height, weighted distributions and CSV-based recipient sets would be my highest priority for `zts-airdrop`.
I would also make the faucet trust model extremely obvious in the UI. Since an unattended static faucet necessarily contains signing capability, its wallet should always be treated as limited hot inventory and funded accordingly.
Overall the requested Phase 1 funding looks reasonable to me considering that the deliverables already exist and can be independently verified. I support it.