NoM Utilities

Marketing ╰ Funding | Submissions
1

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:

image
image510×692 33.3 KB

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:

  • :white_check_mark: All five repositories public, with release binaries for the Go tools
  • :white_check_mark: 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
  • :white_check_mark: CUDA generator benchmark: 55,962 mnemonics/s (279,809 addresses/s) on an RTX 3060, and bit-compatible with the Go tool’s derivation
  • :white_check_mark: 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)?

On-chain filing:

Project name Funds
NoM Utilities 2,000 ZNN / 20,000 QSR, one phase
Zenon AMM
Pillar Ownership Transfer via HTLC
Zenoglyphs VM (ZVM)