# \[Grant Proposal\] Zcash Name Service **URL:** \ **Category:** Applications\ **Created:** [May 19, 2026, 6:48pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737 "2026-05-19T18:48:48Z")\ **Posts on this page:** 1\ **Showing post:** 15
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [August 9, 2026, 8:17am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/15 "2026-08-09T08:17:01Z")
We want to share an update on the current status of the ZNS deliverables and the remaining work toward beta and mainnet deployment. The milestone deliverable work is progressing, with several components complete. The remaining work is concentrated around deployment and testing of the Registry / Mint service, SDK implementation, external audit, and beta/production rollout. Part of the ZNS timeline shifted because we deferred some development while Ironwood was still evolving. ZNS relies on controlled note randomness, and Ironwood changes how rcm is derived by introducing ψ and incorporating more of the note contents. As the design evolved, we updated the transaction-building, wallet integration, and verification paths in parallel with each release. That work is now converging on the finalized design and is reflected in the SDK, testing, and audit milestones that remain. Our current target for the broader beta and launch milestone is **September 15**. ## **Deliverable Status** ### **D1: Whitepaper** - **What ships:** Final spec, test vectors, memo grammar, and name canonicalization rules. - **Status:** In progress (90%) - **Notes:** Currently drafted. We will add relevant TEE assumptions and migration considerations. - **Github:** [https://github.com/zcashme/zns-whitepaper](https://github.com/zcashme/zns-whitepaper) ### **D2: `orchard-zns` fork** - **What ships:** Public `orchard` fork with structured note randomness override, passing `cargo test`, and upstream PR filed. - **Status:** Implementation complete (100%) - **Notes:** The required transaction construction flow is available, including support for wallets or custom builder code supplying their own RCM and signing transactions. - **Github:** [GitHub - zcashme/orchard: Implementation of the Zcash Orchard Protocol · GitHub](https://github.com/zcashme/orchard) ### **D3: Registry / Mint** - **What ships:** TEE-hosted name-minting service with enclave-generated spending key and public attestation. - **Status:** Development largely complete; deployment/testing remaining (90%) - **Notes:** Remaining work is primarily deployment, verification, testing, and finalizing operational considerations around TEE migration/recovery scenarios. - \*\*Github:\*\*[GitHub - zcashme/zns-mint · GitHub](https://github.com/zcashme/zns-mint) ### **D4: Resolver** - **What ships:** HTTP service for `name → address` resolution and listings on testnet and mainnet. - **Status:** In-progress (90%) - **Notes:** Must be adapted for Ironwood. - **Github:** [https://github.com/zcashme/zns-resolver](https://github.com/zcashme/zns-resolver) ### **D5: `zns-verify`** - **What ships:** Rust crate with `verify_name(...)`, `verify_listing(...)`, `verify_sale(...)`, and test vectors. - **Status:** Complete (100%) - **Notes:** The verification crate and test vectors are complete. Once published on [crates.io](http://crates.io/), wallets and other applications can use it to independently verify names, listings, and sales. - **Github:** [GitHub - zcashme/zns-verify · GitHub](https://github.com/zcashme/zns-verify) ### **D6: SDKs** - **What ships:** TypeScript/WASM package, native Rust bindings, and wallet integration support. - **Status:** In-progress (40%) - **Notes:** Existing SDK work provides groundwork, but a zns-verify specific SDK deliverable has not yet been implemented. ### **D7: External audit** - **What ships:** Independent review of `orchard-zns`, Registry / Mint, Resolver, `zns-verify`, SDKs, and TEE assumptions, with findings addressed before launch. - **Status:** Not started (0%) - **Notes:** Audit work will begin after the components in scope are published. ### **D8: Beta and launch** - **What ships:** Private testnet beta, public mainnet beta, partner SDK delivery, and production mainnet deployment. - **Status:** Not Started (0%) - **Notes:** We are currently targeting **September 15** for this phase. Audit findings must be addressed before production launch. Now, to address some of your questions: > [@artkor](#): > > If name ownership becomes more durable and independently verifiable, then bad initial registrations may also become harder to correct later. We agree with the concern. The tradeoff is that if we want name ownership to be real, there cannot also be an administrative mechanism for reversing a registration later. So our approach is to address these risks _before_ a protected name is claimed. For example, sensitive names are added to the [protected list](https://www.zcashnames.com/protected). Anyone can [suggest additional names for protection](https://www.zcashnames.com/protected/suggest), and protection decisions can be [disputed with supporting evidence](https://www.zcashnames.com/protected/dispute). A dispute triggers a review, where an admin accepts or dismisses it. All of this is public. When someone requests access to claim a protected name, we manually verify that they are actually associated with that identity. The process is similar to how Twitter historically verified accounts before issuing checkmarks. For example, if someone wanted to claim `zooko`, we would look for evidence that they control other accounts or channels publicly associated with Zooko. If that checks out, we can provide the claim access code through one of those established accounts. You can see the current claim process in our [beta program](https://zcashnames.com/beta/apply). People on the waitlist will also be able to request access to protected names through our upcoming [reservation process](https://zcashnames.com/reserve). Once a protected name has been properly claimed, it can no longer be disputed through this process. From that point forward, ownership is determined by the protocol and the wallet that controls the name. We agree that impersonation, typosquatting, bad-faith registrations, and similar cases need to be addressed. We think it should happen before ownership is finalized, through protected names, community suggestions, disputes, and identity verification, rather than through a long provisional period after registration. More detail on the current model is here: [Protected Names](https://www.zcashnames.com/docs/use/protected-names). Check out the links. Interested in your thoughts on our approach. > [@palmar](#): > > Since ZNS is a private for-profit initiative developing a product that will be sold to the Zcash community, I wonder whether the project is following the guidelines specified in [ZIP-1015](https://zips.z.cash/zip-1015) regarding open-source code and licensing: Yes, all our code is currently open sourced using the MIT license. You will be able to independently verify that our code published on GitHub is the exact same code that is used in production. In addition to the software developed as part of this grant, ZcashNames is committed to helping developers build applications on Zcash and has open-sourced tools created for internal use ([crates.io: Rust Package Registry](https://crates.io/users/craftsoldier)). We will post the next update no later than September 1. --- _[View the full topic](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737)._